Смирение не является общей чертой с архитекторами программного обеспечения. Поработав с несколькими ужасными архитекторами и недавно с очень приятным архитектором, я собрал некоторые из своих опытов так, как любит каждый архитектор: как набор правил.
Правило 0: не принимай глупости
Кажется, что некоторые архитекторы предполагают, что разработчики, если оставить их наедине с собой, будут вести себя как обезьяны. По моему опыту, это очень редко бывает. Единственные ситуации, в которых я видел, как разработчики делают глупости, — это когда они молча протестуют против архитектора. Если вы будете следовать этому правилу, остальные детали.
Правило 1: вы можете ошибаться
Рассматривая чью-то дизайнерскую идею, я предпочитаю задавать честно открытые вопросы. Возможно, я думаю, что разработчик упустил важный факт, например, параллелизм. Есть несколько разных подходов к ситуации:
- Архитектор: «Вы не можете сделать это таким образом, потому что это нарушает правила кода»
- Архитектор: «Вы не можете сделать это таким образом, потому что это не будет безопасно, когда есть несколько пользователей»
- Архитектор: «Думали ли вы, как это будет работать с несколькими пользователями?»
- Архитектор: «Как ваше решение соответствует ситуации нескольких пользователей?»
Уважаемый архитектор: Пожалуйста, оцените эти подходы от одного наименее до наиболее вероятного, чтобы получить наилучшую возможную систему. (Совет: это простая задача, хотя многие архитекторы терпят неудачу обычно)
Правило 2: будьте осторожны с технологиями
Каждая технология имеет свою цену. Многие технологии приносят бесконечно малую пользу.
Вот список технологий, которые, как мне показалось, имеют неизменно более высокую стоимость, чем преимущества, и поэтому никогда не будут использовать (если вы их не знаете, не волнуйтесь. Дело в количестве): JavaServer Pages, Java Server Faces , JAX-WS, Hibernate, Spring, EJB, Oracle SOA Server, IBM WebSphere, Wicket, Google Web Toolkit, Adobe Flex, JBoss jBPM, JMS (все реализации), JBoss.
Вот список технологий, которые я с удовольствием использую: JUnit, Jetty, Joda-time, Java Standard Edition.
Вот скромный обмен, который вы можете попробовать скопировать:
- Архитектор: Вы должны использовать технологию X
- Я: Я смотрел на технологию X, и я не понимаю, как она поможет мне решить бизнес-проблему
- Архитектор: Что вы имеете в виду?
- Я: Ну, это то, что нам нужно сделать:… .. И это то, что технология X предполагает:…. Я не вижу, как они совпадают.
- Архитектор: Так что вы предлагаете использовать вместо этого?
- Я: Хм … Я думаю, что мы можем решить это с помощью простой Java. На самом деле, вчера вечером я сделал довольно хорошее подтверждение концепции.
- Потрясающий архитектор: Круто. Давайте использовать это.
Правило 3: последовательность не так важна, как вы думаете
Если бы у меня была копейка за каждый раз, когда я слышу это …
- Архитектор: «Да, я знаю, что этот путь может показаться неуклюжим, но вы должны это сделать. Видите ли, если вы этого не сделаете, система становится непоследовательной и невозможно поддерживать »
Конечно, я не часто работаю с техническим обслуживанием, но я знаю, что когда я имею дело с любой системой, самое сложное — это понять бизнес-логику для этой системы. Совместимость системы X (с одним набором бизнес-логики) и системы Y (с другим) очень низка в списке вещей, которые заставляют меня терять сон.
Тот факт, что система X ужасно сложна, потому что она имеет дюжину слоев, чтобы соответствовать системе Y — теперь это то, что заставляет меня хотеть вырвать мои волосы. Различные контексты имеют разные компромиссы.
О да: помните правило 0? Предположим, что разработчики в данном контексте пытаются создать хорошее решение для этого контекста.
О, да, еще одна вещь: я никогда не видел, чтобы что-то непостижимо сложное в малом становилось ремонтопригодным только потому, что мы стали большими.
Ах, да, еще одна вещь: если программист действительно убегает от кода, потому что у некоторых из них есть один стиль фигурных скобок, а у других — фигурные скобки в другом стиле, я потеряю всякую веру в человечество.
Правило 4: последовательность снизу вверх превосходит последовательность сверху вниз
Есть один способ, которым я смог создать больше согласованности внутри системы:
- Создайте эталонное приложение с архитектурой, которой легче следовать, чем ломать. Если вы сделаете это хорошо, разработчики покачают головой при самой идее отклонения от архитектуры. Если только они действительно не нужны. В этом случае все в порядке.
- Развивайте культуру перекрестного опыления: разработчики, которые видят код друг друга, имеют более согласованный код, чем разработчики, которые просто видят свой собственный код. Парное программирование, обзоры кода и сеансы обмена технологиями способствуют перекрестному опылению.
Правило 5: Тактическое повторное использование в разных системах — это субоптимизация
Повторное использование создает связь. Если система X и система Y повторно используют некоторые функциональные возможности, а система X требует, чтобы эти функциональные возможности были изменены, это повлияет на систему Y. По крайней мере, команда, работающая над системой X, должна принять решение сделать частный ответвление от повторно используемой функциональности, что означает что он больше не используется повторно. В худшем случае система Y получит ошибку из-за изменения в повторно используемой функциональности.
При повторном использовании в разных системах то, что вы используете, должно быть либо стабильным (скажем, платформа Java SE, либо чем-то настолько стабильным, что вы определенно не сделали это самостоятельно) или стратегическим. Под стратегическим повторным использованием я подразумеваю услуги, которые объединяют информацию, а не просто дублируют функциональность.
Другими словами: повторное использование должно быть либо использованием, либо интеграцией . Дублирование твой друг.
Правило 6: Различать правила и догмы
Есть три причины иметь правило в любом стандарте кодирования:
- Небезопасно: в коде есть ошибка, которая проявляется при некоторых (не теоретических) обстоятельствах
- Непонятно: «я» не понимаю, что происходит
- Ересь: код написан в стиле, который не нравится кому-то
Популярная викторина: Если у вас есть правило, которое гласит: «Все поля должны иметь комментарий JavaDoc», это проблема безопасности, проблема понятности или проблема ереси? Что, если стандарт использует этот пример:
/** * Contains the name value of the object */ private String name;
А как насчет правила, которое гласит: «нет новой строки перед открывающей фигурной скобкой»? А как насчет правила: «стиль, используемый для фигурных скобок, должен быть последовательным»? Это небезопасный код, непонятный код или ересь?
Мы должны больше заботиться о написании соответствующего кода для ситуации и меньше заботиться о том, чтобы успокоить богов последовательности.
Правило Омега: будь скромным
За годы, которые я работал с разработкой программного обеспечения, я видел больше вреда, причиненного архитекторами программного обеспечения, чем помощь. Как профессиональная роль, я думаю, мы бы сэкономили деньги, если бы избавились от них (нас). Даже если бы мы все-таки заплатили свою зарплату.
Когда вы занимаетесь профессией, которая причиняет больше вреда, чем предотвращает, у вас есть два варианта: вы можете попробовать и улучшить, или вы можете молиться, чтобы никто не заметил.