Джоэл о программном обеспечении

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


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

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

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

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

2 октября 2000

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

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

Я уверен, что на любой нетривиальный проект (на который отведено больше 1 недели кодирования или больше 1 программиста), если у вас нет спецификации, вы всегда потратите больше времени и напишете код худшего качества. И вот почему.

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

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



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

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

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

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

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

  • Код будет построен так, чтобы использовать два интерфейса: V1 и V2. V1 содержит все функции первой версии, а V2, который наследуется от V1, добавляет все нововведенные функции. Теперь метод V1::Save будет использоваться для обратной совместимости, а V2::Save может быть использован для сохранения всех нововведений версии 2. Если пользователь откроет файл через V1 и попытается использовать функциональность из V2, программа его об этом предупредит, и он вынужден будет либо конвертировать файл, либо прекратить использование нововведений второй версии.
  • Еще 20 минут.

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

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

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

    Так что вот вам огромная причина номер раз, чтобы написать спецификацию. Огромная причина номер два – спецификации сокращают информационные потоки. Когда вы пишете спецификацию, вы должны только один раз выяснить, как программа работает. Каждый член команды может потом просто почитать спецификацию. Команда тестеров читает ее, чтобы узнать, как программа должна работать, и что надо тестировать. Маркетологи используют ее, чтобы писать свои мутные обзоры готовящейся к выпуску программы, которые выкладываются на веб-сайте. Бизнесмены неправильно истолкуют ее, и нафантазируют о том, как выпуск продукта покроет все издержки (но это в конечном счете привлечет инвесторов, так что все нормально, пусть фантазируют). Разработчики читают ее, чтобы узнать, какой код писать. Заказчики читают ее, чтобы удостовериться в том, что разработчики создают продукт, за который они захотят заплатить. Сотрудники отдела технической документации читают ее и пишут хорошее руководство к программе (которое потом теряется или выбрасывается, но это уже другая история). Менеджеры читают ее и в результате могут сделать вид, что понимают, о чем идет речь на заседаниях правления. И так далее.

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

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

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

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

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

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

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

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

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

    Я думаю, это потому что люди просто не любят писать. Пустой экран с курсором ужасно расстраивает. Лично я победил свой страх перед чистым листом, пройдя курс обучения в колледже, который требовал написания очерков на 3-5 страниц каждую неделю. Письмо – это тренировка. Чем больше вы пишете, тем больше вы можете написать. Если вам нужно написать спецификацию, а вы не можете, то заведите дневник, создайте свой блог, пойдите на курсы творческого письма, или просто напишите хорошие письма своим родственникам и бывшим соседям по институтскому общежитию, о которых вы не вспоминали последние 4 года. Все, что заставляет вас писать слова на бумаге, улучшит ваши навыки создания спецификаций. Если вы менеджер по разработке ПО, а люди, которые обязаны писать спецификации, не могут это делать, то отправьте их на какие-нибудь курсы творческого письма.

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



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


    Джоель Спольски - основатель Fog Creek Software, небольшой компании по
    разработке программного обеспечения, расположенной в Нью-Йорке.
    Окончил Йельский Университет, работал программистом и управляющим в
    Microsoft, Viacom и Juno.

    Содержимое этих страниц представляет собой мнение одного человека.
    Всё содержимое Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

    FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky



    Содержание раздела