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

Понадобилось однажды программку написать простенькую: распознавание несложных капч. Для этого надо было сделать поиск цифр. В коде было очень много кусков с практически одинаковым кодом, но разными указанными цветами. Сидел я, копировал, заменял. Через некоторое время надоело, и я, не думая, скопировал и написал: #define clBlack clRed. И #undef, конечно же. Что удивительно, всё потом заработало.

До сих пор вспоминаю, не было ли там где-нибудь #define true false.

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

О проверке дискриминанта вспоминают практически все. О том, что есть комплексные числа, и этот случай надо тоже обрабатывать, — примерно каждый пятый.

О том, что надо обрабатывать вырожденный случай — линейное уравнение, — каждый двадцатый.

О потере точности не вспоминает практически никто. После моих намёков код переписывается и распухает раза в три.

О потере точности в комплексных числах никто сам так и не вспомнил.

Сопроцессор в архитектуре х86 при денормализованном результате может генерировать исключение (ошибку). Народ матерится и начинает устанавливать флаги сопроцессора. После намёка, что такой финт может повлиять на выполнение кода во вложенных вызовах, в соседних потоках и колбэках, матерится и переписывает ещё раз. Потом вопрос: а что будет, если кто-то поменял флаги сопроцессора извне? Потом я задаю вопрос про SSE, ARM, PowerPC, режимы округления 80x87. Прошу оценить погрешность вычислений. Что делать, если погрешность вычислений такова, что влияет на знак дискриминанта? Намекаю, что при большой погрешности надо сменить метод решения… К этому моменту не совсем тупой народ начинает понимать, что сильно попал.

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

Если человек говорит, что пишет программы без ошибок, увольняйте его немедленно. Полное совершенство и всеведение доступно только Аллаху, но он программ не пишет. Для прочих смертных — это верный признак, что человек умеет сваливать ответственность на других, и за ним придётся все переписывать. Чем круче джип, тем дальше бежать за трактором.

Говорят, парашютные инструкторы больше всего не любят учеников, которые не боятся.

Вы знаете и используете юнит-тесты, интеграционные тесты, выстраиваете красивые архитектуры, пишете идеальный код? Отлично! Но почему вы уверены, что в нём нет ошибок? Почему вы не боитесь? Ни один из имеющихся у человечества инструментов, включая формальную верификацию программ, не позволяет доказать её корректность.

Очевидно, что для самолёта нулевая высота там, где лежит Мировой океан. Вот кто знал, что F-16 может летать на несколько метров ниже этого уровня? Однако над Красным морем на бреющем полёте это возможно.

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

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

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

Однажды инженер из AT&T по ошибке выдернул блок не из выведенной в режим обслуживания стойки АТС, а из стоящей рядом рабочей. Соседние АТС этого не оценили и веером отключились. Наземную связь на территории половины США восстанавливали около суток.

Вы все ещё уверены в своём коде и не боитесь? А были бы так уверены, если бы от вашего кода зависели жизни людей?

Довелось мне унаследовать работу одного, несомненно, талантливого программиста. Был у него всего один недостаток: не писал он комментариев. Во многих тысячах строка кода изредка лишь вкрапливалось что-то типа //new, //modified. Самый информативный комментарий, который мне попался: //product.

Коллеги-программисты! Не умеете описывать свои гениальные функции по стандартам — хотя бы не ленитесь писать информативные комментарии между строк, если не хотите, чтобы вас прокляли.

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

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

Есть входные данные — они могут поступать из разных источников, значит, надо продумать защиту от того, чтобы эти данные могли привести к сбоям.

Есть опечатки в коде — для этого в нормальных языках программирования предусмотрены специальные инструменты. И никакая «неопределённая переменная» вам не будет страшна. Кстати, не забывайте инициализировать переменные — это ведь нетрудно!

Есть ошибки, когда кто-то перепутал местами переменные или использовал не ту функцию, но для этого у вас должен быть продуман сценарий тестирования модуля. Сделали — собрали — протестировали. Ведёт себя не так, как должен? Устраните проблему! И делайте это на уровне отдельных модулей, ещё до того, как готовая система уйдёт в отдел тестирования.

Не надо городить сложноинтегрированные системы. Разбивайте их на отдельные функциональные блоки! Каждый блок должен работать идеально. Надо будет — лучше потом написать ещё один интерфейсный блок для сопряжения.

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

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

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

Может быть, причина в модных тенденциях программирования, когда код пишется по наитию, в режиме ошпаренной кошки, или тремя программистами за одним монитором, или на основе монстроидальных фреймворков без понимания их устройства, или с бездумным использованием чужих наработок по принципу «нагуглил и скачал»?

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

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

Как-то раз после особенно долгого, почти часового объяснения, как написать какие-то 200 строчек кода с использованием модуля Graph, я сдался и попросил прислать код на почту. Открываю .pas, читаю начало кода:

program graphblabla;
if 4 > 3 then
BEGIN
…

Мне понадобилось минут пять, чтобы перевести дух.

Закрыл в пятницу четыре бага. В субботу четыре из четырёх получили статус «Rejected» с комментарием в стиле: «Написано, что исправлен, а в stage-окружении ничего не изменилось». Спросил у админов, когда последний раз пересобирали код. Ответили, что в пятницу вечером. Кирпичики уже собирались посыпаться. Уточнил ревизию, которую использовали для сборки. Ответили, что использовали версию кода с изменениями, сделанными не позже четверга.

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

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

Есть у меня товарищ A., у которого свой товарищ B. Товарищ A., не щадя живота своего, вкалывает на B. Сам я калякаю на питонах, дельфях да плюсах.

А. — юный падаван: там подхалтурит, здесь подпаяет, в общем, ничего выдающегося. B. — техномаг, рулит отделом в средней успешности фирме, работающей в двух направлениях: разработка мелкокалиберного ПО и сервисный ремонт ПК. Я в этой адской системе как внештатник числюсь.

И вот сидим мы давеча в баре с А. под хорошим градусом, ибо сынишка у него родился. И вдруг хватает он меня за пуговицу рубахи и скромно так, даже стыдливо молвит:

— Валик, ты бы это… Короче… Программируй неправильно! А то мы задолбались в пять вечера уходить, ни фига интереса нету. B. жалуется, по быдлокоду соскучился, говорит. И директор премии лишил за прошлый месяц…

Грешен: пивом подавился.