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

Зашел я как-то на старое место работы с бывшими коллегами пообщаться и застал одного из них за процессом написания программы. Надо сказать, что товарищ от программирования весьма далёк, но, как мне объяснили, получает высшее образование заочно. Сидит, чешет голову, листает килограммовые талмуды — решил не беспокоить. Мало ли, может, курсовик пишет?

Через пару часов раздался победный вопль, который известил нас о том, что программа наконец заработала. Я повернул голову, чтобы посмотреть на творение и увидел черное досовское окно с радостной строчкой «Hello World!»

Несколько лет назад я сильно болел известной MMORPG Lineage 2 и узнал, что существует и активно развивается open source-проект по эмуляции серверной части этой игры. Поскольку сервер был написан на Яве, которая в то время была моим любимым хобби, я не мог пройти мимо.

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

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

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

Через полминуты замечаю, что охрана явно делает что-то не так. Меня уже не пытаются убить, хотя сражение вокруг кипит. Стражников столько, что компьютер уже сильно тормозит. Внезано большая часть участников битвы умирает от особо мощного массового заклинания, благодаря чему я наконец-то получаю шанс оглядеться.

Оказалось, что ИИ охраны замка не запрещал атаковать своих союзников. Маги, пытались выдворить меня из замка, задели своей «ковровой бомбардировкой» толпу мечников. Умный ИИ знал твёрдо: кто бьёт моего друга — тот мой враг, и ему надо дать в глаз! Соблюдая этот закон, кто-то из охраны надавал по шапке атакующим меня магам, за тех вступились друзья — и понеслось.

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

Хотите узнать, что такое настоящая ошибка?

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

В день приезда генерального директора.
На машину генерального директора.
В которой мирно спал кот жены генерального директора.

Изучаю чужую БД и вижу поле (bool) IS_FEMALE. Зову товарища и восхищаюсь нетипичностью решения.

— Обычно это поле называется SEX и значение «true» закреплено за мальчиками.
— И действительно, почему это мужчины — «тру»? Хотя в некотором смысле логично обозначать мальчиков единичкой, а девочек — ноликом.

Сам же создатель же схемы так прокомментировал этот диалог: «Логическое поле должно быть названо так, чтобы значение трактовалось однозначно — например, HAS_PENIS. Так как базу будут читать приличные люди, назвали IS_FEMALE».

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

Пришел собеседоваться программистом, сижу в общем офисе, жду менеджера. Рядом разговаривают два молодых человека.

— Слушай, а в for-цикле можно использовать что-то кроме int i?
— Можно... Наверное. Попробуй?..
— Не работает!
— Покажи, что ты там написал... Поменяй свои запятые на точки с запятой!

"Штирлиц насторожился." Тут выкрик другого парня:

— Что написать перед int, ну... это... чтобы он без минусика был?

О том, что человеку нужно ключевое слово unsigned, я догадался только после подсказки его коллеги:

— Untitled.
— Не, не работает, даже не выделяет цветом!
— Ну цветом он не выделяет, потому, что мелкомягкие всё криво написали!
— Да и вообще, замени на byte и не мучайся. — это уже третий программист.

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

Девяносто пятый год, пишем систему отображения результатов выбора в ГосДуму с использованием иерархической СУБД OpenM (папа Cache). В ходу такие понятия, как "ствол", "ветви" и "листья". Двое коллег обсуждают структуру базы данных:

— А давай-ка мы каждого кандидата в депутаты повесим на отдельной ветке!...

Не спорьте со специалистом по БД. Он знает толк в оптимизации иерархических структур!

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

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

Принялись за объект героя, написали ему систему поражений и прикрутили обратно. Тут началось странное — при попытке атаковать первого же врага главный герой погибал.

В чём дело? Условия смерти героя мы описали верно, разве что кровь ещё не нарисовали. В игре используется всего один объект «пуля». Бились над проблемой долго и безрезультатно.

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

Проблему решили, написав новый объект «пуля_героя», для которой сам герой был неуязвим. Товарищи, никогда не забывайте про кровь — по крайней мере на время разработки!

Писал я давным-давно программу — дело касалось прикручивания отладчика ActiveX-скриптов к пользовательским программам.

Прошло года четыре, и на новом месте работы всплыла аналогичная задача. Я человек не жадный, вытащил из архивов код — разбирайтесь, ребята, не жалко! Разобрались и даже нашли в моем старом коде баг. Пришлось вместе посидеть и поправить.

Буквально через день занесла меня нелёгкая на старое место работы. Водят меня мои бывшие коллеги, представляют новичкам: дескать, этот товарищ у нас работал лет пять назад, дебаггер для скриптов писал. Тут я и выдаю: «Серёга, там в таком-то файле на строке N при обработке ошибки утечка памяти — это фигня, но для порядка надо поправить и дописать „delete“».

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

Задача: протестировать оптимизирующий компилятор С++ (gcc, естественно) для встраиваемого PowerPC-процессора.

Тестовый стенд: отладочная плата, на ней проц, основной способ взаимодействия с которым - интерфейс RS-232. Чтобы не заморачиваться с передачей данных по COM-порту, я решил смухлевать — сделал все тестовые данные константными.

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

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

Уровень оптимизации 1. Код стал компактнее, откровенно тупые действия вырезаны, но некоторая рыхлость всё ещё есть. Не впечатляет.

Уровень оптимизации 2. Объекты пропали. Память больше не задействована, вместо нее работают 32 регистра процессора. Так держать!

Уровень оптимизации 3. Загрузка вычисленного значения в регистр как константы. Всё. Объём кода - 8 байт, или две инструкции (две, потому что загрузка константы на этой архитектуре идёт по полуслову).

Домухлевался. Один-ноль в пользу компилятора!