Безболезненные функциональные спецификации – Часть 1: Зачем беспокоиться?

Автор: Джоэл Сполски

Переводчик: Андрей Шкуропий

2 октября 2000

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

Почему люди не хотят писать спецификации? Они утверждают, что экономят время, пропуская эту стадию разработки. Люди ведут себя так, словно создание спецификаций – это роскошь, позволительная только для инженеров NASA, проектирующих космические шаттлы, или сотрудников крутых страховых компаний. Чепуха. Прежде всего, отказ от написания спецификаций – это ваш самый большой ненужный риск при разработке программного продукта. Это так же глупо, как намерение перейти пустыню Мохаве, взяв с собой в рюкзаке только постельное белье, и в надежде импровизировать по пути. Программисты, которые погружаются в кодирование без написания спецификации, склонны думать, что они похожи на крутых гангстеров, стреляющих с бедра. Это не так. Они ужасно непродуктивны. Они пишут плохой код, выпускают низкопробное ПО и подвергают свои проекты совершенно неоправданному риску.

Наиболее важная функция спецификации – проектирование программы (design the program). Даже если вы работаете один, и пишете спецификацию исключительно для себя, процесс ее написания – описание того, как работает программа до мельчайших подробностей – заставит вас непосредственно проектировать программу.

Давайте проведаем двух воображаемых программистов в двух компаниях. Программистка Быстрякова, из компании «Скороспелые Бананы Софт», никогда не пишет спецификации. «Спецификации? Нам не нужны никакие вонючие спецификации!». А вот господин Разумихин из компании «Хороший Характер Софт», отказывается писать код, пока спецификация не будет полностью готова. Это только двое из многих моих воображаемых друзей.

У Быстряковой и Разумихина есть нечто общее: они заботятся о проблеме обратной совместимости для версии 2.0 своих разрабатываемых продуктов. Быстрякова решает, что наилучший способ обеспечить обратную совместимость – написать конвертер, который просто преобразует файлы версии 1.0 в файлы версии 2.0. Она сразу приступает к реализации. Пишет, пишет, пишет. Клик-клик-клик по клавишам. Жесткий диск крутится. Пыль летит. После примерно 2 недель работы у нее есть сносный конвертер. Но заказчики Быстряковой недовольны. Ее код заставляет всех сотрудников в их компании сразу переходить на новую версию программы. Самый большой заказчик Быстряковой, компания «Разборные Детали Анлимитед», отказывается покупать новую программу. Ребята из «Разборных Деталей» хотят быть уверены, что программа версии 2.0 будет продолжать обрабатывать файлы, созданные в версии 1.0, не преобразуя их в новый формат. Быстрякова решает написать обратный конвертер и затем нацепить его на функцию «Сохранение файла». Это привносит путаницу, потому что когда вы добавляете в файл, созданный под версией 2.0, новшества этой версии, они выглядят работающими, пока вы не начнете сохранять файл в формате версии 1.0. Только тогда вам будет выведено сообщение, что свойство, которое вы внесли в файл полчаса назад, не может быть сохранено в старом формате файла. Итак, разработка обратного конвертера заняла еще две недели, и этот конвертер работает не так уж хорошо. Потраченное время – 4 недели.

В то же время, господин Разумихин из компании «Хороший Характер Софт» (сокращенно, «ХХС») – один из тех занудных типов, которые отказываются писать код, пока не будет готова спецификация. Он тратит 20 минут, проектируя функцию обратной совместимости, так же как делала Быстрякова, и выдает спецификацию, которая гласит:

Спецификация показывается заказчику, который говорит «Минуточку! Мы не хотим сразу переходить на новый формат!». Г-н Разумихин размышляет еще немного и вносит поправку:

Потрачено еще 20 минут.

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

Еще 20 минут.

Г-н Разумихин рассержен. Эта переработка займет 3 недели вместо 2 изначально запланированных! Но она элегантно решит все проблемы заказчика, так что он идет и выполняет ее.

В итоге г-н Разумихин потратил: 3 недели и 1 час. Потраченное время Быстряковой: 4 недели, но ее программа далеко не так хороша.

Мораль сей сказки такова: надуманный пример может доказать все, что угодно. Ой. Я не то хотел сказать. Мораль истории в том, что когда вы проектируете ваш программный продукт на человеческом языке, вам нужно всего несколько минут, чтобы попытаться вдуматься в альтернативные пути, исправить ошибки и улучшить разработку. Никто не чувствует дискомфорт, когда удаляет абзац в текстовом редакторе. Но когда вы проектируете продукт на языке программирования, итерационная разработка займет недели. Хуже всего, что программист, который потратил 2 недели на написание определенного кода, привязывается к нему душой, независимо от того, насколько тот неправильный. Неважно, что скажут начальник и заказчики Быстряковой. Они не убедят ее выбросить прекрасный код конвертера, даже если он имеет не самую лучшую архитектуру. В результате конечный продукт имеет тенденцию становиться компромиссом между изначально неправильной разработкой и идеальной разработкой. Это было «лучшей разработкой, которую мы могли получить, учитывая то, что мы уже написали весь этот код, и мы просто не хотим его выбрасывать». Это звучит не так хорошо, как «самая лучшая разработка, которую мы могли получить. Точка».

