7 ПРИЗНАКОВ ПЛОХОГО ПРОЕКТА
С признаками плохого проекта по Мартину из его книги “Быстрая разработка программ” встречался каждый разработчик, но не каждый может действительно в должной мере противостоять этой зловещей семерке. Более того, даже сам Мартин не в силах на все сто противостоять этой семикратной коррозии, которая пожирает строку исходного кода за строкой, проект за проектом. К сожалению, это вопрос лишь времени.
Вот, что неизбежно в той или иной степени ожидает проект на оси времени (выделено автором):
- Закрепощенность: система с трудом поддается изменениям, поскольку любое минимальное изменение вызывает эффект “снежного кома”, затрагивающего другие компоненты системы.
- Неустойчивость: в результате осуществляемых изменений система разрушается в тех местах, которые не имеют прямого отношения к непосредственно изменяемому компоненту.
- Неподвижность: достаточно трудно разделить систему на компоненты, которые могли бы повтроно использоваться в других системах.
- Вязкость: сделать что-то правильно намного сложнее, чем выполнить какие-либо некорректные действия.
- Неоправданная сложность: проект включает инфраструктуру, применение которой не влечет непосредственной выгоды.
- Неоправданные повторения: проект содержит повторяющиеся стуктуры, которые могут унифицироваться с применением простой абстракции.
- Неопределенность: проект трудно читать и понимать, недостаточно четко выражено содержимое проекта.
Но у меня есть и хорошие новости. Мы можем упешно минимизировать вышеуказанные признаки и их последствия. Все в наших руках и все зависит от нас, ибо кадры решают все, а не Мартины со своими признаками. Для этого лишь надо заставлять себя постоянно аудировать исходный код проекта по этим признакам. Днем и ночью. При малейшем сомнении стараться выправить ситуацию.
Плохое имя у функции – вот так будет лучше. Криво написан цикл – уже переписал. Неправильно отформатирован текст процедуры – исправил. Неудачный заголовок – новый лучше. Пакет зависит от другого – подумал как надо и устранил зависимость. Хотелось бы использовать вот такой вот компонент, но он в библиотеке, в которой три сотни компонентов – отказался от его использования вообще! И так далее…
Но самое главное на мой взгляд – априори думать о предстоящих в проекте изменениях, а не о требуемой функциональности на текущий момент.
Ссылки:
