Принципы, которые должен знать архитектор ПО

97 принципов из одноимённой книги-сборника — сжатая мудрость десятков практикующих архитекторов. От коммуникации до технического долга.

Бизнес и коммуникация

1. Не ставьте своё резюме выше интересов клиента. Технологии ради технологий — предательство доверия.
2. Возможно, ваша главная проблема не в технологиях. Люди, процессы, бюджет — часто важнее кода.
3. Общение — король, ясность и лидерство — его верные слуги. Без коммуникации архитектура мертва.
4. Вы ведёте переговоры чаще, чем вам кажется. Каждое согласование — переговоры.
5. Всем заправляет бизнес. Технические решения обслуживают бизнес-цели.
6. Подготовьте убедительное экономическое обоснование. Без цифр ваше решение — мнение.

Простота и сложность

7. Снижайте неотъемлемую сложность, устраняйте второстепенную. Боритесь с тем, что создано вами.
8. Простота лучше универсальности. YAGNI: вам не понадобится.
9. Простое должно быть простым. Не усложняйте простые вещи ради «архитектурной чистоты».
10. Не мудрствуйте. Сложность — не признак мастерства.
11. Лучшее — враг хорошего. Не стремитесь к идеальной архитектуре.
12. Масштаб — враг успеха. Растущая система требует растущей дисциплины.
13. Не создавайте решения «на перспективу». Решайте сегодняшние проблемы.

Проектирование и код

14. Производительность приложения определяется его архитектурой. Не оптимизациями постфактум.
15. Создание архитектуры — искусство баланса. Компромиссы неизбежны.
16. Архитектурные компромиссы — осознанный выбор между противоречивыми требованиями.
17. Приготовьтесь выбрать два из трёх. Быстро, дёшево, качественно — выберите два.
18. Одна строка рабочего кода стоит 500 строк спецификации. Код — истина.
19. Программирование — часть процесса проектирования. Архитектор, не пишущий код, теряет связь с реальностью.
20. Архитектор должен быть практиком. Иначе его решения — фантазии.
21. Архитектор — прежде всего разработчик. Не должность, а роль.
22. Проектируйте только то, что можете запрограммировать. Абстракции без реализации опасны.
23. Начните с ходячего скелета. Работающий прототип лучше идеальной схемы.
24. Лучшие программы не строят — их выращивают. Архитектура эволюционирует.

Требования и предметная область

25. Ищите истинный смысл требований. За каждым требованием — потребность.
26. Разберитесь в предметной области. Без доменных знаний архитектура оторвана от жизни.
27. Изучите профессиональный жаргон. Ubiquitous language — общий язык с заказчиком.
28. Чётко определённые задачи решаются качественно. Размытые требования — размытый результат.
29. Сомневайтесь в допущениях — особенно в собственных. Ваши убеждения — главный источник ошибок.
30. Когда видите единственное решение — спросите других. Единственность — признак неполноты анализа.
31. Правила диктует контекст. Универсальных решений не существует.

Данные и инфраструктура

32. В основе всего — данные. Код меняется, данные остаются.
33. База данных как Крепость. Защищайте целостность данных.
34. Управляйте не только кодом, но и данными. Схема, миграции, версионирование.
35. Архитектор должен разбираться в оборудовании. Железо определяет ограничения.
36. Выбирайте инфраструктуры, хорошо сочетающиеся с другими. Интеграция — ключ к масштабированию.
37. Небоскрёбы не масштабируются. Монолитная архитектура имеет пределы.
38. Обеспечьте непрерывную интеграцию. CI — не опция, а необходимость.

Качество и технический долг

39. Сбои неизбежны. Проектируйте устойчивость, а не отсутствие сбоев.
40. Используйте количественные критерии. Без метрик нет управления качеством.
41. Думать о производительности никогда не рано. Поздняя оптимизация — переписывание.
42. Не забывайте о производительности. Но не оптимизируйте преждевременно.
43. Проверяйте решения на прочность по ключевым характеристикам. Тестируйте нефункциональные требования.
44. Расплатитесь по техническим кредитам. Долг растёт с процентами.
45. «Срезание углов» сейчас обойдётся слишком дорого потом.
46. Уделяйте пристальное внимание поддержке и сопровождению. Система живёт дольше, чем пишется.
47. Ваша система станет унаследованной — учитывайте это при проектировании.

Люди и команда

48. Предоставьте разработчикам независимость. Микроменеджмент убивает архитектуру.
49. Поддерживайте разработчиков. Архитектор — не контролёр, а помощник.
50. Не контролируйте — наблюдайте. Дайте команде свободу в рамках ограничений.
51. «Я» в архитектуре не существует. Архитектура — продукт команды.
52. Делитесь знаниями и опытом. Архитектор-одиночка — бутылочное горлышко.
53. Найдите и удерживайте энтузиастов. Один увлечённый стоит десятерых равнодушных.
54. Ответственное руководство важнее внешнего впечатления.
55. Отвечайте за свои решения.
56. У программной архитектуры есть этические аспекты.

Мышление архитектора

57. Встаньте! Меняйте перспективу, смотрите на систему с разных точек.
58. Посмотрите с высоты 300 метров. Детали замыливают картину.
59. Руководствуйтесь неопределённостью. Планируйте для неизвестного.
60. Пробуйте, прежде чем сделать выбор. Прототипируйте архитектурные решения.
61. Время меняет всё. Сегодняшнее правильное решение — завтрашний антипаттерн.
62. Не спешите решать задачи. Дайте проблеме «отлежаться».
63. Записывайте свои обоснования. Почему принято именно это решение — важно.
64. Осознавайте последствия изменений. Взмах крыла бабочки в архитектуре.
65. Освойте новый язык. Новый язык — новый способ мышления.
66. Учитесь у архитекторов зданий. Физические ограничения дисциплинируют.
67. Боритесь с повторениями. DRY — на уровне архитектуры.
68. Добро пожаловать в реальный мир. Теория и практика — разные вещи.
69. Остерегайтесь «хороших идей». Не каждая идея должна быть реализована.
70. Всё будет не так, как задумано. Готовьтесь к изменениям.

Антипаттерны

71. Не увлекайтесь архитектурными метафорами. «Система как живой организм» — красиво, но бесполезно.
72. Патология шаблонов. Шаблон ради шаблона — вред.
73. Решений на все случаи жизни не существует. Silver bullet нет.
74. Сделать наспех и сбежать — преступление. Передача непродуманной архитектуры — саботаж.
75. «Архитектор ПО» пишется со строчной буквы. Не культивируйте эго.
76. Неоднородность побеждает. Гомогенные системы — миф.
77. Проблемы могут быть больше, чем их отражение в зеркале. То, что вы видите — не вся картина.
78. Повторное использование зависит не только от архитектуры. Культура и процессы важнее.
79. Бизнес и недовольный архитектор. Если архитектор недоволен — он строит неправильную систему.
80. Для пользователя интерфейс — это и есть система. Архитектура не видна пользователю — и это нормально.

Связанные статьи на сайте

• C4 Model: документируем архитектуру за 4 шага
• Модульный монолит или микросервисы: спектр решений
• ADR: как вести архитектурные решения
• Справочник архитектурных паттернов ИТ-систем
• Архитектурные роли в ИТ

Что дальше

• Кеширование: паттерны, стратегии, реализации — как архитектурные принципы применяются в кешировании: инвалидация, TTL, Cache-Aside

Связанные статьи: Архитектурные роли в ИТ: кому какие принципы важнее