— Ммм, не знаю даже…

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

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

— Вот это и есть наша задача. Надо придумать, как сэкономить время на отладке программ.

— Вы научите их, как эффективнее отлаживать программы?

— Нет, — покачал головой Кенорос, — мы будем учиться эффективно проектировать.

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

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

— Как же можно вот так взять и отменить отладку программы? — уже в который раз поражался мистер Томпкинс.

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

— Да, но тогда получается, что в нашей программе вообще не должно быть…

— Не должно быть ошибок. Правильно. Вы схватываете просто на лету.

— Совсем без ошибок?!

— Конечно. Вы же сами только что это сказали.

— Но как мы можем написать код без единой ошибки?

— Ну, смотрите. Вот только что вы обнаружили ошибку в одном из модулей. Где находится эта ошибка?

— В модуле.

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

— Правильно, это каждому известно. И что же?

— А то, что когда вы находите ошибку, то смотрите совершенно не туда, куда нужно.

— И куда же я смотрю? — осведомился мистер Томпкинс, поневоле раздражаясь.

— Вы смотрите внутрь модуля, в программный код.

— А куда я, по-вашему, должен смотреть?

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

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

— Вот и неправильно.

— Что неправильно? Что мы не замечаем отдельные ошибки?

— Нет, неправильно, что вы пытаетесь исправлять ошибки на стадии проектирования.

— Я не могу понять — о чем это вы?

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

— Но мы всегда проектируем, прежде чем писать код, — все так делают.

— Разумеется. Только вот все занимаются этим не в то время, которое было отведено на проектирование. Скажем, в начале проекта команда создает некий документ. В этом документе есть немного философии, немного размахивания руками и надувания щек, может быть, общая структура будущей системы — вот, в общем, и все. И все это создается с одной-единственной целью: обезопасить себя от руководства, которому обязательно нужно видеть этот самый документ. Наконец начальство говорит: «Поехали». И теперь начинается самая интересная часть работы. Вся команда радостно запихивает никому не нужный документ на полку, где он пылится до окончания проекта. А вот когда они приступают к написанию кода, тут-то и начинается настоящее проектирование. Именно тогда, когда они пишут код! Вот когда принимаются решения о конкретных модулях, их поведении и интерфейсах. И вот эти решения вы уже никак не проверите.

Мистер Томпкинс только дух перевел. Ему страшно не нравилось то, к чему клонил Аристотель.

— Разумеется, низкоуровневый дизайн воплотить в жизнь куда как проще.

— Разумеется.

— Но только низкоуровневый.

— То, что вы называете высокоуровневым дизайном, на самом деле — философия и размахивание руками.

— Не знаю, не знаю… Что-то подсказывает мне, что вы почти во всем правы, и тем не менее…

— Конечно же, я прав. Низкоуровневое проектирование — единственная реальная вещь во всем проекте. А то, что столь напыщенно называют «концептуальным дизайном», на самом деле — одна показуха.

— Ну, допустим, вы правы. А если нет? Уж меня-то это точно должно беспокоить, правда? Допустим, я сделаю то, что вы советуете, а потом окажется, что вы ошиблись?

— Тогда вам хана, — весело улыбнулся Аристотель Кенорос.

— Вот это-то меня и беспокоит.

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

— Аристотель, скажите честно — чья это сумасшедшая идея? Кто это все придумал?

— Один парень.

— Вы сами?

— Нет, не я. Какой-то другой парень. Я даже не знаю его имени. Я сам практикую эту технику уже много лет, но выдумал ее не я.

— Вы даже не знаете, как его зовут?

— Нет, мы с ним общаемся через Интернет. Просто обмениваемся сообщениями. Это оракул, гуру, но имени своего он не называет. Могу дать вам его ID, если хотите. Спросите его сами, — Аристотель нацарапал несколько цифр на листке бумаги и протянул его мистеру Томпкинсу.

Мистер Томпкинс взял листок и отправился восвояси.

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

Однако это не доказывало обратного: что в результате более тщательной работы над дизайном в программе останется меньше ошибок и недоделок. Дело в том, что он уже приготовился записать следующий пункт: «Чем больше времени мы расходуем на проектирование, тем больше времени экономим на отладке», но ему не хватило уверенности. Так ли это? Проверить сейчас он это не мог, значит, надо было просто поверить Аристотелю Кеноросу или же вообще забыть об этом. И, честно говоря, он еще не решил, какой путь будет более правильным.

Если он согласится последовать совету Аристотеля, то наверняка не обойдется без бунта на корабле. Программисты привыкли тратить много времени на отладку программ и исправление ошибок. И едва ли им понравится такая вот радикально новая схема работы.