Закончил очередную функцию нашей Главной Проги. Андроид-приложеньице отправляет запрос на сервер конторы, получает ответ, выводит очередной график. Очередное сообщение — очередную линию рисует алерт-подобным цветом. Запрос — ответ — отображение.

Дочь скачала программку для соцсети. Сообщения, группы, картинки. Запрос — ответ — отображение.

Гаджет о погоде. Удобно, градусы всегда видно на рабочем столе. Оно постоянно делает запрос на погодный сервер, получает ответ, выводит.

Взгрустнул.

Запрос — ответ — отображение. Таковы 90% ПО и в маркетах, и которое делаю сам. Фактически — урезанная версия браузера. (Ну ладно, иногда расширенная. У нас, например, теги графиков и алертов не по спецификациям W3C сделаны. Три раза «ха».) Блин, но суть-то одна!

90% программистов пишут браузеры. Если повезёт, появляются 10% настоящего программинга на стороне сервера, который заказчику/клиенту/потребителю не виден, но чаще всё уже готово. (Сам использую спелчекер — ну, если юзер вдруг захочет тут же письмо отправить, кошерно бы его сразу и проверить, всё-таки начальство в основном использует, ему негоже ашипки сажать.)

Коллеги говорят: «За что платят, то и делай». Да я не против. Но грустно как-то немного…

Тут один человек предлагал «выбирать технологии», дабы освободиться от быдлокода. Я тут валяюсь под столом и пытаюсь сквозь смех написать…

Так уж повелось, что программист на порядок чаще читает код, нежели пишет, причём, скорее всего, код этот чужой. Весьма вероятно, его писали где-нибудь в середине мезозоя, и последний тираннозавр, который в нём соображал, погиб от злосчастного астероида. Да и стандарты кодирования тогда были другие, если были вообще. К примеру, писать комменты на перфокартах — зто замедлять загрузку почём зря, это плохо. Логично?

И тут приходит такой из себя хомо сапиенс и говорит, что для данной задачи нужен другой инструмент и/или фреймворк. Да кто бы тебя спрашивал! Даже если и прав, код уже написан. Когда софт писали, не было этих фреймворков. К тому же фреймворк определяется другими факторами. Язык программирования и тип задачи практически однозначно укажут на фреймворк. C# для GUI-приложения автоматически даёт Windows Forms, Delphi даёт VCL — и выбирать не приходится.

Таки да, есть много умных книг, как писать программы, даже как их рефакторить. Есть куча людей, которые посоветуют тебе, какие инструменты выбрать под новую задачу. Но, блин, кто-нибудь, напишите, пожалуйста, книгу, что делать с уже написанным кодом! Код уже есть, писать его не надо, проехали, но объясните, как теперь с ним жить!

Сижу вот. Восемь миллионов строк. Поддерживать нереально: слишком много. Разобраться нереально: решаемые кодом задачи заумные. Рефакторить нереально: надо разбираться в сути вопроса, чтоб рефакторить. Заново переписать восемь лямов тоже нереально: займёт те же лет двадцать. Выкинуть код нереально: доход от продаж с этого продукта выражается семью нулями зелени. Ну и?.. Any ideas, как говорят на том берегу атлантической лужи?

Фух, отпустило. Проржался. C грустным видом вылезаю из-под стола, чтобы тупить в очередной кусок кода…

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

Вот попадается упёртый товарищ с синдромом утёнка: когда-то он освоил систему ХХХ, работает с ней, только с ней и ни с чем иным.

— Попробуем сделать вот так?

— Нет!

— Ну, может, вот это заменим?

— Нет и нет!

— Почему?!

— Потому что ХХХ — лучшее, что было создано с начала времён!

Другой, наоборот, модный и современный:

— На прошлой неделе анонсировали YYY! Крутая штука, я уже попробовал, офигенно!

— Погоди, там вон то не доделано, баги не пофикшены, а вот это вообще глючит…

— Ты ретроград! Всё передовое человечество!.. А ты!

Третий — раб массовки:

— Надо делать вот так, так все делают!

— Но в нашем случае это же неудобно.

— Ну и что, так все делают! Понимаешь, все!

Четвёртый — раб авторитетов:

— У тебя неправильно: вот эту штуку надо делать вот так.

— Почему?

— Так завещал Великий Гуру, так учит Его статья в самом авторитетном журнале!

— Но ведь твой гуру говорил про свой частный случай, когда…

— Он не мог ошибаться! Ты хочешь сказать, что знаешь лучше?!

Сам я тоже не идеален и иногда упираюсь, но у меня хотя бы аргументы есть. Скажем, мне не нравится один популярный язык программирования, не нравился никогда, потому что крив и глючен. Иной раз посмотришь на новую версию, видишь, что лучше не стало — и аргументы остаются в силе: он по-прежнему крив и глючен. Покажите мне, что кривизну исправили — и я поменяю своё мнение. Но вот так упираться, основываясь на привычке, моде, массовости и вере, — зачем?!

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

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

— Ну, у нас же реализована архитектура «запрос — ответ»! Нам же не надо держать 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 — пустая трата времени даже при разработке биллинговой системы.

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

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

Объясняю.

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

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