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

Говорят, что архитектор программного обеспечения должен думать как садовник, а не как командир. Первые формируют, ухаживают и удаляют сорняки, а вторые определяют и диктуют. Архитектор должен курировать, а не диктовать, формировать, а не определять, и побуждать к обсуждению, а не навешивать ярлыки. Но как заставить его работать?

В WSO2 я делал обзоры архитектуры более восьми лет. WSO2 имеет обширный портфель продуктов, включая хорошо известные WSO2 ESB, WSO2 API Manager и WSO2 SP. За последние восемь лет мы обсудили, спроектировали, улучшили и переработали многие продукты и функции.

Важнейшей частью нашего процесса проектирования является то, что архитектура не создается архитекторами. У нас нет группы архитекторов, которые диктуют архитектурные чертежи, которые реализуются другими. Напротив, дизайн выполняется командой, которая напишет код. Архитекторы исправляют, жалуются, курируют и улучшают дизайн. У нас есть команда архитекторов, но они - проводники и привратники, а не диктаторы.

В следующем выступлении Грегор Хопе прекрасно передает эту идею.

Https://www.youtube.com/watch?v=qVyt3qQ_7TA

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

Однако в обзорах архитектуры есть и свои подводные камни. Пол (@pzfreo) называл этот драйв архитектурой, когда архитекторы входят, слушают, комментируют и двигаются дальше. Как архитектор, вы можете легко проверять, жаловаться и разбирать дизайн. Однако, если вы не будете осторожны, вы можете оставить команду в замешательстве и неуверенности в том, что делать правильно.

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

Ниже приведены некоторые из этих принципов. Некоторые из них хорошо известны, а некоторые мы усвоили трудным путем.

Базовый

Принцип 1: ПОЦЕЛУЙ (Будь простым) и Все должно быть сделано как можно проще, но не проще. Идея состоит в том, чтобы использовать самое простое решение, которое выполняет эту работу.

Принцип 2: ЯГНИ (Он вам не понадобится) - не создавайте его, пока он не понадобится.

Принцип 3: ползай, ходи, беги. Другими словами, заставьте его работать, сделайте его лучше, сделайте его отличным. Do Iterative Development - Делайте гибкую, итеративную разработку. Для каждой функции создайте вехи (максимум 2 недели) и выполните итерацию.

Принцип 4. Единственный способ создавать стабильные и высококачественные продукты - это автоматизированные тесты. Будьте изобретательны с автоматическими тестами; все можно автоматизировать !! Подумайте об этом, когда будете проектировать.

Принцип 5. Всегда думайте о рентабельности инвестиций и уделяйте больше внимания тому, чтобы добиться максимального эффекта.

Принцип 6. Знайте своих пользователей и соответствующим образом балансируйте свои усилия. Для большинства продуктов будут тысячи конечных пользователей, 20 разработчиков, расширяющих продукт, и 100 сотрудников DevOp, которые будут его настраивать. Например, не тратьте месяцы на создание пользовательского интерфейса для DevOp, который все равно вряд ли будет его использовать (вместо этого им нравятся скрипты!). Это частный случай Принципа 5.

Принцип 7. Разрабатывайте и тестируйте функции максимально независимо. Подумайте об этом, когда будете проектировать. Это избавит вас от многих проблем в долгосрочной перспективе, иначе вы не сможете протестировать систему, пока все не будет построено. Также с этим принципом ваши релизы будут более плавными.

Принцип 8. Остерегайтесь зависти Google. Все мы любим блестящие дизайны. В вашу архитектуру легко добавить функции и решения, которые вам никогда не понадобятся.

Выбор функций

Принцип 9. Невозможно продумать, как пользователи будут использовать наш продукт в полной мере. Так что выбирайте MVP (минимально жизнеспособный продукт). Идея состоит в том, чтобы выяснить несколько вариантов использования, сделать только те функции, которые их поддерживают, поставлять продукт и формировать будущий продукт на основе отзывов и опыта.

Принцип 10. Делайте как можно меньше функций, а в случае сомнений опускайте их. Многие функции никогда не используются, возможно, вам стоит вместо этого оставить точку расширения.

Принцип 11. Дождитесь, пока кто-нибудь об этом попросит (например, функции, которые не являются нарушением условий сделки, дождитесь, пока они потребуются).

Принцип 12. Наберитесь смелости, чтобы бороться с покупателем, если функции, которые он запрашивает, искажают общую картину. Узнайте более широкую картину, попробуйте найти другой способ решения проблемы. Помните цитату Фордов : «Если бы я спросил людей, чего они хотят, они бы сказали, что лошади быстрее». Также помните, что вы эксперт. Вы должны вести. Работа лидера - делать то, что правильно, а не то, что популярно. Позже пользователи будут вам благодарны.

