Прецеденты в спецификации программ

 

Предисловие

 

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

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

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

При всем при том использование самого мощного и выразительного языка еще не дает гарантии успеха: на C# при должном старании можно написать не менее запутанную программу, чем на Fortran IV с его бесконечными метками и переходами GOTO. Все эти блестящие инструменты бесполезны в руках человека, который не обучен ими владеть (и при этом особо не жаждет научиться). Много ли, к примеру, вы видели фрезеровщиков-самоучек? Лично я — нет, поскольку к станку не допустят человека, не прошедшего должное профессиональное обучение и не получившего соответствующее удостоверение. В программировании, к сожалению, на самотек обучение ставится гораздо чаще. То ли само ремесло кажется проще фрезеровки, то ли предполагаемый ущерб меньше: ни станок не запорет, ни сам не покалечится, а кривую программу и стереть недолго.

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

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

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

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

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

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

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

 

Спецификации

 

Собственно, это достаточно широкое и расплывчатое понятие. Например, в Большой советской энциклопедии читаем: Спецификация (позднелатинского specificatio, от лат. species — вид, разновидность и facio — делаю), 1) определение и перечень специфических особенностей, уточнённая классификация чего-либо (дальнейшее, увы, к делу не относится). В дальнейшем мы будем употреблять это слово именно в данном смысле — как перечень всех свойств и функций некоего продукта, который мы хотим получить в результате разработки.

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

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

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

 

⇐ Предыдущая12345678Следующая ⇒

Поделиться: