Я учусь на втором курсе айтишной специальности в крупном государственном вузе не очень крупного южного города нашей необъятной Родины. В расписании появился страшный зверь под названием «Организация ЭВМ и систем». Страшный не в силу своего природного содержания, а благодаря извращённому видению преподавательского состава.

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

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

Что-то у меня заработало не так. Зову барышню-аспиранта.

— Посмотрите, пожалуйста, у меня здесь…

— Так, подожди, это у тебя что вообще?

— Машинные команды, всё в шестнадцатиричной системе. Вот, сбоку перевод на ASCII.

— Я не знаю, что такое эти твои команды, но если ещё раз увижу, что занимаешься на занятии всякими глупостями, напишу на тебя докладную!

А вы, старшие товарищи, ругаетесь на нас, «лоботрясов недоученных»: мол, страна просит героев, а рожают дебилов. Попробуй выучись с такими «учителями»!

Начинал я на ЕС ЭВМ в ОС «Система виртуальных машин», она же VM/SP. Так вот, пользовательских исполняемых бинарников там не было вовсе. Была команда LOAD с ключом /START, которая грузила объектные модули, линковала и запускала на исполнение. При желании, конечно, можно было слинковаться и сохранить бинарник на диск (в терминологии СВМ оно называлось MODULE), но места на диске было откровенно жаль.

А теперь, как говорится, приз в студию. Загрузка всех объектных файлов реальной задачи и линковка на ЕС-1046 проходили быстрее, чем линковка «Hello world» на любом современном РС. А ведь сидел на ЕС-ке не я один, а целый учебный класс.

Прошло 25 лет, а я до сих пор не знаю, чем внутри персоналок занимаются эти хвалёные MIPS и TFLOPS. Но точно — совсем не моими задачами.

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

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

Я понимаю, что можно было второпях нагородить делов, но вам, уважаемые, любой мало-мальски смыслящий человек скажет, что массив восьмого уровня вложенности — это перебор!

В связи с этим хочу напомнить программистам старую истину Стива Макконнелла: «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте», передать огромный привет Андрею Николаевичу и Ивану Юрьевичу и пожелать им на новом месте работы такого же наследства, которое досталось мне!

Решил на днях заняться маленьким проектом. Запланировал уже давно, но пока не приступал, да и три выходных как раз выпали. Сказано — сделано: выспался, купил пива, дабы использовать в работе пик Балмера, дождался ночи.

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

$message = "Операция выполнена успешно. Ошибка в необходимости выводить ошибку".

Долго думал. Решил оставить как есть.

Что видит заказчик?

Вот, такой дом мне и нужен. Вот одобренный архитектором проект, пусть делают. Через четверть срока проекта я вижу у соседа шикарные панели из красного дерева, а у меня должна быть просто покрашенная стена. Ладно, скажу, пусть переделают. А ещё через полсрока вижу вживую мозаику на полу вместо обычной плитки. А потом натяжные потолки. Я, конечно, понимаю, что это не по плану, но не смертельно ведь, правда?

А что видит разработчик?

Утвердили проект — хорошо. Через месяц заказчик приходит и говорит, что хочет не электрическое отопление, а геотермальное. Еле объяснили, что в этом районе не получится. Согласился, но перешёл на газовое. Переубедить не смогли, кроим всё заново. Через два месяца, когда осталась отделка, прибегает и говорит, что хочет камин. Блин, в проекте нет камина! Ладно, не впервой… Под конец зашёл, посмотрел, покивал и сказал, что несущая стена явно лишняя — нужно объединить зал и кухню. Пришлось аккуратно выдалбливать и делать разводку под колонны. Не дай бог жить в этом страшилище…

И сразу всё ясно. «Мелкие поправки по ходу дела» — на самом деле кардинальные изменения. Только заказчик этого не поймёт.

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

Вспомнилась мне эволюция переделки управления в одной игрушке с тачево-айфонного на кнопочно-консольное.

Спек № 1. День потратил, сделал, как хотели, и даже багов не оставил. Посмотрели. Сказали, что неудобно, и прислали спек № 2.

Убрал старое, написал новое, день потратил. В коде по-прежнему всё более-менее гламурно. Посмотрели, прислали спек № 3.

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

И снизошло на спек № N явление великое — аппрув. И изрёк я фразу эпичную: «Это точно финальная версия? Точно-точно? Тогда мне нужно ещё время привести её в порядок». Дали мне время. Код снова стал выглядеть гламурно, и часть извращений отправилась на govnokod.ru в качестве учебника, как делать нельзя, совсем нельзя и нельзя ни в коем случае, но все делают и будут делать. И явилась версия финальная, в коей я был уверен, в которой багов весь отдел QA не нашёл, код которой читался, как хороший роман с логичной концовкой.

К чему я это всё? Да ни к чему. Просто неплохо было бы бедным и страдающим под игом творческого поиска заказчика разрабам ввести ещё одну итерацию — code review, которая приводила бы все бульдозерные отвалы под один интерфейс, дабы не пугался новоявленный Франкенштейн дитя своего.

Взгляд программиста на разработку:

1. Тебе объясняют, чего хотят (назовём это первичным техзаданием, хотя ТЗ сам себе обычно пишешь, ибо заказчик не в состоянии составить вразумительное).

2. Ты чего-то там ваяешь и, победив гору глюков, с сожалением отдаёшь невинного ангела, алмаз кристальной чистоты и небесной красоты в грязные лапы заказчика.

3. Заказчик смотрит, говорит: «Круто. А можно ещё добавить вот такую вот фичу?»

