"ВКонтакте" отказалась от микросервисов | ComNews
https://www.comnews.ru/content/228980/2023-09-25/2023-w39/1008/vkontakte-otkazalas-mikroservisov

Новая книга от PostgresPro:
Лесовский А. В. Мониторинг PostgreSQL. — М.: Бумба, 2024. — 247 с.
https://postgrespro.ru/education/books/monitoring

Уходят титаны...
https://x.com/Bertrand_Meyer/status/1742613897675178347?s=20

Некоторые ссылки битые потому, что блог автора переехал с frey.su на frey.today Правильные ссылки смотрите в блоге автора:
https://frey.today/blog/

Тг-канал Дениса Бескова сменил свой адрес на https://news.1rj.ru/str/denis_beskov

Думаю, что в представлении он не нуждается. Один из самых грамотных специалистов, которого я только встречал за всю свою практику. Именно он организовал нашумевшее недавно интервью в Владиком Хононовым.

Автор профстандарта системного аналитика, основатель школы системного анализа и проектирования, организатор и спикер конференций, в свое время построил отдел системных аналитиков в Лаборатории Касперского.

Подписывайтесь)

Еще один список инструментов для управления требованиями:
http://makingofsoftware.com/resources/list-of-rm-tools

💬 "Машина может быть на ДВС, но машина - это не "то, у чего внутри ДВС", машина - это на чем ездят."
-- @IgorBespalchuk

Простыми словами про дихотомию функции и конструкции. Problem Space vs. Solution Space.

Иногда хочется так много сделать, но так мало получается сделать. А у него получилось. И я хорошо понимаю, какой титанический труд за этим стоит. Хочу пожелать успехов и дальнейшего развития.

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

Не реклама. Мое мнение. Потому что хочу, чтоб таких качественных курсов было побольше на нашем захламленном рынке знаний.

Кто не хочет погружаться в работы Barry Boehm для выбора SDLC-модели разработки, тот может использовать более простой подход - Cynefin framework (см. мини-книгу в канале @nullnullday )

Постараюсь посетить:
https://news.1rj.ru/str/denis_beskov/165

Там все чуть сложнее. Если совсем просто объяснять, то итерация - это "метод научного тыка".

Бытовой пример. Например, нужно обесточить и заменить розетку. Видим в щитовой кучу автоматов. Какой из них выключить? Можно, конечно, определить путем логического вывода, например, отыскать схему разводки или исследовать разводку детектором скрытой проводки. А можно просто включить в розетку лампочку и поочередно перебирать все рубильники до тех пор, пока не угадаем.

Как говорил математик Polya: "If you run into a dead end in one of the areas, iterate!".

Суть итерации в том, что иногда проще сделать и изменить, чем пытаться угадать с первого раза.

Типичная ситуация в работе архитектора - это когда он начинает прорабатывать решение, и тут выясняется, что оно не может быть реализовано, потому что 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 сделает свое дело. Программисты часто прибегают к копированию. Было бы что копировать. Если копировать нечего, тогда наступает царство "Теории разбитых окон". Если копировать нечего, то оно само не появится (иначе появилось бы раньше). Значит, его должен создать архитектор. Сам, или совместно с программистами, - зависит от ситуации.

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

Про полиграфы. В наше время находятся работодатели, которые считают, что вправе заставлять соискателя оправдываться перед ними в своей невиновности еще до того, как те успеют поработать на них.
https://www.youtube.com/shorts/1_pE1MaV8_A

Много раз на практике наблюдал ситуацию, когда специалист имеет правильное понимание, но не может его аргументированно донести своим коллегам. Возникает борьба за лидерство, токсичность, конфликтность. Одни только баттлы вокруг SRP чего стоят. Нередко это заканчивается агрессивно-пассивной позицией: "делай как хочешь, только меня потом не трогай".

Ключем к пониманию ситуации является слово "потом".

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

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

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

Я уже говорил, что лидерство заключается, в первую очередь, в дальности горизонта видения. Еще в Дао Де Цзин писали, что мудрый лидер управляет не запретами, а проливанием света на последствия. Вот этот горизонт видения и есть то самое, вокруг чего люди объединяются.

Именно поэтому Craig Larman говорил:
💬 “Место, где происходит реальная работа” в программировании - это код, из чего следует, что первоклассными менеджерами должны становиться лучшие разработчики, которые часто оценивают код.
- Craig Larman, https://less.works/ru/less/principles/systems-thinking.html

Хороший лидер уберегает от проблем. Потому что способен их предвидеть. Потому что знает. Что означает, что ничто другое не имеет значения.

Как говорил Л.Н.Толстой, один из самых влиятельных людей мира, единственным инструментом власти которого было слово:
💬 "Всякая истина, выраженная словами, есть сила, действие которой беспредельно".

Поэтому очень важно не только видеть правильное решение, но и видеть причинно-следственные связи, приводящие к этому решению.

Хорошим примером является DDD. Зачастую разработчики интуитивно чувствуют его полезность, но не понимают какую именно проблему он решает. Попытки "насадить" DDD могут привести к формированию оплота сопротивления. Даже у Nick Tune, известного автора по DDD, такое случалось.

В последнее время иногда слышу термин "управление накоплением знаний". Я уже говорил о том, что процесс обретения знаний сопровождается сокращением количества информации. Подобно тому, как скульптор освобождает образ, отсекая все лишнее. Коллекционировать знания не нужно, т.к. можно запутаться.

Иногда приходилось наблюдать ребят, которые начинали заниматься накопительством знаний, пока не начинали тонуть в когнитивной нагрузке. На этом их процесс развития останавливался, и они возводили стены психологической защиты вокруг того, что они успели освоить. Тот информационный хлам, который они успели бесформенно освоить, создавал у них иллюзию наличия знаний, усиленную эффектом иррационального усиления на вершине пика глупости кривой Даннинга-Крюгера. Что приводило к их высокой токсичности.

Пост на аналогичную тему:
https://news.1rj.ru/str/ru_arc/178

Подборка материалов для подготовки аналитика:
https://news.1rj.ru/str/denis_beskov/173