Когда комментарии заменяют или дополняют сопроводительную документацию

Сюда относятся шапки над функциями и другими объектами кода (структурами, модулями, классами). Например:

//********************************************************************************

// Данный модуль содержит различные вспомогательные математические функции

// Создан: Ивановым И. И.

// Дата последнего изменения: 16.09.2005

//********************************************************************************

 

// Данная функция генерирует случайную величину,

// распределенную по нормальному закону

// average – мат. ожидание

double NormalRandom(double average)

{

…

}

…

Некоторые среды разработки, при выборе такой функции показывают подсказку с текстом, написанным в комментарии.

Также существуют средства, позволяющие генерировать по тексту программы с такими комментариями сопроводительную документацию. В Visual Studio.NET, если ввести ///, автоматически создается шапка для комментариев функции с тэгами xml. С помощью утилиты, входящей в Visual Studio.NET можно сгенерировать документацию из этих комментариев.

Гибкие методологии разработки

Традиционный подход к разработке

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

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

1) Требования к программному обеспечению очень часто меняются в процессе работы над проектом

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

2) Разработка детализированной архитектуры занимает очень много времени

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

3) Не используется гибкость программного обеспечения

Программное оеспечение (software) происходит от слова soft – мягкий, поскольку в отличие от аппаратного обеспечения (hardware – нечто твердое) оно легко поддается изменениям. Однако, традиционные подходы к программному обеспечению отказываются от этой уникальной возможности, препятствуя изменениям.

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

Гибкие подходы к разработке

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

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

Гибкие методологии обладают следующими преимуществами:

1. Обратная связь

Работающая система дает обратную связь, позволяющую на раннем этапе обнаружить ошибки или неправильно понятые требования.

2. Возможность изменений

Если в процессе работы выяснится, что в системе нужно что-то изменить, это гораздо проще сделать.

3. Качество архитектуры

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

4. Психологический аспект

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

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

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

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

 

Опасности гибких методологий

Не смотря на все преимущества, гибкие методологии подход таят в себе серьезные опасности:

1. Недостаточное внимание предварительному проектированию

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

Хорошая статья на эту тему: Мартин Фаулер «Проектирования больше нет» (Is Design dead?).