Эргономичный код
796 subscribers
76 photos
3 videos
20 files
384 links
Канал о разработке поддерживаемых бакэндов - про классическую школу TDD, прагматичное функциональное программирование и архитектуру и немного DDD.

Группа: https://t.me/+QJRqaHI8YD

https://azhidkov.pro
Download Telegram
Привет!

Когда ещё весной-летом делал первый подход к посту о декомпозиции на базе диаграммы эффектов захомячил крутой пост про связанность и сцепленность.

Сейчас делаю второй подход к посту декомпозиции, откопал его, перечитал, снова впечатлился и на это раз решил поделиться с вами:)

#posts@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code
Привет!

Накопал любопытный пост, в которой автор переносит виды сцепленности из структурного дизайна, на современную разработку.

Не совсем согласен, но ознакомиться рекомендую.

#posts@ergonomic_code #coupling@ergonomic_code #structured_design@ergonomic_code
Привет!

Не спрашивайте как, но я тут наткнулся на очередную любопытную статью - Analyzing Error-Prone System Structure.

В ней авторы приводят результаты анализа реальной системы на предмет зависимости количества и стоимости исправления ошибок в подсистемах от сцепленности и функциональной связанности подсистем.

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

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

#papers@ergonomic_code #coupling@ergonomic_code #effects_diagram@ergonomic_code
🔥5👍1
Привет!

В продолжение вчерашнего топика очень крутой доклад от Кента Бека про coupling и cohesion.

В докалде Бек утверждает, что в оригинальной книге сцепленность оценивается относительно некоторого изменения (хотя я сам такого не помню и в книге найти не смог).

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

Но в этот раз у меня появилась идея как узнать, какие у меня будут изменения - посмотреть коммиты в Проекте Э, попытаться как-то классифицировать изменения и их сложность (объём). Экстраполировать эти данные, сказать что наиболее дорогими (с учётом вероятности) будут изменения такого типа и по умолчанию защищаться я буду от них.



Ещё одна мысль из доклада - "расстояние" между сцепленными элементами имеет значение. И это одна из основных причин, почему я перешёл от Эргономичной структуры в1 к в2. И в чём разочаровался по мотивам Проекта Э.

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



Ну и наконец книга - Tidy First?: A Personal Exercise in Empirical Software Design - добавлю в свой список на прочтение

#talks@ergonomic_code #design@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code
3🔥3👍2
И вот ещё хороший доклад про Coupling.

Там же, внезапно, мужик говорит про тот самый Connascence и объёдиняет его с классическим Coupling в ещё более современный Integration Strength. Ток эту штуку тексту нагуглить не получается.

И так же говорит про "расстояние" в коде.

#talks@ergonomic_code #design@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code
👍4🔥32