97 этюдов для архитекторов программных систем - Нил Форд

позаботиться о том, чтобы в архитектуре для всех них были выделены подходящие роли. Архитектура, спроектированная с учетом только одной «расы», привлечет к проекту представителей именно этой «расы». И даже если в составе команды будут самые умелые «гномы», или самые талантливые «эльфы», или самые могущественные «волшебники», однобокий подход к решению задач будет серьезно ограничивать возможности команды.

Хороший король ведет все «расы» подданных к великой цели и помогает им трудиться бок о бок, чтобы достичь ее. Без великой цели у команды не будет видения, а ее работа в конечном итоге превратится в партизанские вылазки. Без представителей всех «рас» команда сможет решать проблемы только одного типа и остановится у первой же преграды, не соответствующей этому решению.

Архитектор указывает цель, принимая в расчет особенности всех «рас». Тогда архитектура становится руководством по поиску таких задач, которыми смогут заниматься члены команды из разных «рас», пока будут больше узнавать друг о друге. Когда проект столкнется со сложностями, команда уже будет знать, как подходить к их преодолению, потому что архитектура дала команде возможность стать одним целым.

Эван Кофски (Evan Cofsky) — программист, музыкант-любитель и заядлый мотоциклист. Он увлекся музыкой и компьютерами в колледже и продолжает увлеченно заниматься ими до сих пор. В настоящее время является штатным экспертом по языку Python в компании Virgin Charter, где в должности ведущего разработчика возглавляет команду исключительно талантливых и разносторонних людей.

Учитесь у архитекторов зданий

Кейт Брайтуэйт

Архитектура — социальный акт и материальный театр человеческой активности.

Спиро Костоф (Spiro Kostof)

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

Архитектор становится великим благодаря не столько уму, сколько чистому, чуткому сердцу.

Фрэнк Ллойд Райт (Frank Lloyd Wright)

Что в большей степени присуще архитекторам вашей организации: необузданная интеллектуальная мощь и способность помнить мельчайшие технические детали или хороший вкус, изысканность и душевная щедрость? В какой атмосфере предпочли бы работать вы сами?

Врач может похоронить свою ошибку, архитектор — разве что обсадить стены плющом.

Фрэнк Ллойд Райт

Не является ли «сопровождение унаследованных систем» лишь подрезкой этого плюща? Хватит ли вам как архитектору силы духа уничтожить собственное неудачное творение? Или вы предпочтете просто прикрыть его? Райт сказал также, что лучшим другом архитектора является кувалда. А что вы разбили ею за последнее время?

Архитекторы не только верят, что сидят по правую руку от Бога, но и считают, что если Бог встанет, то они займут его место.

Карен Мойер (Karen Moyer)

Замените «Бог» на «заказчик».

В архитектуре, как и во всех остальных прикладных видах искусства, конечная цель управляет действием. Конечная цель — хорошо построенное здание. Такое здание обладает тремя свойствами: Удобство, Прочность и Эстетичность.

Генри Уоттон (Henry Watton)

Когда вам в последний раз попадался на глаза программный продукт, архитектура которого доставила вам эстетическое удовольствие? А вы сами стремитесь к тому, чтобы ваши работы были эстетичными?

Человек, не являющийся великим скульптором или художником, не может быть архитектором. Если он не скульптор, не художник, то сможет быть только строителем.

Джон Раскин (John Rushin)

Занимает ли эстетика достойное место в вашей архитектуре? Движет ли вами в ходе объединения компонентов при построении систем художественный интерес к формам и текстурам, скульптурное чувство баланса и стремление к передаче движения либо ощущение важности отрицательного пространства?

И наконец, высказывание, не требующее комментариев, — верное средство от самого разрушительного синдрома в работе архитектора:

Это выглядит фантастическим парадоксом, но тем не менее является важнейшей истиной: абсолютно совершенная архитектура не может быть действительно великой.

Джон Раскин

Биография автора приведена ранее.

Боритесь с повторениями

Никлас Нильссон

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

Прежде чем пускаться в объяснения, давайте договоримся о двух истинах, касающихся разработки программного обеспечения:

• Дублирование — это зло.

• Повторяющаяся работа замедляет разработку.

Вы как архитектор задаете тон. Вы лучше всех представляете себе систему в целом, и, скорее всего, именно вы задали направление работы, создав полный вертикальный срез системы — пример, который к настоящему моменту был неоднократно скопирован. Каждая операция копирования (копирует ли разработчик несколько строк кода, XML-файл или класс) свидетельствует о том, что в системе что-то можно упростить или выкинуть. Чаще всего копируется не логика предметной области, а инфраструктурный код, обеспечивающий ее работу. По этой причине очень важно, чтобы вы четко представляли себе возможный эффект от своих примеров. Любые фрагменты кода, любые примеры конфигурации в ваших примерах станут основой для десятков, сотен и тысяч других частей системы. Следовательно, вы обязаны следить за тем, чтобы ваш код был понятным, хорошо передавал ваши намерения и не содержал ничего, кроме самого существенного — логики предметной области. Как архитектор вы должны быть крайне чувствительны к любым повторам, потому что все, что вы пишете, будет повторено.

В вашей системе такого не происходит, правда? А теперь взгляните на этот конфигурационный файл: что потребует изменения, если применить его к другой части системы, а что останется прежним? Или возьмите типичный метод уровня бизнес-логики: нет ли в нем шаблона, который проявляется и в других методах с такими операциями, как обработка транзакций, легирование, аутентификация или аудит? А как насчет уровня доступа к данным? Часто ли встречаются одинаковые фрагменты, отличающиеся только именами сущностей и полей? Смотрите на вещи шире. Попадаются ли вам две-три строки кода, которые всегда идут рядом и воспринимаются как одно целое, хотя и работают с разными объектами? Все это примеры повторения. Со временем разработчики учатся отсеивать и игнорировать повторения при чтении кода, обращая внимание лишь на интересные отличия. Но даже при наличии такого навыка чтение кода тормозится. Такой код подходит для выполнения