Хороший дизайн, плохой дизайн…

System Analysis and DesignDesigning and refactoring

Иногда, открываешь какой-нибудь проект с историей и понимаешь, что история и у этого проекта была длинная… Да еще и авторы менялись, и видно, что у них был небольшой опыт.

В чем это выражается? — В том, что все части системы настолько переплетены, что невозможно оторвать один кусок и использовать где-то еще. Как результат, такой проект, конечно невозможно накрыть никакими модульными тестами кроме как приемочными со стороны группы QA. А значит, что со временем стоимость доработки будет возрастать, так как мы теряем уверенность в том, что наши изменения не поломают какие-то другие части.

Другим симптомом низкого качества проекта, может служить факт, что один класс выполняет одновременно множество ролей, то есть такой универсал-многостаночник. Это часто получается из-за того, что разработчику просто лень писать новый класс/интерфейс, потом его вводить в систему перестраивая связи. Намного проще просто «добавить метод по месту», «ведь если я добавлю сюда еще один метод ничего плохого не произойдет, так?» — думает он. Но после одного метода, появляется второй и третий. Если разработчик продвинутый, он запишет задачу «технический долг — надо выполнить рефакторинг и поделить всё на части», но часто он может даже не понимать, что проблема существует. Это обычно распространено в молодых командах, где нет специалиста с хорошим и правильным стажем.

А бывает ли такое, где есть специалист со стажем, но проект все-равно находится в запутанном состоянии? Да, и такое бывает. Как правило, на проектах, которые велись одним разработчиком, и его никто не наставлял на путь истинный. А потом, он вырастает, у него уж есть репутация «я тут давно работаю», «поработай тут, с мое, а потом говори» И он уже становится неспособным воспринимать правильный дизайн и правильное разделение компонент. Ему кажется, что это слишком сложно и запутанно.

Иногда, можно видеть ситуацию, когда профессионал пишет «по-быстрому», расширяя объекты несвойственным функционалом. Однако, профи точно знает, что прямо сейчас он решает задачу быстро, или делает макет, а завтра ему нужно будет обязательно выполнить рефакторинг. Но такой подход всё-таки оправдан только на быстрых и коротких проектах с очень маленькой длительностью. Технический долг имеет свою процентную ставку, и с каждой неделей она возрастает.

Как понять какой дизайн хороший, а какой плохой? Я рекомендую простой критерий:

Для каждого класса/объекта системы пишем ответы на вопросы:
  • Чем класс должен заниматься? Какова его зона ответственности?
  • Чем класс НЕ ДОЛЖЕН заниматься? В какие смежные области класс точно не должен лезть.

Ответы на эти вопросы сформируют систему связанных фактов, которую нужно проверить ответив на самый главный вопрос:

Почему ты считаешь, что (эта фича/действие/возможность) должна обеспечиваться этим классом?

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

Кроме этих вопросов, можно применить еще несколько индикаторов, позволяющих «поймать» неверное решение на ранних фазах:

Класс выполняет больше одной роли. В ответе на вопрос «Что класс должен делать?» хочется начать перечислять возможности. И вы не можете сконцентрироваться на какой-то одной самой важной. Это означает, что надо подумать о разделении на несколько классов.

Не удается выразить одним кратким предложением, чем занимается класс. Это значит, что его зона ответственности размыта, и у вас нет понимания зачем этот класс нужен. Индикатор показывает, что в будущем это может стать «кучей мусора».

Есть острое желание вытащить наружу какие-то защищенные данные или методы. Показывает, что к класса меняется роль, и он становится агрегатором данных. Имеет смысл перепроверить назначение класса и его ограничения.

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

Вопрос: Коллеги, а какие вы применяете способы проверки дизайна на устойчивость?
Tags:проектирование попроектная деятельность
Hubs: System Analysis and Design Designing and refactoring
+2
7.9k 59
Comments 11
Data Architect
from 160,000 ₽Droice LabsRemote job
Business System Analyst (Data Warehouse)
from 3,000 €ExnessЛимассолRemote job
Wireless Systems Engineer
from 100,000 to 200,000 ₽ON SemiconductorСанкт-Петербург
Python Team Lead (with Django and AWS)
from 240,000 ₽SibedgeRemote job
Java Developer
from 4,200 to 5,800 $CambristRemote job

Top of the last 24 hours