Часть 1 - А зачем?
From The Joel on Software Translation Project
Автор: Joel Spolsky
понедельник, 2 октября 2000г.
Painless Functional Specifications - Part 1: Why Bother?
Перевод - Максим Михальчук
Последняя редакция - 22 октября 2002г.
Когда впервые появился Тест Джоэля, одним из наиболее больных вопросов, по отзывам читателей, было написание спецификаций. Складывается впечатление, что спецификации - как чистка зубов нитью — все знают, что это нужно, но никто не делает.
Почему никто не пишет спецификаций? Все говорят, что они экономят время, пропуская фазу их написания. Они ведут себя так, как будто роскошь написания спецификаций доступна только специалистам по космическим аппаратам или тем, кто работает на огромные и авторитетные страховые компании. Вздор! Во-первых, ненаписанная спецификация — это просто наибольший ненужный риск в программном проекте. Это так же глупо, как пытаться пересечь пустыню Сахару в одних трусах, надеясь «на авось». Разработчики программного обеспечения, целиком погружающиеся в кодирование без написания спецификаций считают себя крутыми стрелками с бедра. Это не так. Они ужасно непродуктивны. Они пишут плохой код и выпускают дрянное ПО, они подвергают их проекты абсолютно необоснованым гигантским рискам.
Я считаю, что если в любом нетривиальном проекте (более недели кодирования или более одного программиста), отсутствует спецификация, то на проект всегда уйдёт больше времени, а полученный код будет низкого качества. И вот почему:
Наиболее важная цель спецификации — спроектировать программу. Даже если вы работаете над кодом в полном одиночестве, и пишете спецификацию исключительно для себя, само написание спецификации — подробное описание работы программы - заставит вас на самом деле спроектировать программу.
Давайте навестим двух воображаемых программистов. Василий Быстров, работающий в «Горячих бананах», никогда не пишет спецификаций. «Спецификации? Нам не нужны эти дурацкие спецификации»! А Алексей Понятный из компании «Хорошо выдержанное ПО» отказывается писать код до того, как спецификация будет расписана от и до. Это всего лишь двое из моих воображаемых друзей.
У Быстрова и Понятного есть нечто общее — они оба отвечают за обратную совместимость версии 2.0 выпускаемых компаниями продуктов.
Вася решает, что лучше всего обратную совместимость реализовать с помощью конвертера, который будет просто-напросто переводить файлы версии 1.0 в формат версии 2.0, и начинает лабать этот код. Пишем, пишем, пишем. Трах, бум, бац. Винчестер трещит. Пыль столбом. Примерно через две недели у него получается более-менее рабочий конвертер. Но заказчики-то, увы, в полном унынии. Код Быстрова заставит их поголовно перейти на новую версию. Самый крупный заказчик, Nanner Splits Unlimited, отказывается покупать новую версию. Им необходимо, чтобы версия 2.0 работала с файлами версии 1.0 без конвертации. Быстров решает написать обратный конвертер, и привязать его к функции сохранения. Это вносит некоторую путаницу, ведь при использовании возможности версии 2.0, всё вроде-бы работает до сохранения в формате 1.0. И только тогда программа сообщает, что возможность, использованная полчаса назад, не будет работать в старом формате файла. Итак, обратный конвертер написан за две лишние недели, и он не работает так хорошо, как хотелось бы. Затрачено 4 недели.
А Алексей Понятный из из компании «Хорошо выдержанное ПО» — один из тех зануд, которые отказываются писать код до получения спецификации. Он тратит примерно 20 минут на описание обратной совместимости такого же характера, как и у Быстрова, и получает спецификацию, которая, по существу, гласит:
- При открытии файла, созданного предыдущей версией ПО, файл преобразовывается в новый формат файла.
Спецификацию показывают заказчику, и тот возражает «Погодите-ка! Мы не хотим переводить всех сразу на новую версию!» Понятный, ещё немного подумав, исправляет спецификацию:
- При открытии файла, созданного предыдущей версией ПО, файл преобразовывается в новый формат файла в памяти. При сохранении данного файла пользователю даётся возможность обратного преобразования.
Ещё 20 минут потрачено.
Начальник Понятного, большой любитель объектного подхода, смотрит на это и понимает, что что-то неладно. Он предлагает другой подход.
- Необходимо разделить код так, чтобы он использовал два интерфейса: V1 и V2. V1 должен содержать все возможности первой версии, а V2, наследник V1, добавит все новые возможности. Тогда V1::Save будет поддерживать обратную совместимость, а V2::Save будет использоваться для сохранения всех новшеств. При открытии файла 1.0 и попытке использования новой функциональности, программа сразу же выдаст предупреждение, что либо файл необходимо конвертировать, либо нужно отказаться от использования этой новой возможности.
Вот ещё 20 минут.
Алексей Понятный раздражён. Этот рефакторинг займёт три недели вместо первоначально запланированных им двух! Но он решит все проблемы пользователей, причём самым лучшим образом, поэтому Алексей берёт и пишет.
Понятному потребовалось 3 недели и один час. Быстрову понадобилось 4 недели, тем не менее его код не так хорош как хотелось бы.
Мораль сей басни такова, что с помощью надуманного примера можно доказать всё, что угодно. Ой, нет! Это не то, что я имел в виду. Мораль в том, что при разработке вашего продукта на человеческом языке для обдумывания нескольких возможностей, исправления и улучшения требуется всего несколько минут. От удаления параграфа в редакторе никому не станет дурно. Но при разработке на языке программирования требуются недели для пересмотра. И что самое плохое, программист, потративший две недели на написание какого-либо кода, становится очень привязан к этому коду вне зависимости от того, насколько код неверен. И ничто, сказанное начальником или заказчиками Быстрова, не смогло бы убедить его выбросить прекрасный конвертирующий код, даже при том, что это была неправильная архитектура. Как результат, готовый продукт — это компромисс между начальным неверным дизайном и идеальным дизайном. «Лучший дизайн, который можно получить, написав весь этот код и не выбрасывая его» совсем не тоже самое, что и «Лучший дизайн, точка».
Итак, это первая громадная причина писать спецификации. Второй большой причиной является экономия времени на общении. При написании спецификации обсуждать то, как должна работать программа, необходимо только один раз. В дальнейшем все члены команды могут просто перечитать спецификацию. В Отделе контроля качества прочитают её для того, чтобы узнать, как должна работать программа, чтобы знать, как её тестировать. Маркетологи на её основе напишут свои бесформенные фантастические статьи для того, чтобы выложить на веб сайт описания ещё не написанных продуктов. В Отделе развития неправильно истолкуют её, причудливо фантазируя о том, как продукт сможет спасти от плешивости и бородавок, но продукт получит инвестиции, так что это нормально. Разработчики прочитают спецификацию и будут знать, какой код писать. Заказчики прочитают её, чтобы убедиться, что за этот продукт стоит платить. Отдел документирования разработок прочитает её и напишет хорошее руководство (его, правда, всё равно никто читать не будет, но это совсем другая история). Менеджеры её прочитают и смогут делать вид на собраниях руководства, будто они в курсе происходящего. И так далее.
Если спецификации нет, то всё это общение всё равно происходит, потому что оно необходимо, но только от случая к случаю. Отдел контроля качества волей-неволей играется с программой, и, когда что-либо выглядит странно, ещё раз отрывает программистов от работы и задаёт им ещё один вопрос о том, как оно должно работать. Кроме того, что это вредит продуктивности программистов, сами программисты обычно дают ответ в соответствии с тем, какой код они написали, а совсем не «верный ответ». Таким образом, Отдел контроля качества тестирует программу на соответствие программе, а не дизайну, что было бы, хм, немного более полезно.
При отсутствии спецификации с бедным отделом документирования происходит нечто забавное (в грустном смысле этого слова). У составителей документации обычно нет политического права прерывать программистов. Во многих компаниях, если у составителей входит в привычку прерывать разработчиков с вопросами, а как что-либо должно работать, программисты направляются к руководству с мольбой о невозможности выполнить работу из-за этих [удалено цензурой] писателей, и не могли бы они, пожалуйста, держать их подальше, и менеджеры, пытаясь улучшить производительность, запрещают составителям документации в дальнейшем тратить драгоценное время их программистов. Такие компании всегда можно отличить, так как файлы справки и руководства не содержат никакой другой информации кроме той, что и так можно увидеть на экране. Когда на экране появляется сообщение
- Хотите ли вы включить поддержку LRF-1914?
... и вы нажимаете кнопку "Справка", появляется трагикомический раздел справки, гласящий что-то вроде
- Позволяет вам выбрать между поддержкой LRF-1914 (по умолчанию) или отсутствием поддержки LRF-1914. Если вы хотите использовать поддержку LRF-1914, выберите "Да" или нажмите "Д". Если вы не хотите использовать поддержку LRF-1914, выберите "Нет" или нажмите "Н".
Хм, спасибо. Вполне очевидно, что составители документации пытались скрыть тот факт, что они не знали, что такое поддержка LRF-1914. Они не могли спросить программиста из-за того, что (a) они смущались или (b) программист в Караганде, а они в Москве, или (c) руководство запретило им прерывать программиста, или же по причине любой другой патологии корпорации, которых слишком много, чтобы упоминать их все, но фундаментальная проблема в отсутствии спецификации.
Третьей из наиболее важных причин за использовние спецификаций является тот факт, что без детальной спецификации невозможно создать план работ. Отсутствие плана подходит для кандидатской диссертации, над которой вы планируете провести лет так 14, или если вы работаете над следующим Duke Nukem и считаете, что мы выпустим продукт, когда он будет хорош и готов. Но для почти любого реального дела просто необходимо знать, как долго будет идти разработка, ведь она стоит денег. Вы не купите даже джинсы, если не будете знать их цену, так как можно ответственно решить, разрабатывать ли продукт, без знания сколько времени это потребует, а, следовательно, сколько он будет стоить? О планах работы читайте в Painless Software Schedules.
Ужасающе всеобщей ошибкой являются дискусии о том, как что-либо должно быть сделано, никогда не оканчивающиеся принятием решений. Брайан Валентин (Brian Valentine), главный разработчик Windows 2000, стал знаменит благодаря своему лозунгу "Decisions in 10 minutes or less, or the next one is free." (Решение за десять минут или меньше, или вы уволены. Следующий!)
Слишком во многих программистских организациях, каждый раз при обсуждении дизайна никто так и не удосуживается принять решение, обычно по политическим причинам. Так что программисты работают исключительно над бесспорным кодом. С течением времени все трудные решения принимаются под давлением обстоятельств. Такие проекты - первые кандидаты на провал. Если новая компания берётся за разработку с новой технологии и заметно, что она по своей природе неспособна принимать решения, лучше сразу её свернуть и вернуть деньги инвесторам, ведь она никогда ничего не выпустит.
Написание спецификации - хороший способ точно выразить все те раздражающие большие и мелкие проектные решения, обычно скрытые в отсутствие спецификации. Даже мелкие решения могут быть точно описаны с помощью спецификации. Например, при разработке веб-сайта с членством, вполне очевидно, что если пользователь забудет пароль, то его необходимо этому пользователю послать. Прекрасно. Но этого недостаточно для написания кода. Чтобы написать код, необходимо знать слова такого письма. В большинстве компаний программистам не доверяют писать слова, которые может увидеть пользователь (и почти всегда, правильно делают). Поэтому специалист по маркетингу или пиарщик, или любой другой хороший специалист по русскому языку должен написать точную формулировку письма. "Господин Кустов, Данным письмом мы сообщаем Вам забытый Вами пароль. Постарайтесь в будущем быть аккуратнее". Если заставлять себя писать хорошую, полную спецификацию (и я скоро расскажу об этом немного более подробно), то Вы либо устраните все подобные случаи, либо, по крайней мере, сможете пометить их большим красным флажком.
Хорошо. Мы всё ещё на этой странице. Спецификации - это материнство и Пасха. Я подозреваю, что большинство людей это понимают, и мои разглагольствования, хоть и занятны, но не учат вас ничему новому. Так почему же никто не пишет спецификации? Не для того, чтобы сэкономить время, ведь это не так, и, я считаю, что большинство программистов это признают. (В большинстве организаций, единственные существующие «спецификации» — это отрывистые документы величиной со страничку, в спешке написанные в Блокноте после написания кода и после объяснения этой треклятой возможности трёхсотому спросившему.)
Как мне кажется, это происходит потому, что довольно много людей не любят писать. Сидеть, уставившись на чистый экран - занятие не для слабонервных. Лично я пересилил свой страх к писанию с помощью занятий на курсах, на которых требовалось написание 3-5 стpaничных рассказов каждую неделю. Писание — как мышцы, чем больше пишешь, тем больше способен написать. Если вам нужно писать спецификации, а вы не можете, заведите дневник, создайте блог, пойдите на уроки творческого письма или просто напишите приятное письмо каждому родственнику и однокашнику, с которыми вы не виделись четыре года. Любое действие, включающее в себя запись слов на бумагу, улучшит ваши способности по написанию спецификаций. Если Вы - менеджер по разработке и те, кто должен писать спецификации, их не пишут, пошлите их на курсы творческого письма куда-нибудь в горы.
Если вы никогда не работали в компании, в которой пишут функциональные требования, возможно, вы никогда их и не видели. В следующей статье данной серии я покажу Вам короткий пример спецификации, и мы поговорим о том, что должно быть в хорошей спецификации.