4. Говоришь: «Нет проблем». Пыхтишь над прогой, побеждаешь ещё одну кучку глюков, приносишь заказчику программу, которая делает немного больше, немного умнее или выглядит немного красивее, но более жуткая в коде.

* * *

Проходит несколько итераций пунктов 3 и 4, и заказчик говорит: «Всё, готово». И ты с содроганием осознаёшь, что на свет произвёл очередного монстра, который ездит, летает, пыхает огнем, копает ямы, вышивает крестиком и изобретает велосипед. Красота кода — по хрену. Эффективность стремится к нулю. Код сложный, запутанный, куча шаманских костылей. Невзирая на то, что сам создал этого монстра, ты его боишься. Боишься тронуть даже что-нибудь незначительное и второстепенное — вся программа грозит осыпаться.

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

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

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

С каждого заказчика я требую полный список требований к приложению. Предупреждаю, что на все последующие «хочу» и «можно ли» ответом будет «нет». Вы скажете, что этот подход чреват потерей клиентов. Я знаю. А вы задумываетесь, какого рода «клиентов» вы теряете? Я задумываюсь.

Потратить неделю на поиск заказчика, который в состоянии совершенно точно описать по пунктам всё, что ему нужно, и потом ещё неделю на разработку сверхсложного пусть даже велосипеда? Или потратить неделю на разработку чего-то специфичного (на первый взгляд), затем ещё неделю на то, чтобы понять, что не хватает клиенту-на-два-килорубля, потом ещё неделю на разработку дополнительной функциональности (это при том, что цена не меняется), а в итоге ещё пару недель на докручивание непредусмотренных рюшечек и осознание того, что в итоге всё умещается в велосипед-на-пару-дней-работы?

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

Я просто обалдеваю с некоторых программных решений.

Задача: обеспечить параллельную разработку новых возможностей у одного и того же программного продукта.

Решение: «песочницы». Одну папку исходного кода дублируют множество раз, по числу групп разработчиков, создавая так называемые версии. Каждая группа разработчиков мучает свою версию, ковыряясь в ней, как детишки в песочнице, и не пачкает чужие версии, то есть не мешает остальным группам. Перед релизом все версии, которые успели достичь половой зрелости и продемонстрировали хотя бы 15 минут стабильной работы, сливают в одну, её называют основной, выжигают на компакт-дисках и продают клиентам. После чего отдел тестирования начинает бегать кругами и орать, потому что две разные группы ковырялись в одних и тех же файлах, а слияние выполнялось левой ногой через правое ухо, и теперь не работают ни код первой группы, ни код второй, а грузовики с дисками уже выехали в магазины.

Итак, одновременно существуют несколько десятков версий. Разработчики занимаются своими малопонятными делами и время от времени вносят забагованный исправленный код в одну из «песочниц». Еженощно на всех «песочницах» бежит регрессия, а следующим утром ещё не проснувшиеся разработчики получают сто пятьдесят шаблонных сообщений электронной почты уровня «особой важности» с результатами тестирования для каждой версии и со стандартным заголовком: «А-а-а-а, мы все умрём, регрессия упала по ТВОЕЙ вине, а ну быстро исправляй свои баги». До сих пор всё хорошо.

Раз в какое-то время эти «песочницы» нужно изменять. Добавить, убрать, переименовать. Для этого используется доморощенная программа, написанная для своего удобства студентом-первокурсником в свободное от занятий фигнёй время и доведённая до ума тремя поколениями мудрых специалистов. Опций там на самом деле всего две («добавить „песочницу”» и «удалить „песочницу”»), поэтому переименование реализовано просто и красиво: старая «песочница» удаляется, создаётся новая, и разработчикам рассылается сообщение: «Из-за технических проблем мы потеряли весь код в такой-то версии; если вы вносили туда изменения, внесите их вот в такую-то версию, пожалуйста».

Пока всё ещё неплохо, да? Подождите, сейчас начнётся самое весёлое.

Рассылать сообщения вообще всем работникам — идея, конечно, благая, но будет проще и правильнее рассылать сообщения только тем, кто уже вносил код в эту конкретную «песочницу». Сделать это просто и легко: все внесения кода в «песочницу» есть, они выстроены в красивую таблицу, авторы изменений указаны отдельной колонкой, и есть специальная галочка «сообщить авторам изменений об удалении». Если отметить галочку, скрипт вытащит имена из таблицы и отправит каждому автору персональное извещение.

То есть у нас классическая двухходовка: во-первых, вытащить все имена авторов изменений из таблицы и что-то с ними сделать; во-вторых, удалить всю таблицу изменений.

Так вот, вы в жизни не догадаетесь, в каком порядке выполняются эти два шага.

Ехал я домой в поезде после очередной учебной недели. Нечем было себя занять, поэтому решил сделать очередную лабораторную работу по дисциплине «Организация функционирования ЭВМ» (старый добрый ассемблер). Напротив меня в купе сидела довольно симпатичная девчонка и с умным видом тыкала в клавиатуру ноутбука. Через некоторое время мы познакомились, разговорились.

— Сколько будет два в тридцать второй? — решил в шутку спросить я.

Не прошло и двух секунд.

— Четыре миллиарда двести девяносто четыре миллиона девятьсот шестьдесят семь тысяч двести девяносто шесть.

Немая сцена секунд десять. Она встаёт, подходит и глядит в монитор моего ноута:

— Е$@ть! Ассемблер!

Со своей любимой я счастлив уже около трёх лет. Ассемблер — всему голова.