Не является ли «сопровождение унаследованных систем» лишь подрезкой этого плюща? Хватит ли вам как архитектору силы духа уничтожить собственное неудачное творение? Или вы предпочтете просто прикрыть его? Райт сказал также, что лучшим другом архитектора является кувалда. А что вы разбили ею за последнее время?
Архитекторы не только верят, что сидят по правую руку от Бога, но и считают, что если Бог встанет, то они займут его место.
Карен Мойер (Karen Moyer)
Замените «Бог» на «заказчик».
В архитектуре, как и во всех остальных прикладных видах искусства, конечная цель управляет действием. Конечная цель — хорошо построенное здание. Такое здание обладает тремя свойствами: Удобство, Прочность и Эстетичность.
Генри Уоттон (Henry Watton)
Когда вам в последний раз попадался на глаза программный продукт, архитектура которого доставила вам эстетическое удовольствие? А вы сами стремитесь к тому, чтобы ваши работы были эстетичными?
Человек, не являющийся великим скульптором или художником, не может быть архитектором. Если он не скульптор, не художник, то сможет быть только строителем.
Джон Раскин (John Rushin)
Занимает ли эстетика достойное место в вашей архитектуре? Движет ли вами в ходе объединения компонентов при построении систем художественный интерес к формам и текстурам, скульптурное чувство баланса и стремление к передаче движения либо ощущение важности отрицательного пространства?
И наконец, высказывание, не требующее комментариев, — верное средство от самого разрушительного синдрома в работе архитектора:
Это выглядит фантастическим парадоксом, но тем не менее является важнейшей истиной: абсолютно совершенная архитектура не может быть действительно великой.
Джон Раскин
Биография автора приведена ранее.
Боритесь с повторениями
Никлас Нильссон
Приходится ли вашим разработчикам выполнять однообразные задания, над которыми почти не нужно думать? Попадаются ли в коде почти одинаковые фрагменты? Замечаете ли вы код, написанный методом «скопировать-вставить-изменить»? Если ответы положительные, то ваша команда работает медленнее, чем могла бы, и, как ни странно, причиной тому можете быть именно вы.
Прежде чем пускаться в объяснения, давайте договоримся о двух истинах, касающихся разработки программного обеспечения:
• Дублирование — это зло.
• Повторяющаяся работа замедляет разработку.
Вы как архитектор задаете тон. Вы лучше всех представляете себе систему в целом, и, скорее всего, именно вы задали направление работы, создав полный вертикальный срез системы — пример, который к настоящему моменту был неоднократно скопирован. Каждая операция копирования (копирует ли разработчик несколько строк кода, XML-файл или класс) свидетельствует о том, что в системе что-то можно упростить или выкинуть. Чаще всего копируется не логика предметной области, а инфраструктурный код, обеспечивающий ее работу. По этой причине очень важно, чтобы вы четко представляли себе возможный эффект от своих примеров. Любые фрагменты кода, любые примеры конфигурации в ваших примерах станут основой для десятков, сотен и тысяч других частей системы. Следовательно, вы обязаны следить за тем, чтобы ваш код был понятным, хорошо передавал ваши намерения и не содержал ничего, кроме самого существенного — логики предметной области. Как архитектор вы должны быть крайне чувствительны к любым повторам, потому что все, что вы пишете, будет повторено.
В вашей системе такого не происходит, правда? А теперь взгляните на этот конфигурационный файл: что потребует изменения, если применить его к другой части системы, а что останется прежним? Или возьмите типичный метод уровня бизнес-логики: нет ли в нем шаблона, который проявляется и в других методах с такими операциями, как обработка транзакций, легирование, аутентификация или аудит? А как насчет уровня доступа к данным? Часто ли встречаются одинаковые фрагменты, отличающиеся только именами сущностей и полей? Смотрите на вещи шире. Попадаются ли вам две-три строки кода, которые всегда идут рядом и воспринимаются как одно целое, хотя и работают с разными объектами? Все это примеры повторения. Со временем разработчики учатся отсеивать и игнорировать повторения при чтении кода, обращая внимание лишь на интересные отличия. Но даже при наличии такого навыка чтение кода тормозится. Такой код подходит для выполнения компьютером, но не для чтения разработчиками.
Ваша прямая обязанность — избавиться от повторений. Возможно, для этого вам придется освоить новую инфраструктуру, создать более совершенные абстракции, обратиться к специалистам для создания аспектной инфраструктуры или написать несколько небольших генераторов кода. И все же повторения никуда не исчезнут, пока кто-то специально не позаботится об этом.
И этот кто-то — вы.
Биография автора приведена ранее.
Добро пожаловать в реальный мир
Грегор Хоп
Технари любят точность — особенно программисты, живущие в мире нулей и единиц. Они привыкли работать с двоичными решениями: один/ноль, истина/ложь, да/нет. Всё четко и последовательно, от неожиданностей защищают ограничения внешних ключей, атомарные транзакции и контрольные суммы.
К сожалению, реальный мир не столь упорядочен. Клиенты оформляют заказы, а через секунду отменяют их. Чеки отклоняются, письма теряются, платежи задерживаются, а обещания нарушаются. Ошибки ввода данных происходят чаще, чем нам хотелось бы. Пользователи предпочитают «плоские» («shallow») интерфейсы, которые предоставляют одновременный доступ ко многим функциям, а не длинный и узкий коридор «процесса» ввода данных, который проще реализуется и кажется многим разработчикам более «логичным». Ходом выполнения программы управляет уже не стек вызовов, а пользователь.
Распределенные системы только усугубляют положение, потому что в игру вступает уйма новых несогласованностей. Службы бывают недоступны, изменяются без предварительного уведомления и не предоставляют транзакционных гарантий. При выполнении приложения на тысячах компьютеров вопрос уже не в том, произойдет ли сбой, а в том, когда он произойдет. Такие системы обладают слабой связанностью (loosely coupled), асинхронностью и параллелизмом и не соответствуют традиционной транзакционной семантике… Не желаете принять синюю таблетку?!
Дивный новый мир компьютерных технологий трещит по швам — так что же нам делать? Как это часто бывает, осознание проблемы становится первым важным шагом к ее решению.
Распрощайтесь со старой доброй детерминированной архитектурой стека вызовов, в которой вы сами определяли, что, когда и в каком порядке происходит. Вместо этого будьте готовы реагировать на события в любое время и в любом порядке, восстанавливая состояние системы по мере необходимости. Выдавайте асинхронные запросы параллельно вместо последовательного вызова методов. Чтобы избежать полного хаоса, моделируйте свое приложение, используя управляемые событиями цепочки процессов или модели состояний. Нейтрализуйте ошибки посредством коррекции, повторных попыток или тестовых операций.
Звучит слишком устрашающе? Вы на такое не рассчитывали? К счастью, в реальном мире с похожими проблемами имеют дело уже давно: задержки писем, нарушенные обещания, перепутанные сообщения, платежи не на те счета — примеров не счесть. Соответственно люди вынуждены посылать письма заново, списывать некорректные заказы и игнорировать напоминания об уже произведенных платежах. Не вините реальный мир в своих проблемах — лучше используйте его, чтобы подсмотреть решения. В конце концов, Starbucks тоже не использует протокол двухфазной фиксации.[29] Добро пожаловать в реальный мир!
