Иногда, открываешь какой-нибудь проект с историей понимаешь что, история и у этого проекта была длинная… Да еще и авторы менялись, и видно что у них был небольшой опыт.
В чем это выражается? — В том, что все части системы настолько переплетены, что не возможно оторвать один кусок и использовать где-то еще. Как результат, такой проект конечно невозможно накрыть модульными тестами кроме как приемочными со стороны группы QA. А значит что со временем стоимость доработки будет возрастать, так как мы теряем уверенность в том что наши изменения не поломают какие-то другие части.
Другим симптомом низкого качества проекта, может служить факт что один класс выполняет одновременно множество ролей, то есть такой универсал-многостаночник. Это часто получается из-за того, что разработчику просто лень писать новый класс/интерфейс потом его вводить в систему перестраивая связи. Намного проще просто «добавить метод по месту», «ведь если я добавлю сюда еще один метод ничего плохого не произойдет, так?» — думает он. Но после одного метода, появляется второй и третий. Если разработчик продвинутый, он запишет задачу «технический долг — надо выполнить рефакторинг и поделить всё на части», но часто он может даже не понимать, что проблема существует. Это обычно развито в молодых командах где нет специалиста со хорошим и правильным стажем.
А бывает ли такое, где есть специалист со стажем, но проект все-равно находится в запутанном состоянии? Да, и такое бывает. Как правило на проектах которые велись одним разработчиком и его никто не наставлял на путь истинный. А потом он вырастает, у него уж есть репутация «я тут давно работаю», «поработай тут, с мое, а потом говори» И он уже становится не способным воспринимать правильный дизайн и правильное разделение компонент. Ему кажется что это слишком сложно и запутано.
Иногда, можно видеть ситуацию что профессионал пишет «по быстрому», расширяя объекты несвойственным функционалом. Но это не знает что нужно писать так. Профи точно знает, что прямо сейчас он решает задачу быстро, или делает макет, а завтра ему нужно будет обязательно выполнить рефакторинг. Но такой подход всё-таки оправдан только на быстрых и коротких проектах с очень маленькой длительностью. Технический долг имеет свою процентную ставку, и с каждой неделей она возрастает.
Как понять какой дизайн хороший, а какой плохой? Я рекомендую простой критерий:
Для каждого класса/объекта системы пишем ответы на вопросы:
- Чем класс должен заниматься? Какова его зона ответственности?
- Чем класс НЕ ДОЛЖЕН заниматься? В какие смежные области класс точно не должен лезть.
Ответы на эти вопросы с формируют систему связанных фактов. Которую нужно проверить ответив на самый главный вопрос:
Почему ты считаешь что (эта фича/действие/возможность) должна обеспечиваться этим классом?
Если вы нашли логическое и не противоречивое доказательство которое не конфликтует с ранее записанными фактами, значит ваш проект имеет хороший дизайн. Если же есть сомнения, значит что-то не так и нужно подумать о перепроектировании.
Это конечно не защищает от того, что дизайн будет гарантированно хороший, но даст почву для размышлений.
Кроме этих вопросов, можно применить еще несколько индикаторов позволяющих «поймать» неверное решение на ранних фазах:
Класс выполняет больше одной роли. В ответе на вопрос «Что класс должен делать?» хочется начать перечислять возможности. И вы не можете сконцентрироваться на какой-то одной самой важной. Это означает что надо подумать о разделении на несколько классов.
Не удается выразить одним кратким предложением чем занимается класс. Это значит что его зона ответственности размыта и у вас нет понимания зачем этот класс нужен. Индикатор показывает, что в будущем это может стать «кучей мусора».
Есть острое желание вытащить наружу какие-то защищенные данные или методы. Показывает что к класса меняется роль, и он становится агрегатором данных. Имеет смысл перепроверить назначение класса и его ограничения.
Используя такие простые логические инструменты, можно быстро проверить на устойчивость вашу архитектуру чтобы она не стала рахитектурой.
Вопрос: Коллеги, а какие вы применяете способы проверки дизайна на устойчивость?
ссылка на оригинал статьи http://habrahabr.ru/post/261433/
Добавить комментарий