Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

Итак, мы сели за компьютер, и я спросил, что должно делать его приложение. Том начал с экрана ввода данных. Я показал, как создать текстовый файл со сценарными командами и как ввести в сценарий символьное представление команд редактирования. Но когда я взглянул ему в глаза, ответный взгляд был совершенно пустым. Он не понял ни единого слова из моего объяснения.

Тогда я впервые встретился с этим явлением. Для меня символьное представление команд редактирования было простым и естественным: например, для представления команды Control+B (команда перемещения курсора в начало текущей строки) в файл сценария просто включались символы ^B. Но Тому это казалось бессмысленным: он не мог перейти от редактирования файла к редактированию файла, который редактировал файл.

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

Мало-помалу я начал сам реализовывать приложение Тома, пока он сидел и наблюдал. Через 20 минут стало ясно, что он уже думает не о том, как сделать все самому, а о том, как объяснить мне , что именно ему нужно.

На это ушел целый день. Том описывал некоторую возможность, а я реализовывал ее, пока он наблюдал. Рабочий цикл составлял не более 5 минут, поэтому ему не нужно было отходить и заниматься чем-то другим. Он просил меня сделать X, и через 5 минут реализация X работала.

Часто Том рисовал то, что он хотел, на листке бумаги. Некоторые из его требований было трудно реализовать средствами ED-402; тогда я предлагал что-то другое. В конечном итоге мы договаривались до чего-то, что могло работать, и я реализовывал согласованный вариант. Но потом мы опробовали его, и Том менял свое решение. Он говорил что-нибудь вроде: «Да, но это не совсем то, что мне нужно. Давай попробуем иначе». Час за часом мы пробовали, экспериментировали и придавали приложению нужную форму. Мы опробовали одно, потом другое, потом третье. Вскоре мне стало абсолютно ясно, что Том – скульптор, а я – инструмент в его руках.

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

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

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

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

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

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

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

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

Между ключевыми участниками проекта часто возникают разногласия. В таких случаях часто бывает проще «заговорить» проблему, чем решать ее. Они находят такую формулировку требования, с которой будут согласны все, без реального разрешения спора. Однажды я слышал, как Том Демарко сказал: «неоднозначность в документе с требованиями появляется из-за разногласий между участниками [34]».

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

Сэм(ключевой участник проекта): «Так, еще нужно организовать резервное копирование журнальных файлов».

Пола: «С какой частотой?»

Сэм: «Ежедневно».

Пола: «Понятно. И где будут храниться резервные копии?»

Сэм: «В смысле?»

Пола: «Наверное, они должны сохраняться в определенном подкаталоге?»

Сэм: «Да, пожалуй».

Пола: «И как он будет называться?»

Сэм: «Может, backup?»

Пола: «Да, нормально. Значит, журнал будет ежедневно сохраняться в каталоге backup. В какое время?»

Сэм: «Ежедневно».

Пола: «Нет, в какое именно время суток?»

Сэм: «В любое».

Пола: «В полдень?»

Сэм: «Нет, только не во время торгов. Лучше в полночь».

Пола: «Хорошо, пусть будет полночь».

Сэм: «Отлично, спасибо!»

Пола: «Всегда рада помочь».

Позднее Пола рассказывает о задаче своему коллеге Питеру.

Пола: «Значит, журнал должен копироваться в подкаталог с именем backup ежедневно в полночь».