emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

Когда-то я услышал, что пишущий архитектор - это настолько бессмысленно, абсурдно и невероятно, как "генерал авиации, летающий на боевые". Недавно мне попалась статья, в которой именно о таком генерале рассказывает прославленный ас Александр Покрышкин: 📝…

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

Решение оказывается мертворожденным. Чтоб его оживить, возникает соблазн окутать его метастазами системы.

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

Система отражает то, что творится в головах программистов. А значит, здоровье системы начинается отсюда. Это и есть фундамент. Согласен с Gregor Hohpe в том, что табуретка архитектора о трёх ногах: Skill, Impact, Leadership.

Лидерство. Архитектор или становится вождем и принимает на себя ответственность за судьбу проекта, или он рисует мертворожденные стрелочки с квадратиками где-то на обочине жизненного русла продукта. Еще недавно подобное явление называли "хвостизм". Наверное, поэтому первой книгой в списке от Gregor Hohpe идет книга "Clean Code". А второй - "Refactoring".

💬 "When designing a single software component, architects should focus on good coding and design practices." -- Gregor Hohpe

Знания программистов - это первое, с чего я всегда начинал работу на новых проектах. И только потом - стрелочки и квадратики. Тем более, что в Screaming Architecture эти стрелочки не так уж сильно и нужны. А от лапшы они все-равно не спасают.

Лекционный формат не работает. Одна картинка стоит тысячи слов. Поэтому важно сделать один сервис образцово-показательным. А дальше copy-paste сделает свое дело. Программисты часто прибегают к копированию. Было бы что копировать. Если копировать нечего, тогда наступает царство "Теории разбитых окон". Если копировать нечего, то оно само не появится (иначе появилось бы раньше). Значит, его должен создать архитектор. Сам, или совместно с программистами, - зависит от ситуации.

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

The Architect Elevator

Back from the engine room

Architects dive deep to come back up with new insights. Here’s is what I brought back from the serverless cloud integration engine room.

www.tgoop.com/emacsway_log/1283

2.3K viewsIvan, edited  Jan 19, 2024 at 11:54

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

Решение оказывается мертворожденным. Чтоб его оживить, возникает соблазн окутать его метастазами системы.

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

Система отражает то, что творится в головах программистов. А значит, здоровье системы начинается отсюда. Это и есть фундамент. Согласен с Gregor Hohpe в том, что табуретка архитектора о трёх ногах: Skill, Impact, Leadership.

Лидерство. Архитектор или становится вождем и принимает на себя ответственность за судьбу проекта, или он рисует мертворожденные стрелочки с квадратиками где-то на обочине жизненного русла продукта. Еще недавно подобное явление называли "хвостизм". Наверное, поэтому первой книгой в списке от Gregor Hohpe идет книга "Clean Code". А второй - "Refactoring".

💬 "When designing a single software component, architects should focus on good coding and design practices." -- Gregor Hohpe

Знания программистов - это первое, с чего я всегда начинал работу на новых проектах. И только потом - стрелочки и квадратики. Тем более, что в Screaming Architecture эти стрелочки не так уж сильно и нужны. А от лапшы они все-равно не спасают.

Лекционный формат не работает. Одна картинка стоит тысячи слов. Поэтому важно сделать один сервис образцово-показательным. А дальше copy-paste сделает свое дело. Программисты часто прибегают к копированию. Было бы что копировать. Если копировать нечего, тогда наступает царство "Теории разбитых окон". Если копировать нечего, то оно само не появится (иначе появилось бы раньше). Значит, его должен создать архитектор. Сам, или совместно с программистами, - зависит от ситуации.

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

BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.