Спецификация программы – это процесс приема требований и сокращения их до точки, в которой навык программиста может взять вверх. Это акт передачи информации, объяснения и прояснения в целях устранения основных неоднозначностей. Подобно разговору с разработчиком, который будет осуществлять первоначальную реализацию, спецификация является скрижалью для будущих поколений программистов, которые будут заниматься сопровождением и усовершенствованием программы. Спецификация представляет собой также и соглашение с пользователем – это кодификация их потребностей и негласный контракт, говорящий о том, что окончательная версия системы будет соответствовать тем же требованиям.
      Составление спецификации – это большая ответственность.
      Проблема состоит в том, что многим проектировщикам трудно остановиться. Они полагают, что, пока каждая второстепенная деталь не будет выявлена до мельчайших подробностей, они даром получают свои деньги.
      Это является ошибкой по ряду причин. Во-первых, наивно полагать, что спецификация вообще способна зафиксировать каждую подробность некой системы или предъявляемых к ней требований. В узких предметных областях существуют формальные методы, с помощью которых можно описать систему, но для объяснения смысла обозначений конечным пользователям все равно требуется проектировщик – все еще имеет место человеческий фактор. И даже в отсутствии проблем, присущих этой версии, маловероятно, что средний пользователь точно знает, что ему нужно от этого проекта. Заказчики могут сказать, что осознают суть требований и подписаться под 200-страничным документом, составленным вами, но можете быть уверены – как только они увидят систему в работе, вы будете завалены просьбами о внесении изменений.
      Во вторых, существует проблема выразительности самого языка. Все методики составления диаграмм и формальные методы все еще полагаются на выражение проводимых операций средствами естественных языков . А естественный язык не приспособлен для этого. Посмотрите на формулировку любого контракта: юристам приходится коверкать язык самым неестественным способом, стараясь быть точными.
      Проблемный вопрос для вас. Напишите короткую инструкцию по завязыванию бантиком шнурков на ботинках. Попробуйте!
      Если вы хоть чем-то похожи на нас, то скорее всего, сдадитесь, дойдя примерно до этого места: "Теперь оберните большой и указательный пальцы так, чтобы свободный конец шнурка проходил под левым шнурком во внутреннюю петлю…" Это феноменально трудное задание. И все же большинство из нас могут зашнуровать ботинки, не напрягая мозги.
 

      Подсказка 57: Некоторые вещи лучше сделать, чем описывать

 
      И наконец, существует "эффект смирительной рубашки" – конструкции, которая не оставляет кодировщику пространства для импровизации и отнимает усилия программирования любого рода. Кое-кто говорит, что хотел как лучше, но он неправ. Зачастую лишь на стадии написания текста некоторые варианты становятся очевидными. Во время написания программы вы можете подумать следующее: "Посмотрим вот сюда. Поскольку я написал эту подпрограмму именно таким образом, я смог добавить эту функциональную возможность практически без усилий". Или: "В спецификации говорится, что нужно сделать вот это, но я смог добиться практически того же результата, сделав по-другому, но затратил на это вдвое меньше времени". Ясно, что вы не обязаны вносить изменения, но у вас не было бы и намека на эту возможность, если бы ваши действия сдерживались конструкцией, изобилующей предписаниями.
      Будучи прагматиком, вы должны стремиться рассматривать сбор требований, проектирование и реализацию как различные ипостаси одного процесса – поставки заказчику качественной системы. Не воспринимайте как изолированные друг от друга те среды, в которых происходит сбор требований, составление спецификаций и создание программ. Вместо этого постарайтесь принять «бесшовную» технологию: спецификация и реализация просто являются разными аспектами одного и того же процесса – попыткой зафиксировать и кодифицировать некое требование. Каждый из этих аспектов должен плавно переходить в другой без искусственных границ. Вы обнаружите, что в жизнеспособном процессе разработки поощряется обратная связь, идущая от реализации и тестирования к процессу составления спецификации.
      Поймите нас правильно, мы не против искусственного генерирования спецификаций. Разумеется, мы признаем, что в ряде случаев необходимы невероятно подробные спецификации – в силу причин, обусловленных контрактом, из-за операционной системы, в которой вы работаете, или природы самого продукта, разработкой которого вы занимаетесь . Просто осознайте, что по мере того как спецификации становятся все более подробными, их доходность начинает убывать, а то и уходит в минус. Кроме того, будьте осторожны при составлении многослойных спецификаций, нижние уровни которых не обеспечены реализацией или прототипами; слишком легко составить спецификацию того, что невозможно построить.
      Чем дольше вы будете позволять спецификациям оставаться защитной оболочкой, предохраняющей разработчиков от кошмарного мира составления программ, тем сложнее будет перейти к решению задач, возникающих при составлении программ. Не окажитесь в этой спирали спецификации: в некоторой точке вам придется начать программирование! Если ваша команда будет облачена в теплые, удобные спецификации, разорвите эти оковы. Подумайте о создании прототипов или о разработке с использованием метода "стрельбы трассирующими".

Другие разделы, относящиеся к данной теме:

      • Стрельба трассирующими

Вопросы для обсуждения

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

Какова отдача от методов?

Нужно ли использовать формальные методы?

41
Команды прагматиков