4. Признаки плохого проекта.

Диагноз «загневания» программы устанавливается в случае обнаружения одного из следующих признаков:

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

Признак плохого проекта часто определяется на субъективной основе. Давольно часто появляющаяся в данном случае проблема явл.следствием нарушения одного или большего кол-ва принципов. Устранение принципов плохого проекта производиться путем приминения принципов (персональной ответственности, открытия-закрытия, подстановки Liskov, инверсия зависимости, отделение интерфейса) командами разработчиков ПО. Закрепощенность Закрепощенность проявляется в том случае, когда программа с трудом подда­ется изменениям, производимым с помощью простых методов. Проект становится жестким, если одно изменение влечет за собой каскад последующих изменений в зависимых модулях. Чем больше модулей подвержено изменениям, тем более жестким считается проект. Неустойчивость Неустойчивость при внесении одного изменения программа "разрушается" во многих местах. Очень часто новые проблемы возникают в тех областях, которые не связаны с изменяемым компонентом. В процессе исправления этих ошибок возникают новые ошибки. По мере возрастания неустойчивости программного модуля вероятность появ­ления непредвиденных проблем приближается к 100%. Несмотря на всю абсурд­ность подобного утверждения, подобные модули встречаются довольно часто. Неподвижность Проект считается неподвижным, если он содержит компоненты, которые мо­гут применяться в других системах, однако усилия и степень риска, связанные с изоляцией этих компонентов от первоначальной системы, слишком велики. К со­жалению, эта тенденция проявляется весьма часто. Вязкость Вязкость может проявляться в двух формах: по отношению к ПО и к среде. В случае необходимости внесения изменений разработчики, как правило, при­меняют различные методы. Некоторые из них способствуют сохранению исход­ного проекта, а другие — нет (поскольку относятся к разряду хакерских приемов). Если предлагаемые проектом методы сложнее в применении, чем хакерские прие­мы, то говорят, что вязкость проекта чрезвычайно высока. В этом случае легко до­пустить ошибку, а нужные и корректные действия выполнить не так уж и просто. В идеале требуется разработка программы, допускающих внесение изменений, сохраняющих структуру проекта. Симптом вязкости наблюдается в случае, если среда разработки характери­зуется словами "медленный" и "неэффективный". Неоправданная сложность Проект имеет неоправданную сложность, если содержит элементы, не исполь­зующиеся в настоящий момент времени. Это часто происходит в том случае, когда разработчики предвидят изменения в требованиях и проводят мероприятия, на­правленные на то, чтобы справиться с этими потенциальными изменениями. На первый взгляд кажется, что это неплохо. В конце концов, подготовка к предстоя­щим изменениям должна сохранить наш код гибким и предотвратить кошмарные изменения, которые могут возникнуть впоследствии. К сожалению, эффект от таких мероприятий может быть совсем противопо­ложным. При подготовке к наступлению множества дополнительных непредви­денных обстоятельств проект начинает изобиловать никогда не использующимися конструкциями. Некоторые из таких подготовительных мероприятий могут оку­паться, а другие — нет. А между тем проект несет на себе груз неиспользуемых элементов проекта. В силу этих причин программа получается сложной и трудно понимаемой. Неоправданные повторения Операции "вырезки" и "вставки" могут быть полезными при редактирова­нии текста, но в то же время они могут быть опасными операциями в случае редактирования кода. Слишком часто программные системы выстраиваются на десятках или сотнях повторяющихся элементов кода. Неопределенность Неопределенность программного модуля проявляется в сложности его пони­мания. Код может быть написан либо в четкой и выразительной манере, либо быть неопределенным и трудным для понимания. Код, эволюционирующий с течением времени, становится все более неопределенным. Необходимо постоянно следить за тем, чтобы код оставался "прозрачным" и выразительным, сводя возможную неопределенность к минимуму.