Архитектор должен также знать и понимать суть различных антипаттернов. Антипаттерны (термин введен Эндрю Кенигом (Andrew Koenig)) представляют собой повторяемые процессы, приводящие к неэффективным результатам. Вот хорошо известные примеры антипаттернов: Analysis Paralysis (аналитический паралич), Design By Committee (разработка комитетом), Mushroom Management (управление грибами), Death March (путь камикадзе ). Знание этих шаблонов поможет вам избежать многих типичных ошибок. Список распространенных антипаттернов приведен по адресу .
Архитекторы программного обеспечения должны уметь общаться друг с другом ясным, лаконичным и эффективным образом. На помощь приходят шаблоны; нам, архитекторам, остается лишь изучить и понять их.
Биография автора приведена ранее.
Правила диктует контекст Эдвард Гарсон
Что в большей степени присуще архитекторам вашей организации: необузданная интеллектуальная мощь и способность помнить мельчайшие технические детали или хороший вкус, изысканность и душевная щедрость? В какой атмосфере предпочли бы работать вы сами?
Врач может похоронить свою ошибку, архитектор разве что обсадить стены плющом.Фрэнк Ллойд Райт
Архитекторы не только верят, что сидят по правую руку от Бога, но и считают, что если Бог встанет, то они займут его место.Карен Мойер (Karen Moyer)
В архитектуре, как и во всех остальных прикладных видах искусства, конечная цель управляет действием. Конечная цель хорошо построенное здание. Такое здание обладает тремя свойствами: Удобство, Прочность и Эстетичность.Генри Уоттон (Henry Watton)
Человек, не являющийся великим скульптором или художником, не может быть архитектором. Если он не скульптор, не художник, то сможет быть только строителем.Джон Раскин (John Rushin)
И наконец, высказывание, не требующее комментариев, верное средство от самого разрушительного синдрома в работе архитектора:
Это выглядит фантастическим парадоксом, но тем не менее является важнейшей истиной: абсолютно совершенная архитектура не может быть действительно великой.Джон Раскин
Боритесь с повторениями Никлас Нильссон
разработчикам выполнять однообразные задания, над которыми почти не нужно думать? Попадаются ли в коде почти одинаковые фрагменты? Замечаете ли вы код, написанный методом «скопировать-вставить-изменить»? Если ответы положительные, то ваша команда работает медленнее, чем могла бы, и, как ни странно, причиной тому можете быть именно вы.
Прежде чем пускаться в объяснения, давайте договоримся о двух истинах, касающихся разработки программного обеспечения:
Дублирование это зло.
Повторяющаяся работа замедляет разработку.
Вы как архитектор задаете тон. Вы лучше всех представляете себе систему в целом, и, скорее всего, именно вы задали направление работы, создав полный вертикальный срез системы пример, который к настоящему моменту был неоднократно скопирован. Каждая операция копирования (копирует ли разработчик несколько строк кода, XML-файл или класс) свидетельствует о том, что в системе что-то можно упростить или выкинуть. Чаще всего копируется не логика предметной области, а инфраструктурный код, обеспечивающий ее работу. По этой причине очень важно, чтобы вы четко представляли себе возможный эффект от своих примеров. Любые фрагменты кода, любые примеры конфигурации в ваших примерах станут основой для десятков, сотен и тысяч других частей системы. Следовательно, вы обязаны следить за тем, чтобы ваш код был понятным, хорошо передавал ваши намерения и не содержал ничего, кроме самого существенного логики предметной области. Как архитектор вы должны быть крайне чувствительны к любым повторам, потому что все, что вы пишете, будет повторено.
В вашей системе такого не происходит, правда? А теперь взгляните на этот конфигурационный файл: что потребует изменения, если применить его к другой части системы, а что останется прежним? Или возьмите типичный метод уровня бизнес-логики: нет ли в нем шаблона, который проявляется и в других методах с такими операциями, как обработка транзакций, легирование, аутентификация или аудит? А как насчет уровня доступа к данным? Часто ли встречаются одинаковые фрагменты, отличающиеся только именами сущностей и полей? Смотрите на вещи шире. Попадаются ли вам две-три строки кода, которые всегда идут рядом и воспринимаются как одно целое, хотя и работают с разными объектами? Все это примеры повторения. Со временем разработчики учатся отсеивать и игнорировать повторения при чтении кода, обращая внимание лишь на интересные отличия. Но даже при наличии такого навыка чтение кода тормозится. Такой код подходит для выполнения компьютером, но не для чтения разработчиками.
Ваша прямая обязанность избавиться от повторений. Возможно, для этого вам придется освоить новую инфраструктуру, создать более совершенные абстракции, обратиться к специалистам для создания аспектной инфраструктуры или написать несколько небольших генераторов кода. И все же повторения никуда не исчезнут, пока кто-то специально не позаботится об этом.