Программизмы

Устроился в небольшую компанию программистом. Компания предоставляет некоторые услуги своим клиентам. Но предоставляет крайне фигово: больше полусотни пользователей не держит.

Начинаю разбираться, что почём. Первым делом настораживает, что сессия длится один пакет. Следующий пакет так же должен быть с авторизационными данными.

— Ну, у нас же реализована архитектура «запрос — ответ»! Нам же не надо держать TCP-сессию! — говорит программист с 25-летним стажем.

— Гм, — говорю я и лезу в код сервера.

Лучше бы я этого не видел.

На каждый входящий пакет создаётся поток-обработчик, который умирает сразу же после того, как отсылает пакет обратно. И, естественно, убирает за собой все данные о клиенте. Что характерно, поток-получатель парсит HTTP-заголовок.

Начинаю переписывать код. Сперва создаю пул потоков-обработчиков, но очень быстро утыкаюсь в ситуацию, когда у меня 100500 потоков на 24-ядерной системе. В общем, ситуацию это спасает, но не намного.

Далее избавляюсь от авторизации: клиенту передаётся его сессионный ID, и уже дальше работаем с ним.

Потом избавляюсь от пула потоков, создав очередь запросов, из которой могут брать любые рабочие потоки.

Потом делаю ещё одну страшную вещь: переношу очередь запросов как можно ближе к получению пакетов, до парсинга HTTP-заголовка. Результат — восьмиядерный рабочий комп выдерживает стрессовую нагрузку до 100  тысяч пакетов в секунду.

На следующую неделю компания закрывается: в связи с кризисом отвалились три крупных клиента, и бюджета на программистов не хватает.

Уважаемый автор истории «Будут деньги — будет пища»! Без сомнения, вы хороший программист. Однако, если бы ПО делалось по вашему предложению (а такие попытки были лет 10–15 назад), то случилось бы следующее:

1. Кассир пробивает покупки и показывает вам итоговую сумму.

2. Вы оплачиваете покупку.

3. Кассир говорит что-то типа: «Ой! Бумага закончилась! Подождите три минуты — схожу на склад».

4. Вы уходите со словами: «Я спешу, мне чек не нужен».

5. Кассир отменяет продажу и кладёт деньги себе в карман.

В итоге магазин шаговой доступности становиться убыточным, закрывается, и вам приходится ездить за хлебом и прочим к чёрту на кулички.

Прежде чем делать предложение по оптимизации ПО, учтите специфику отрасли, где это ПО применяется.

В связи с недавними событиями вспомнилась история, произошедшая N-дцать лет назад. Играл я в то время в X-COM и развивал прекрасного со всех сторон юнита в качестве лидера. Но случился очередной левел-ап перед полётом на Марс, и у юнита вместо очередного прибавления очков здоровья (было 246 или около того) произошло ужасное несчастье: хит-поинтов стало 28. Как начинающий программист, я понял, что произошло переполнение восьмибитной ячейки памяти (хорошо хоть не упало), хранящей количество очков здоровья, но как игроку мне это сильно не понравилось.

Спустя те же N-дцать лет ко мне пришёл разработчик с вопросом, какой именно тип сделать для колонки в базе данных — 32-битный или 64-битный (проблема скорости работы стояла остро). Система подразумевает наличие локальной базы и репозиторной базы, и структура таблиц обеих баз должна быть идентичной, чтобы упростить синхронизацию между ними. Поскольку значение в этой колонке — это количество операций, сделанных лично пользователем, то логично предположить что пара миллиардов — это практически недостижимый предел человеческих возможностей по совершению операций с системой. Но тут-то я вспомнил, что примерно то же самое, видимо, предполагалось и в этой самой игре. Ведь не всегда можно угадать, сколько же локальных баз (то есть пользователей) будет синхронизировано с репозиторной базой. Потому и предложил разработчику использовать 64-битное поле. На всякий случай… Ведь похожий случай уже был недавно.

Собираю LUA.

lua\lapi.c(1090): warning C4702: unreachable code

Смотрю на 1090-ю строчку:

return 0;  /* to avoid warnings */

Машинных языков много, но что между ними общего? Они не терпят синтаксических ошибок. Наберите нечаянно или нарочно какой-нибудь prind, fond-colar или stardigz — интерпретатор или компилятор растеряется.

Разработчики поисковиков ещё педантичнее. Их детища на опечатки отвечают нравоучениями: «Ты чё лепечешь, может, ты имел в виду вот это?»

Так кто придумал язык падонков? Оставим теории заговора в покое — они красивы, но неубедительны. Всё проще. Либо его «аффтары» далеки от IT, либо настолько близки, что нетерпимость бездушных железок к синтаксическим ошибкам их реально достала.

Но зачем отыгрываться на людях?