Если у вас нет спецификации, все эти информационные потоки продолжают идти, потому что они должны идти, но это происходит вынужденно (ad hoc). Команда тестеров волей-неволей просто играется с программой, и когда что-то выглядит странным, они снова и снова идут и отрывают программистов от работы, чтобы задать им еще один глупый вопрос о том, как это должно работать. Кроме того, что это , они скорее всего попытаются дать не «правильный ответ», а ответ с позиций своего кода. Так что тестеры на самом деле тестируют не программу по плану разработки, а программу по плану самой программы (testing the program against the program rather than the program against the design), хотя первый вариант был бы, э-э, немножечко полезнее.

Если у вас нет спецификации, самое смешное (сквозь слезы) происходит с несчастными сотрудниками отдела технической документации, которые часто не имеют привилегии отрывать программистов от работы. Во многих компаниях случается так, что сотрудники ОТД заводят плохую привычку отвлекать программистов, чтобы спросить у них, как что-либо должно работать, а программисты потом бегут к своим менеджерам и хнычут о том, как они не могут ничего закончить из-за этих [вырезано цензурой] писателей из ОТД, и просят держать их подальше. И менеджеры, пытаясь увеличить продуктивность, запрещают этим жертвам поклепа тратить драгоценное время программистов. Вы всегда можете отличить такие компании, потому что их файлы помощи и руководства не дают вам больше информации, чем вы можете получить с экрана программы. Когда вы видите сообщение на экране, которое гласит

…и вы нажимаете кнопку «Помощь», то показывается трагикомический раздел помощи, который говорит что-то вроде

М-да. Спасибо. Здесь хорошо видно, что создатель справки пытался скрыть тот факт, что он на самом деле не знает, что такое поддержка LRF-1914. И они не могут спросить у программистов, потому что (а) стесняются спросить, или (б) они находятся в Лондоне, а программисты - в Хайдарабаде (примеч. переводчика – город в Индии), или (в) им менеджер запретил отрывать программистов от работы, или из-за любых других корпоративных патологий, которых так много, что их невозможно все перечислить, но главная проблема в том, что у них нет спецификации.

Огромная важная причина номер три написать спецификацию – без детальной спецификации невозможно составить план. Отсутствие плана не проблема, если вы пишете кандидатскую диссертацию и рассчитываете за ближайшие 14 лет ее закончить, или если вы программист, работающий над следующей версией игры Duke Nukem (мы выпустим ее, когда все будет готово и сделано на высшем уровне). Но почти в любой отрасли реального бизнеса вы просто обязаны знать, как долго все будет продолжаться, потому что разработка продукта стоит денег. Вы даже джинсы себе не купите, не узнав, сколько они стоят, так как же ответственный бизнесмен может принять решение, создавать или не создавать продукт, без информации о том, сколько это займет времени, и, следовательно, сколько это будет стоить? Более глубоко эта тема развита в статье .

Ужасно распространена следующая ошибка: разработчики долго обсуждают, каким образом что-то должно быть реализовано, но после этого никогда не принимают решение. Брайан Валентайн (Brian Valentine), один из руководителей разработки Windows 2000, прославился своей «Принимайте решение за 10 минут или меньше, иначе не решайте вообще».

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

Написание спецификации – прекрасный способ точно выразить все эти раздражающие вопросы разработки, большие и маленькие, которые захлестнут вас, если у вас нет спецификации. Даже маленькие решения могут быть выражены в спецификации. К примеру, если вы создаете веб-сайт с регистрацией, все согласятся, что если пользователь забывает свой пароль, то вы его высылаете по электронной почте. Прекрасно. Но этого недостаточно для написания кода. Чтобы написать код, вы должны знать слова, которые будут в письме с паролем. В большинстве компаний программистам не доверяют писать слова, которые увидит конечный пользователь (и, чаще всего, правильно делают). Так что обычно требуется маркетолог или пиарщик, или другой специалист в языке, чтобы написать точную словесную формулировку. «Уважаемый г-н Иванов, вот пароль, который вы забыли. Постарайтесь не быть столь беспечным в будущем». Когда вы заставляете себя писать хорошую, полную спецификацию (и я расскажу об этом гораздо больше в дальнейшем), вы уделите внимание всем этим вещам и либо исправите их, либо пометите большой красной галочкой.

Так-с. Теперь мы на одном уровне. Спецификации – это мать всего. Я подозреваю, что большинство людей понимает это, и мои разглагольствования занимательны, но не учат вас ничему новому. Так почему же люди не пишут спецификации? Не для того, чтобы сэкономить время, потому что это не экономит время, и я думаю, многие кодеры осознали это. (В большинстве организаций единственные «спецификации» – это короткий, на одну страницу документ, который программист набил в Блокноте после написания кода и после объяснения этой долбаной возможности программы трем сотням человек).

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

В английском оригинале статья называется