The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Я даже не знаю, с чего начать. Давайте начнем с этого: Если я вас не понимаю, это ваша вина. Это должно быть самым основным принципом хорошего архитектора программного обеспечения (ну, любого инженера), но большинство архитекторов, с которыми я сталкивался в различных компаниях, не кажутся в это верующими. Они не понимают, что задача архитектора программного обеспечения - упрощать сложные вещи, а не усложнять их. Они используют диаграммы, которые являются самым популярным инструментом архитектора, чтобы объяснить нам, программистам, что они имеют в виду. Но диаграммы обычно очень криптичны и трудно усвояются. Что еще хуже, сложность растет пропорционально их зарплатам - это отвратительно.
Почему это происходит? Почему их диаграммы сложны и трудно читаемы? Я уверен, что вы знаете, о чем я говорю; у вас, наверняка, есть собственные примеры таких диаграмм из проектов и архитекторов, с которыми вы работали. Так почему мы имеем дело с ними?
Архитекторы гордятся сложностью, вот почему. Они считают, что чем более сложная проблема, с которой они работают, тем лучше они инженеры. Я много раз вел такой диалог:
Обычно после этого архитектор улыбается с явным чувством удовлетворенности. Действительно, кто-то заметил, как трудна его работа, и оценил его усилия. Кто-то глуп, а он умён. Он может понять эту многоуровневую архитектуру, а я нет. Он определенно заслуживает моего уважения, верно?
Нет! Хороший архитектор знает, что его главная роль состоит в разложении сложной проблемы на более простые компоненты и позволении программистам разрешать их по очереди. Как и хороший менеджер проекта, который должен разложить сложную задачу на более мелкие. Когда проблема правильно разложена (разбита на более мелкие, изолированные и должным образом развязанные части), сложность уменьшается, и всем становится легче понять и решить.
Главное достоинство архитектора - способность снизить сложность. Таким образом, хороший архитектор никогда не будет гордиться сложной диаграммой. Вместо этого он будет гордиться простым и понятным чертежом с несколькими прямоугольниками, которые идеально объясняют всю многоуровневую систему. В этом и заключается настоящий труд. В этом проявляется истинный архитектурный ум.
Таких архитекторов немного. Я не могу сказать, что я из их числа, но у меня есть несколько рекомендаций по вашим диаграммам. Читайте дальше и помните, что главная цель всего этого - снижение сложности.
Не более пяти прямоугольников. Если их больше, что-то не так. Попытайтесь объясниться менее чем пятью. Просто объедините некоторые из них и дайте им имя. Вы не хотите, чтобы я тратил несколько секунд на попытку понять, кто участвует в представлении, которое вы представляете. Я хочу увидеть их всех сразу и сразу понять, кто есть кто. Я просто придумал число пять, но вы понимаете идею - убедитесь, что все участники диаграммы легко считаются. Я видел диаграммы с 25 или более прямоугольниками… это неприемлемо.
Используйте UML. Ну, используйте ту нотацию, с которой вы чувствуете себя комфортно, но много лет назад люди согласились, что вместо использования разных нотаций будет проще выучить одну для всех - это UML. Это огромный формат/стандарт/язык, но вам не нужно знать все это. Просто изучите основы, этого будет достаточно для выражения практически любой идеи, которая у вас есть. Я бы рекомендовал книгу UML Distilled: Краткое руководство по стандартному языку объектного моделирования (3-е издание) Мартина Фаулера.
Прямые и подписанные линии. На диаграмме нет ничего более раздражающего, чем линия, соединяющая два прямоугольника без текста и без направления. Это поток данных? Это компиляционная зависимость? Есть много возможных значений. Всегда используйте стрелки и всегда аннотируйте их - это поможет мне понять вас гораздо быстрее.
Не используйте цвета. Или скажу так: не злоупотребляйте цветами. И чтобы избежать злоупотребления, вам лучше вообще избегать цветов. Если вам нужно использовать цвета, значит, с вашей диаграммой что-то не в порядке. Вероятно, она слишком сложная, поэтому вам нужно использовать цвета. Упростите ее, группируя элементы.
Не будьте творческими. Это не искусство, это инженерия. Вам не нужно меня впечатлять; вам нужно донести сообщение. Ваша цель - не показать, насколько сложен ваш ум. Более того, стиль вашей диаграммы не должен быть личным. Диаграмма от вас и диаграмма от другого архитектора должны выглядеть почти одинаково, если они передают одно и то же сообщение. Это называется единообразием. Таким образом, вы делаете их понятнее для меня. Мне не хочется выучивать вашу личность, чтобы понять вашу диаграмму. Если это сервер, нарисуйте прямоугольник. Нет необходимости ставить 3D-изображение сервера HP. Прямоугольник достаточен. Также, пожалуйста, без теней, без шрифтов и без стилей. Опять же, это не конкурс на искусство. Я буду очень хорошо понимать ваш прямоугольник и без этой “красивой” тени, которую вы хотите добавить. Я также буду понимать стрелку с обычной шириной; нет необходимости делать ее шире просто потому, что ваш редактор диаграмм позволяет это сделать. Не тратьте свое и мое время на все эти стилизации. Просто сосредоточьтесь на тех простых линиях, прямоугольниках, тексте и стрелках.
Как я уже упоминал, цель всего этого - уменьшить сложность и помочь мне, программисту, понять вас, архитектора. Помните, если я не могу понять вас, это ваша вина. Вы плохой архитектор, если не можете изложить свои идеи простым, понятным языком.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 16:50
