Пятничное чтиво

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————

A Promising New Metric To Track Maintainability

Стараюсь пропагандировать ADD, где ключевая идея — принятие решений на основе характеристик. В случае с исчисляемыми метриками — вопросов нет. Сложности начинаются с «субъективными» и не исчисляемыми метриками, например с maintainability или modifiability. Поэтому сегодня статья, где предлагается математическую модель для расчета maintainability.

Начинается текст с предположения, что coupling и cyclic dependencies помогут с расчетом, но, из-за вертикального и горизонтального разбиения, значения считать сложно. Как решение вводится понятие verticalization, благодаря которому, получается Maintainability Level через работу с циклами графа. Во следующей версии метрики, вводится штраф за «длину» цикла. После чего автор занимается fine tuning метрики. Для систем с малым количеством компонентов, метрика работала плохо. Вторая ситуация возникла, когда метрика показала «хорошее» значение, но разработчики были не удовлетворены поддерживаемостью. Проблема оказалась в структуре модулей, которую решили дополнительным условием.

#maintainability

—————————————

Why senior developers fail to communicate their expertise

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

Начинается текст с ситуации, когда бизнес приходит с гениальной идеей: «меняем разработчиков на LLM». От подобной идеи у разработчиков дергается глаз из-за сложности (complexity). Через конфликт, автор вводит первый цикл (в котором находятся продажники, продакт-менеджеры, CEO): компания выводит продукт на рынок и получает фидбек. В таком цикле главная проблема — неопределенность, которая решается скоростью получения фидбека. Во втором цикле, где компания предоставляет услугу пользователю и получает деньги, главное — стабильность, а со сложностью проблема. Далее автор связывает два цикла через «компанию» из-за чего получается несогласованность между людьми в разных циклах. В конце предлагаются решения, о чем уже прочтете в статье.

Русский перевод

#ppl_communications

—————————————

On mashing up modelling techniques for fun and profit

Статья заинтересовала идеей смешивания context map из ddd и c4 в одну модель. Если что, идея context map в отображении bounded context из DDD и связей между контекстами. А главная ценность — отображение паттернов коммуникаций из DDD. Добавив информацию о «типах» коммуникаций контекстов в с4, получаем больше информации о взаимодействии частей системы не только на техническом, но и на социо уровне (а software system — socio-tech system).

Начинается текст с показа автором модели совмещенного context map и c4, которую сделали для воркшопа. А после объяснения плюсов подхода показывается как подобные модели делать. Сначала делается c4 level 1 с интеграциями, после чего добавляется level 2. Далее добавляются паттерны коммуникации на level 2 (open host, anti-corruption и так далее). После чего добавляются контексты и объясняется в чем плюсы и минусы подхода. В конце дается название подходу (Model Storming). Единственное что огорчило — нет конкретных инструментов, а статья сугубо идейная.

#c4 #ddd