четверг, 28 апреля 2011 г.

Семь приниципов разработки программного обеспечения



В основу статьи положена публикация Девида Хукера «Seven Principles of Software Development»

Принцип первый: Причина для всего этого существует
Любой программный продукт существует по одной причине: он нужен пользователям. Все принимаемые решения должны учитывать эту истину. Прежде чем определять требования к системе, прежде чем рассматривать какую-то часть функциональности системы,  прежде чем определять целевую аппаратную платформу или процессы используемые на этапе разработки, задайте себе вопрос: «ЭТО ДЕЛАЕТ СИСТЕМУ БОЛЕЕ ЦЕННОЙ?» И если ответ «нет», выбросьте то, о чем вы думали перед тем, как задали себе этот вопрос. Все последующие принципы базируются на данном принципе.

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

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

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

Принцип пятый: Будьте открыты для будущего
Система с продолжительный жизненным циклом стоит дороже. В сегодняшних реалиях, когда спецификации изменяются буквально налету, а аппаратные платформы устаревают уже по прошествии нескольких месяцев, жизненный цикл программных продуктов исчисляются не годами, а месяцами. Однако, промышленные программные системы создаются для эксплуатации на более длительное время. Что бы такие системы не потеряли свою актуальность, они должны быть готовы к адаптации к различным изменениям. Системы которые могут подвергаться изменениям, проектировались такими с самого начала. Никогда в процессе проектирования не загоняйте себя в угол. Всегда задавайте себе вопрос: «А что если», и находите на эти вопросы все возможные ответы и с их учетом проектируйте вашу систему, делая ее способной решать общие проблемы и вопросы, а не только частные. Очень вероятно, что после этого многие компоненты системы можно будет использовать повторно в других системах.
Не стоит также забывать, что данный принцип может быть понят не всегда корректно. К примеру, разработчики могут предположить не совсем корректный путь развития системы, и ее реализация будет нести в себе не нужный никому балласт. По возможности, подобных ситуаций нужно избегать.


Принцип шестой: Заранее планируйте повторное использование
Повторное использование экономит время и затраченные усилия. Добиться высокого уровня повторного использования кода – это, пожалуй, труднейшая задача в разработке программного обеспечения. Главным достоинством использования объектно-ориентированных технологий является повторное использование кода и применяемых подходов. Однако, подобная отдача не является автоматической. Для того, что бы добиться преимуществ использования OO необходимо тщательное планирование. Существует огромное количество техник реализации повторного использования процессов разработки на всех уровнях системы. Техники, относящиеся к уровню кода и проектирования, хорошо известны и задокументированы. Доступная сегодня литература описывает повторное использование в форме паттернов проектирования. Однако это всего лишь одна сторона медали. Обсуждение с коллегами вопросов повторного использования имеет первостепенное значение. Как вы можете повторно использовать что-то не зная, что оно существует? Предварительное планирование повторного использования уменьшает затраты и увеличивает стоимость как компонентов, которые можно повторно использовать, так и всей системы, где эти компоненты применяются.

Принцип седьмой: Думайте!
Последний принцип вероятно самый не очевидный. Тщательное продумывание какого то действия перед выполнением этого действия почти всегда делает результат лучше. Когда вы что то продумываете, вероятность того что вы сделаете это правильно возрастает. Вместе с этим у вас появляется устойчивое понимание того, как нужно сделать данное действие, когда вы столкнетесь с ним в будущем. Если вы что-то тщательно продумываете, но в результате все равно терпите неудачу, вы приобретаете неоценимый опыт который поможет вам в будущем. Вместе с тем, подобным образом вы учитесь находить правильное решение в случаях, когда оно не лежит на поверхности. Если система хорошо продумана, ее стоимость возрастает. Применение предыдущих шести принципов невозможно без «включения мозгов», а без них невозможно достичь желаемых высот.