Процесс разработки или… разрабатываем процесс!
Александр Родыгин,
Как правило, в публикациях для программистов сам процесс разработки не упоминается, так как этот вопрос обычно относится к компетенции управляющего персонала: менеджеров проекта. Я рассматриваю его из-за происходящих в данное время грандиозных событий в области методологии разработки программного обеспечения, которые стирают границы между менеджерами и разработчиками как таковыми в целях обеспечения высокого качества продукта на протяжении всего цикла разработки. То есть, согласно последним исследованиям, часто оказывается гораздо эффективнее привлекать программистов к координации усилий, нежели руководить ими с позиции управляющего.
Под методологией подразумевается набор методов и критериев оценки, которые используются для постановки задачи, планирования, контроля и в конечном итоге достижения поставленной цели. Схематично процесс разработки описывается моделью, которая определяет последовательность наиболее общих этапов и получаемых результатов.
Чтобы понять, почему уделяется такое большое внимание методологии разработки, и создаются новые модели, необходимо рассмотреть исторические аспекты этой проблемы и постараться понять, какие меры применялись для того, чтобы гарантировать удачное завершение проекта в поставленные сроки. То есть нужно разобраться с тем, что представляет собой процесс программирования и как им управлять.
Какие особенности характеризуют программирование как сферу деятельности? По-моему мнению, наиболее резко выделяются такие аспекты:
Описанный механизм может быть реализован либо в рамках существующих языков программирования с проведением необходимого анализа на возможность интеграции с существующим окружением, либо в новых языках. Вот как это может выглядеть в контексте С++ (в качестве примера выбран operator==(), который задает условие логической константности):
В классе Personal переопределен оператор сравнения, который задает условие логической неизменности. В операторе проверяется, что логическое содержание объектов эквивалентно (несмотря на то, что на момент проверки данные могут быть не загружены в память). Также отметим, что переопределение операторов копирования и сравнения не является специальной реализацией этих методов для поддержки предлагаемого механизма. Такая их реализация продиктована семантикой интерфейса Personal; мало проку при сравнении двух персон сравнивать значения указателей вместо содержимого изображений. Если необходим метод, осуществляющий сравнение физического содержания всех полей, его можно реализовать дополнительно. В данном случае объект имеет пять константных методов; четыре из них (ReadPictureFromFile, Name, Age, operator==) будут проверены на стадии компиляции, а пятый, метод Picture, - во время выполнения в соответствии с заданным в operator== условием неизменности (при его реализации была использована инструкция mutable).
Плюсы предложенного подхода: используется специальный механизм, что позволяет компилятору контролировать неизменность; в большинстве случаев это будут ошибки компиляции, в ряде случаев ошибки времени выполнения; не нужно делить интерфейс на два - меньше работы программисту; количество проверок времени выполнения по сравнению с вариантом Eiffel невелико и равно количеству случаев, когда физическая неизменность не совпадает с логической, вследствие чего нет потерь в скорости работы; механизм не конфликтует с рядом специфичных для объектно-ориентированного подхода принципов, например, с ковариантным переопределением параметров.
Минусы: в отладочной версии, когда физическая неизменность не совпадает с логической и для хранения информации о состоянии проверяемого объекта требуется большой объем памяти, возможно значительное потребление ресурсов, что может сказаться на скорости работы программы.
Проблеме неизменности посвящено множество публикаций [5-9]. Представленный вариант снимает имеющиеся трудности и может быть использован для решения проблемы обеспечения свойства неизменности для объектов.