Практика

Теория

Необходимость методологических руководств

Методология разработки ПО не является новой областью. Ее истоки восходят к известной работе Дейкстры "Go To Statement Considered Harmful" (О вреде оператора Go To) и последующим работам этого же автора и его коллег по структурному программированию. Но не все последующие методологические работы поддерживают достигнутый уровень стандартов.

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

Первая обязанность советчика - давать совет, согласующийся с предметной областью:

Теоретический базис: принцип методологии Правила методологии ПО должны базироваться на теории предметной области.

Пример Дейкстры может служить хорошей иллюстрацией. Он не пытался атаковать оператор Goto по причинам вкуса или чьих либо мнений - он приводил тщательно выверенную систему выводов. Кто-то мог не соглашаться с некоторыми из аргументов, но не мог отрицать, что заключение построено на хорошо продуманном взгляде на процесс разработки ПО. Не считаться с точкой зрения Дейкстры можно лишь при обнаружении изъяна в его теории и построении своей собственной теории для этого случая.

Теория - это дедуктивная часть методологии ПО. Но правила, основанные только на теории, могут быть опасными. Эмпирическая компонента столь же важна:

Практический базис: принцип методологии Правила методологии ПО должны основываться на широком практическом опыте.

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

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

Опыта, анализа или даже анализа и проектирования явно недостаточно. Не один раз приходилось видеть, как консультанты по анализу выполняли свою работу, получали плату, и оставляли компанию с не более чем схемами с квадратиками и стрелками - документом анализа. А затем компания должна была извлекать нечто полезное из этих кусочков и делать свою трудную работу; иногда работа аналитиков оказывалась полностью бесполезной, поскольку не учитывала важных практических ограничений. Подход "только анализ" противоречит фундаментальным идеям бесшовности (seamlessness) и обратимости (reversibility), интегрированному жизненному циклу, характерному для объектной технологии, где анализ и проектирование свиваются с реализацией и сопровождением. Кто не прошел все этапы этого пути, вряд ли может давать методологические советы.

Дата добавления: 2014-12-07