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

E-mail Печать PDF
Рейтинг пользователей: / 0
ХудшийЛучший 
Индекс материала
Признак плохого проекта
Закрепощенность
Неподвижность
Неподвижность
Вязкость
Неоправданная сложность
Неоправданные повторения
Неопределенность
Чем вызвано
Page 10
Все страницы

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

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

Закрепощенность: система с трудом поддается изменениям, поскольку любое минимальное изменение вызывает эффект "снежного кома", затрагивающего другие компоненты системы.

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

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

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

Неоправданная сложность: проект включает инфраструктуру, применение которой не влечет непосредственной выгоды.

Неоправданные повторения: проект содержит повторяющиеся структуры, которые могут унифицироваться с применением простой абстракции.

Неопределенность: проект трудно читать и понимать. Недостаточно четко выражено содержимое проекта.


Закрепощенность

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

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


Неустойчивость

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

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


Неподвижность

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


Вязкость

Вязкость может проявляться в двух формах: по отношению к ПО и к среде.

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

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

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


Неоправданная сложность

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

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


Неоправданные повторения

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

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

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

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


Неопределенность

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

На начальном этапе составления модуля код разработчикам может показаться достаточно "прозрачным". Это происходит в силу того, что они, погружаясь в проблему с головой, воспринимают код на своем внутреннем уровне. Позднее, когда это состояние проходит, они могут вернуться к модулю и удивиться, что могли составить нечто подобное. Чтобы предотвратить такие случаи, разработчики должны представить себя на месте своих читателей и предпринять согласованные усилия для разложения кода на элементарные операции, чтобы читатели могли его понять. Кроме того, желательно, чтобы кто-то еще просмотрел составленный ими код.


Чем вызвано "загнивание" программы?

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

Тем не менее, не следует причину ухудшения проекта усматривать в изменении требований. Мы, как разработчики, достаточно хорошо знаем, что требования изменяются. Действительно, большинство из нас понимает, что требования - это самые непостоянные элементы проекта. Если формирование проектов затруднено по причине постоянного изменения требований, то винить в этом следует только наши проекты и нашу деятельность. Необходимо найти какой-нибудь способ разработки проектов, более устойчивых к таким изменениям, и осуществлять меры по предупреждению их "загнивания".


"Загнивание" программ исключается в случае применения технологий быстрой разработки ПО

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

 

Добавьтe Ваш комментарий

Ваше имя (псевдоним):
Ваш адрес почты:
Заголовок:
Комментарий:

Комментарии, категория: "IT"

Интересное




Похожие материалы

Партнёры