Всем привет! Сегодня у меня день рождения, и я сделал себе к нему подарок — закончил работать над черновиком своей книги "Доказательная архитектура" 😊
🎞️🎞️🎞️🎞️🎞️🎞️🎞️
«Ну ты же архитектор, тебе виднее».
Эту фразу слышал, кажется, каждый в профессии, и говорят её обычно с уважением. Только вот с чего виднее? За решением стоит опыт — сколько-то похожих систем, сколько-то прочитанных книг, сколько-то шишек. У коллеги, который предлагает сделать наоборот, найдётся не менее убедительная история. Оба опираются на опыт и оба звучат уверенно, а выбрать в итоге нужно какой-то один вариант.
Я много лет собирал ответ на этот вопрос по кускам: в докладах, статьях, спорах, чужих постмортемах и собственных ошибках. Теперь куски собрались в книгу — «Доказательная архитектура».
Главный тезис такой: у архитектурного решения должно быть не только описание того, как будет устроена система. Оно должно объяснять, почему мы рассчитываем, что выбранный вариант сработает в нашем контексте, как мы это проверим и какие сигналы заставят нас его пересмотреть.
Что внутри, если коротко:
➡️ лестница силы аргументов — от интуиции до эксплуатационных наблюдений: чтобы прямо на архсовете понимать, сколько весит прозвучавший аргумент;
➡️ архитектурная гипотеза: как превратить мнение архитектора в проверяемую запись с механизмом эффекта, метриками и условиями пересмотра, зафиксированными до внедрения;
➡️ принцип каскадного снижения связанности, доведённый до проверяемого неравенства;
➡️ Architecture as Code с тестами: как ловить расхождение схемы и реальности на CI, а не на инциденте;
➡️ метрики архитектуры и способы не обмануть себя ими же;
➡️ как проверять отказоустойчивость, когда начинать архитектурный рефакторинг и что изменится, если приложить тот же аппарат к платформам, процессам и оргструктурам;
➡️ и отдельная глава про то, что со всем этим делает ИИ.
В итоге получилось пятнадцать глав со сквозным примером, тянущемся через всю книгу, в конце каждой главы — чек-лист.
Сейчас это черновик. Сейчас хочу собрать небольшую группу коллег по цеху желающих прочесть черновик для проверки.
Если чувствуете в себе силы осилить и дать фидбэк — пишите в личку @razonrus 😎
В качестве обратной связи по черновику мне нужны минимум две вещи:
1. Общие замечания по содержанию. Где я ошибся, где излишне упростил, где пропустил что-то, где не учёл важный контекст. Это хочется обнаружить до публикации.
2. Точечные комментарии прямо по тексту: неточность, спорный переход, недостающее уточнение.
На верстку, стиль картинок, мелкие опечатки и пунктуацию пока можно не обращать внимания. Мне важно именно содержание.
Если формулировка мешает понять мысль, конечно, отмечайте: это уже содержательная проблема.
Планирую собрать обратную связь за месяца полтора.
Спасибо 🙏
🎞️🎞️🎞️🎞️🎞️🎞️🎞️
«Ну ты же архитектор, тебе виднее».
Эту фразу слышал, кажется, каждый в профессии, и говорят её обычно с уважением. Только вот с чего виднее? За решением стоит опыт — сколько-то похожих систем, сколько-то прочитанных книг, сколько-то шишек. У коллеги, который предлагает сделать наоборот, найдётся не менее убедительная история. Оба опираются на опыт и оба звучат уверенно, а выбрать в итоге нужно какой-то один вариант.
Я много лет собирал ответ на этот вопрос по кускам: в докладах, статьях, спорах, чужих постмортемах и собственных ошибках. Теперь куски собрались в книгу — «Доказательная архитектура».
Главный тезис такой: у архитектурного решения должно быть не только описание того, как будет устроена система. Оно должно объяснять, почему мы рассчитываем, что выбранный вариант сработает в нашем контексте, как мы это проверим и какие сигналы заставят нас его пересмотреть.
Что внутри, если коротко:
➡️ лестница силы аргументов — от интуиции до эксплуатационных наблюдений: чтобы прямо на архсовете понимать, сколько весит прозвучавший аргумент;
➡️ архитектурная гипотеза: как превратить мнение архитектора в проверяемую запись с механизмом эффекта, метриками и условиями пересмотра, зафиксированными до внедрения;
➡️ принцип каскадного снижения связанности, доведённый до проверяемого неравенства;
➡️ Architecture as Code с тестами: как ловить расхождение схемы и реальности на CI, а не на инциденте;
➡️ метрики архитектуры и способы не обмануть себя ими же;
➡️ как проверять отказоустойчивость, когда начинать архитектурный рефакторинг и что изменится, если приложить тот же аппарат к платформам, процессам и оргструктурам;
➡️ и отдельная глава про то, что со всем этим делает ИИ.
В итоге получилось пятнадцать глав со сквозным примером, тянущемся через всю книгу, в конце каждой главы — чек-лист.
Сейчас это черновик. Сейчас хочу собрать небольшую группу коллег по цеху желающих прочесть черновик для проверки.
Если чувствуете в себе силы осилить и дать фидбэк — пишите в личку @razonrus 😎
В качестве обратной связи по черновику мне нужны минимум две вещи:
1. Общие замечания по содержанию. Где я ошибся, где излишне упростил, где пропустил что-то, где не учёл важный контекст. Это хочется обнаружить до публикации.
2. Точечные комментарии прямо по тексту: неточность, спорный переход, недостающее уточнение.
На верстку, стиль картинок, мелкие опечатки и пунктуацию пока можно не обращать внимания. Мне важно именно содержание.
Если формулировка мешает понять мысль, конечно, отмечайте: это уже содержательная проблема.
Планирую собрать обратную связь за месяца полтора.
Спасибо 🙏