[5/5] Чистый дизайн (Tidy First?) (Рубрика Architecture)
Этот пост заканчивает серию про книгу "Чистый дизайн" (предыдущие посты: 1, 2, 3 и 4).
- Зацепление (coupling) - автор описывает концепцию каскадных изменений, когда изменения в одном компоненте тянут за собой изменения в других компонентах. Это свойство описали еще Эд Йордон и Ларри Константайн в своей книге "Structured Design" и определение звучало так
Два элемента считаются связанным в отношении некоторого изменения, если изменение одного элемента требует изменения другого элемента В это определении важно не просто, что элементы связаны между собой, но и что эта связь существует относительно определенного изменения. Поэтому для анализа coupling недостаточно простого просмотра исходного кода - важно знать какие изменения уже произошли, а также какие возможны в будущем. В итоге, coupling повышает затраты на разработку, поэтому при очистке часто полезно понимать какие изменения приведут к его уменьшению.
- Равенство Костантайна (Constantine’s equivalence) - интересная цепочка размышлений автора -- Где он начинает с того, что большую часть совокупной стоимости владения кодов составляет стоимость измений -> cost(software) ~= cost(change) -- Продолжает тем, что стоимость изменений имеет степенное распределение (power law distribution), а не нормальное, откуда следует, что стоимость больших изменений перевешивает нормальные события -> cost(change) ~= cost(big changes) -- А большие изменения обусловлены высоким coupling -> cost(big changes) ~= coupling Так получается равенство Константайна: cost(software) ~= cost(change) ~= cost(big changes) ~= coupling или проще говоря
cost(software) ~= coupling Поэтому все и хотят уменьшать coupling, но это требует компромиссов.
- Зацепление и его уменьшение (coupling versus decoupling) - автор начинает с того, что "зацепление часто остается незаметным, пока на него не наступишь - совсем как кубик Лего в темной комнате". Но как появляется зацепление - есть несколько вариантов -- При реализации поведения мы выбрали путь с дополнительным зацеплением, учтя NPV решения (можно было сделать без него, но это было дольше и не ясно когда окупится) -- Изначально оно не создавало проблем (мы изначально не планировали делать изменения, которые теперь внезапно появились перед нами) -- Его было не избежать - в конце концов между нашими элементами системы должны быть отношения и взаимосвязи иначе это уже не система, а группа элементов:) Дальше мы должны принять решение - платить дальше за зацепление или заплатить за его уменьшение. Если построить график, то видно, что оба экстремальных решения приведут к чрезмерным затратам и нам нужно выбрать что-то посередине (как обычно где именно посередине остановиться надо искать эмпирически).
- Связанность (cohesion) - здесь автор фактически говорит про кластеризацию элементов нашей системы. Условно сильносвязанные элементы должны попадать в свои кластера, а несвязанные элементы должны оказываться в разных кластерах. А вот coupling - это уже связи между этими кластерами.
- Заключение (conclusion) - в последней главе автор рассказывает о том, как принимать решение по очистке
-- Затраты. Снизит ли уборка затраты на более позднее время или сделает их менее вероятными? -- Доход. Повысит ли уборка доход больше, быстрее или вероятнее? -- Coupling. Приведет ли уборка к тому, что мне придется менять меньше элементов? -- Cohesion. Сможет ли наведение порядка привести к тому, что элементы, которые мне нужно изменить, будут находиться в меньшем и более концентрированном объеме? И напоследок он приводит сравнение очистки, рефакторинга и эволюции архитектуры, где меняется масштаб изменений, стейкхолдеры, причины и способы осуществления каждого из подходов. Плюс это только первая книга из серии, поэтому ждем следующую.
P.S. В конце автор рекомендует кучу книг, из которых я читал всего несколько
#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture