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

Ответственное руководство — вот достойная роль для архитектора. Архитектор должен действовать в интересах заказчика, а не потворствовать капризам своего эго.

Деятельность архитектора программного обеспечения направлена на удовлетворение потребностей пользователей чаще всего на основании указаний от тех, кто разбирается в предметной области лучше него. Успешная разработка ведет к поиску компромиссов между затратами/сложностью реализации и временем/рабочей силой, доступными для выполнения проекта.

Время и затрачиваемые усилия — ресурсы, принадлежащие компании; архитектор должен управлять ими добросовестно, без скрытых попыток реализовать собственные цели. Чрезмерно сложные системы на базе новомодных инфраструктур или технологий редко обходятся без дополнительных затрат со стороны компании. Архитектору, словно инвестиционному брокеру, доверены деньги клиентов — и при этом предполагается, что его работа обеспечит приемлемую окупаемость инвестиций.

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

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

Этический аспект программного обеспечения становится очевидным, когда речь заходит о гражданских правах, хищении личных данных или вредоносных программах. Однако он проявляется и в менее экзотических обстоятельствах. Успешно работающие программы влияют на жизнь тысяч, а то и миллионов людей. Их влияние может быть как положительным, так и отрицательным. Программы способны улучшить или ухудшить нашу жизнь — пусть даже в незначительной степени.

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

На эту проблему можно взглянуть и с точки зрения эффекта масштаба. Вспомните истории о последних интернет-червях или фильмах-блокбастерах. Наверняка вам встречались подсчеты того, сколько рабочих часов было потеряно из-за них в масштабах страны. Всегда можно найти какого-нибудь аналитика с оценками неслыханного ущерба, нанесенного чем-нибудь, способным отвлечь человека от рабочего стола. Мораль этой истории вовсе не в обличении математического невежества прессы и дешевой погони за сенсациями. В действительности речь здесь идет о том эффекте, который могут дать маленькие числа в большом масштабе.

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

Обязательные поля выглядят довольно безобидно, но с ними вы навязываете свою волю пользователям, заставляя их собирать дополнительную информацию до начала работы. А это часто означает, что данные придется записывать на бумажках, чтобы собрать их в одном месте и ввести в систему единовременно. Все это ведет к потере данных и задержкам, а также вызывает раздражение у пользователей.

Рассмотрим такую аналогию: допустим, мне нужно прикрепить на здание вывеску. Можно ли смонтировать ее на высоте 1,8 м, заставляя тем самым пешеходов нырять под нее или обходить ее стороной? Конечно, мне будет проще обойтись без лестниц и строительных лесов, при этом вывеска даже не будет полностью перекрывать движение. Я экономлю час на установке ценой двух секунд, которые я отнимаю у каждого пешехода, проходящего мимо моего магазина. С течением времени сумма этих двухсекундных потерь намного превысит сэкономленный мною час.

Неэтично усложнять жизнь другим (даже ненамного) только для того, чтобы немного упростить ее для себя. Успешные программы влияют на жизнь миллионов людей, но каждое принятое вами решение фактически навязывает вашу волю пользователям. Всегда помните о том, что ваши решения повлияют на жизнь этих людей. Будьте готовы взять на себя дополнительную ношу, чтобы снять часть груза с ваших пользователей.

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

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

Самая трудная часть строительства не проектирование здания, которое будет стоять на своем месте после завершения, а проработка процесса строительства. Этот процесс начнется с пустой площадки и завершится готовым зданием. За это время каждый рабочий должен иметь возможность применить свои профессиональные навыки, а частично возведенное строение должно оставаться устойчивым. Мы можем извлечь из этой аналогии полезный урок в том, что касается развертывания больших интегрированных систем. (А к категории «интегрированных» относятся практически все корпоративные и веб-приложения!) Традиционное развертывание по схеме «Большого взрыва» выглядит так, словно вы привезли на пустырь груду балок и брусьев, подбросили их в воздух и ожидаете, что они сами сложатся в форме здания.

Вместо этого следует планировать развертывание по одному компоненту. Такой подход обладает двумя заметными преимуществами как при замене существующей системы, так и при строительстве с нуля.

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

Во-вторых, последовательное развертывание заставляет нас создавать четко определенные интерфейсы между компонентами. Развертывание одного компонента новой системы часто подразумевает его обратную интеграцию со старой системой. Следовательно, к моменту завершения развертывания каждый компонент успеет поработать с двумя разными системами: исходной и замещающей. Тем самым покомпонентное развертывание автоматически улучшает возможность повторного использования компонентов. На практике это приводит также к увеличению сцепления (coherence) и уменьшению связанности (coupling) системы.

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

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