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