Конечно же, часть менеджеров — мусор. Но это справедливо и для разработчиков, и для дизайнеров, и для всех остальных. В условиях жёсткой нехватки кадров компании начинают брать работников невысокого качества, а потом хрен их выгонишь.

Мне попадались дизайнеры, ухитрившиеся сделать главную страницу весом в 20 мегабайт. Художники, не имевшие понятия об анатомии и перспективе. Системные администраторы, которые при копировании данных ухитрились потерять все файлы .htaccess и после трёх напоминаний всё равно забывшие, что нужно установить определённый набор библиотек, но выпустившие все это в продакшн.

И, наконец, мои коллеги-программисты, писавшие if на пятнадцати строках с десятком вызовов функций с невменяемыми названиями и параметрами внутри без единого комментария ко всему блоку кода. Программисты, делавшие SELECT * на таблице с сотней миллионов записей (на тестовом сервере было всего тысяч десять, так что всё работало, а вот в продакшне…) Программисты, презирающие ссылки и пересылающие в подпрограмму массивы по миллиону элементов. Программисты, считающие, что ссылки вида parent.parent.parent.parent["funcRecalc"](a,b,c) — это нормально. Программисты, считающие, что defensive programming — пустая трата времени даже при разработке биллинговой системы.

Небрежность, лень, тупость, запутанный и некомментированный код, отсутствие комментариев к коммитам, игнорирование соглашений по коду и полное безразличие к работе в целом — всё это встречается настолько часто, что лишь чудовищный дефицит кадров позволяет всем этим людям иметь работу (во всех смыслах). А вы говорите — менеджеры…

— Пап, объясни, что такое припев.

Объясняю.

— Понял, это как подпрограмма!

А лет тридцать назад авторам одной книги, наоборот, приходилось объяснять детям, что такое подпрограмма, на примере припева.

Прочитал экономические откровения противника копирайта, посмеялся, но решил не вмешиваться в великую борьбу Добра™® со Злом (скачать бесплатно без регистрации и СМС новый интернет ускорьте ваш компьютер), а вместо этого рассказать про менеджеров.

Среди юных разработчиков бытует мнение, что менеджеры в IT — это такие паразиты, что они совершенно не нужны, а то и специально вредят. Что легионы менеджеров готовы облепить любой стартап и сосать деньги из проекта.

Увы, в реальности всё совсем иначе. Хороший менеджер — на вес золота. Его найти ещё сложнее, чем найти хорошего лида-разработчика. А искать придётся, потому что, как только людей в команде становится больше пяти, они начинают резко утрачивать возможность договориться и отследить договорённости самостоятельно. Если же взаимодействуют несколько команд или отделов, например, дизайнеры, серверные программисты и клиентские программисты, то без хорошего менеджера проектов работа превратится в взаимное перекладывание ответственности. Вася ждёт Петю. Петя ждёт дизайн. Дизайнеры помнят о заказе Пети, но сейчас заняты большой задачей от Коли, ведь Петя попросил какую-то мелочь — откуда им знать, что это важно? Вася тем временем от безделья занимается рефакторингом и разбирает свою часть проекта до состояния, когда ему потребуется ещё неделя, чтобы её переделать — бросать переделку он не хочет, потому как жалко уже потраченного времени и «всё равно это надо».

Проект будет в непонятном состоянии, хотя все будут считать, что «почти готово». Это «почти готово» тянется месяц за месяцем, порой превращаясь в годы. Когда же волевым решением проект выходит с обрезкой всяких недоделанных мелочей, он оказывается сырым, потому как собирали в спешке. Хуже того, он ещё и не соответствует ожиданиям целевой аудитории, для которой оказались важны те самые обрезанные мелочи (тут привет передают маркетологи, в задачу которых как раз входит выяснять, чего, как и когда хочет целевая аудитория и за какую цену).

В этом месте некоторые читатели воскликнут: «Да как же так, мы же все умные люди, неужто мы не сможем договориться без какого-то там посредника?» Увы, как показывает практика, люди зачастую не способны договориться даже сами с собой и распланировать свои собственные деньги и время хотя бы на месяц вперёд.

Всё вышенаписанное умножается на десять, если речь идёт о крупной компании, где взаимодействие между отделами строго формализовано.

Ещё в советское время был такой анекдот.

Что нужно сделать, чтобы вскипятить чайник, стоящий на столе? Взять чайник со стола, налить в него воды, поставить на плиту — ну, и так далее, алгоритм очевиден. А если чайник стоит на окне? Нормальный человек скажет: взять чайник с окна, налить воды… А программист (так тогда называли айтишников) скажет: переставить чайник на стол и выполнить предыдущую подпрограмму.

Когда-то мне это казалось прикольным. Не надо, мол, всё программировать снова, можно свести к уже известному. Но когда, чтобы вскипятить чайник, приходится по 25 раз переставлять его с места на место, хочется материться.