В хорошем, крепком банке с конца восьмидесятых активно использовались несколько барабанных АЦПУ с интерфейсом ИРПР. А надо знать, что ИРПР — это штука хитрая и с привычным Centronix не особо совместимая. Поэтому к этому делу прилагался драйвер.

Изначально всё это было заточено под XT. К 93-му году экстишки себя совсем изжили и были переданы в филиалы райцентров, где после Robotron-1715, а кое-где и печатающих калькуляторов Elka-55 им сильно обрадовались. На смену заслуженным экстишкам пришли 286-е машины. Тут-то принтера и отвалились. Кооператив, который делал сопряжение интерфейсов, уже давно пукнул и испарился — разумеется, вместе с исходниками. Печатать сальдовки по сто метров надо. Оставшиеся экстишки отбирают в приказном порядке.

Давай разбираться, что не так. Тык-мык-тык-мык. Что первое в глаза бросается? Экстишка — 4,77 МГц, 286-ая — 12, а в турборежиме — 16. Перепаиваем кварц на экстишечный. Работает принтер. Значит, завязан на тактовую частоту и квитирование делает в зависимости от неё. Но кто ж позволит из работающей экстишки кварц попятить?

«Пишем драйвер», — говорит шеф. Пишем, чё! «За сутки управимся», — отвечаю я.

И тут выясняется, что спеков на ИРПР хоть чем жуй. А вот на ИРПР-М, он же Centronix, чё-то не видно нигде. Ну, пока всякие НИИ работали, можно было в их научных библиотеках покопаться. Или в какой ВЦ по старой дружбе заглянуть — спеки-то не секретные. Но на улице был 93 год, и почти всё уже загнулось и позакрывалось.

Хорошо, что драйвер был пару килобайт. Плохо, что в виде TSR-программки. Если что, Hiew и IDA появились заметно позже, а досовский debug дебагать TSR не очень умел. Даже хекс-режим «внортонепоэфтрисампосмотри», по-моему, ещё не появился. Поэтому сначала мы получили старую добрую распечатку хекс-дампа драйвера. Потом «дизассемблировали» карандашиком на бумажке. Нашли цикл задержки, который крутился в цикле управления квитированием, после чего рассчитали нужные значения для 12 МГц и попатчили драйвер. Найти под утро компилятор ассемблера тоже оказалось непростой задачей. Да и драйвер изначально не на ассемблере был писан. И мусорного кода было предостаточно.

Самое главное, что в цикле гонялось транспонирование каких-то мусорных матриц. Увеличение размеров матрицы и их количества позволило аналогично попатчить драйвер под 25, 33, 40 мегагерц. А вот, не приведи господи, считался бы там какой-нибудь факториал…

Потом появились 486 с кэшем, и всё накрылось тазом. Но к тому времени под рукой уже были и дебаггеры, и IDA, и компиляторы. И году в 96-м драйвер был-таки переписан.

Подводный истребитель, говорите? Ладно, протестировали, нашли багу с отрицательной высотой, спешно исправили, летаем дальше.

Другой истребитель (F-16) на автопилоте должен был переворачиваться брюхом вверх при пересечении экватора. Хорошо, нашли багу с отрицательной широтой (слава богу, при тестировании софта на симуляторе, до реальных полётов), исправили второпях, опять летаем.

Какие бишь там ещё у нас координаты остались? Ага, долгота! И вот уже совсем недавно, в 2007 году, целая эскадрилья новейших истребителей (опять истребителей!) F-22 не смогла перелететь из США в Японию из-за непреодолимого препятствия — линии смены дат посреди Тихого океана.

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

Глаза слипаются. Четвёртый час ночи. Нужно дописать прогу и идти спать. Делов-то на пять минут — и о чём раньше думал? А всё эта лень. Ей нормально, а ты страдай потом.

Ну что уж там демагогию разводить… Накидал форму, написал код. Всё работает. Правда, как всегда, по-индусски: куча ненужных переменных, кривой код. Ну да ладно, зато форма яркая: всевозможные плюшки типа кнопочек, эдитов, лейблов и других никому не сдавшихся блэкджеков. Напоследок глянул форму. О, лишняя кнопка «Button 5». Удалил. Закрыл прогу. И перед самым выходом из системы мне на глаза попалась эта самая кнопка прямо в центре рабочего стола. Она яростно стучала в экран монитора с обратной стороны. Я наклонился к ней и отчётливо услышал вопрос.

— Для чего? — страдальчески кричала она. — Скажи мне, для чего всё это?

— Мне нужно было умножить X на Y, — ответил я.

Кнопка потупила взор и медленно скатилась по экрану вниз.

— Как же так? — прошептала она. — Икс и игрек? Не может быть.

Её глаза налились слезами, и сквозь них она продолжила:

— Я родилась в семье простых рабочих кнопок. Мать рано умерла, отец пил. И чтобы прокормить своих младших братьев, я рано устроилась на работу. После погиб отец. Его переехал двумерный массив, когда тот в пьяном бреду выбежал в исходный код. Братьев у меня отобрали. Один повторил судьбу отца, второго посадили за хищение переменных. Мне было трудно, часто я подумывала о суициде. Но мне встретились добрые лейблы, которые дали мне надежду, уверили в том, что жизнь не так уж и плоха, что есть оборотная её сторона, что всё это не зря, я живу не зря, понимаешь? Я стала усердно работать, добивалась всего сама, потом и кровью. Построила собственную кнопочную империю, занималась благотворительностью. Я стала Стивом Джобсом этой долбаной программы! — срывая голос, кричала кнопка. — И сейчас ты мне говоришь, что это всё ради каких-то вонючих иксов и игреков?

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

Понадобилось однажды программку написать простенькую: распознавание несложных капч. Для этого надо было сделать поиск цифр. В коде было очень много кусков с практически одинаковым кодом, но разными указанными цветами. Сидел я, копировал, заменял. Через некоторое время надоело, и я, не думая, скопировал и написал: #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-окружении ничего не изменилось». Спросил у админов, когда последний раз пересобирали код. Ответили, что в пятницу вечером. Кирпичики уже собирались посыпаться. Уточнил ревизию, которую использовали для сборки. Ответили, что использовали версию кода с изменениями, сделанными не позже четверга.

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