Дизайн сервера и параллелизм

Принцип 13: Знайте, как работает сервер, от оборудования, операционной системы до вашего языка программирования. Оптимизация количества вызовов ввода-вывода - это первый указатель на лучшую архитектуру.

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

Принцип 15. Если ваш проект основан на неблокирующей архитектуре, управляемой событиями, никогда не блокируйте потоки и не выполняйте операции ввода-вывода из этих потоков. Если вы это сделаете, система будет медленной как мул.

Распределенные системы

Принцип 16. Системы без сохранения состояния масштабируемы и просты. Знайте и используйте Shared Nothing Architecture, когда это возможно.

Принцип 17: Доставка ровно один раз, независимо от сбоев, является сложной задачей, если вы не контролируете код как на клиенте, так и на сервере. Постарайтесь спроектировать свои системы таким образом, чтобы их было меньше (например, используйте Принцип 18). Знает, что большинство систем, которые обещают единовременную доставку, где-то срезают угол.

Принцип 18. Реализуйте операции как идемпотентные операции, когда это возможно. Тогда его легко вылечить, и можно жить хотя бы с однократной доставкой.

Принцип 19: знайте теорему CAP. Масштабировать транзакции сложно. По возможности используйте компенсацию. Транзакции на основе СУБД не масштабируются.

Принцип 20: Распределенный консенсус не масштабируется, как и групповое общение, ни надежный обмен сообщениями в масштабе кластера. Максимальный лимит узла для любого из них составляет около восьми узлов в хороший день.

Принцип 21. В распределенной системе невозможно скрыть задержки и сбои. (см. Объяснение ошибок распределенных вычислений).

Пользовательский опыт

Принцип 22. Знайте своих пользователей и знайте их цели: новичок ли он, эксперт или случайный пользователь? Насколько он разбирается в информатике? Гикам нравятся точки расширения, разработчикам нравятся образцы и скрипты, нормальным людям нравятся пользовательские интерфейсы.

Принцип 23. Лучшие продукты не нуждаются в руководстве. Его использование самоочевидно.

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

Принцип 25: Всегда используйте разумные настройки по умолчанию для конфигураций.

Принцип 26. Плохо спроектированные конфигурации могут создать много путаницы. Всегда документируйте несколько примеров значений для конфигурации.

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

Принцип 28: Выдает сообщение об ошибке, если вы видите неизвестную конфигурацию. Никогда не игнорируйте это молча. Скрытые ошибки конфигурации являются источником многих потерянных часов при отладке.

Серьезные проблемы

Принцип 29: Придумывать новые языки легко, но понять их очень сложно. Старайтесь не делать этого, если команда не может потратить на это не менее десяти человеко-лет. Если вы все еще не уверены, прочтите Пять вопросов о языковом дизайне.

Принцип 30: Составные интерфейсы перетаскивания сложны, не создавайте их, если команда не готова вложить в него десять человеко-лет.

Наконец, позвольте мне рассказать о том, о чем я со временем передумал. В идеальном мире платформа должна состоять из ортогональных компонентов - компонентов, каждый из которых обрабатывает один аспект (например, безопасность, обмен сообщениями, реестр, посредничество, аналитика). Система, построенная с такими функциями, была бы оптимальной.

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

Оглядываясь назад, теперь я готов жить с дублированием, когда попытки удалить его приводят к значительной сложности. Лекарство может быть хуже самой болезни.

Заключение

Как архитектор, человек должен думать как Гарднер, который формирует, курирует и удаляет сорняки, а не определяет и строит. Вы должны курировать, а не диктовать, формировать, а не определять, и побуждать к обсуждению, чем навешивать ярлыки.
Хотя в краткосрочной перспективе может быть дешевле и проще диктовать архитектуру, в долгосрочной перспективе, направляя и позволяя команде находить свои способ выплачивает дивиденды.

Если вы не будете осторожны, проще пролететь мимо архитектуры, когда дизайнер только сказал, что его архитектура неверна, но не объяснил, почему она неверна. Один из способов избежать этого - иметь набор общепринятых принципов, которые станут якорем для обсуждения, а также путем обучения начинающих архитекторов.

Мы обсудили некоторые принципы, которые помогли мне справиться с некоторыми проблемами. Ниже приводится резюме.

Если вы вспомните о других, я буду очень рад услышать о них в комментариях.

Надеюсь, это было полезно. Если вам понравился этот пост, вам также могут понравиться Освоение 4-х действий балансировки в архитектуре микросервисов и идеологии параллелизма в Java, C #, C, C ++, Go и Rust. .