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

Часто возникает сильное желание оправдать решения предполагаемой выгодой или прогнозируемыми требованиями. Запомните: когда вы пытаетесь угадать будущие требования, в 50 % случаев вы ошибаетесь, а в 49 % — очень-очень сильно ошибаетесь. Решайте проблемы по мере их поступления. Сдайте приложение вовремя и дождитесь обратной связи, чтобы сформулировать реальные требования. Созданная вами простая архитектура намного упростит реализацию новых требований в случае их поступления. А если вы все же угадаете и спрогнозированные вами требования станут реальными к следующей версии, то у вас уже будет в голове готовое решение. Отличие в том, что теперь вы сможете выделить для него должное время, потому что оно действительно необходимо. И вы с вашей командой опомниться не успеете, как завоюете репутацию профессионалов, способных хорошо оценить задачу и справиться со своей работой в срок.

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

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

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

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

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

Майк Браун (Mike Brown) — ведущий разработчик в компании Software Engineering Professionals, Inc. (http://www.sep.com). Обладает 13-летним опытом работы в сфере информационных технологий, включая 8 лет разработки корпоративных решений для разнообразных вертикальных рынков. Является учредителем группы пользователей Indianapolis Alt.NET, соучредителем WPF Disciples, а также организатором группы профессиональных пользователей Indy Arc.

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

Одним из показателей успешности инвестиций является окупаемость (ROI, Return on Investment). Например: мы предполагаем, что дополнительные затраты времени на создание тестов уменьшат количество ошибок в следующем выпуске приложения. Размер инвестиций в этом случае определяется временем, потраченным на написание тестов, а прибыль — это время, сэкономленное на исправлении ошибок в будущем, плюс удовлетворение клиентов, работающих с более качественной программой. Допустим, в настоящее время 10 из 40 рабочих часов в неделю тратятся на исправление ошибок. По нашим оценкам, выделив 4 часа в неделю на тестирование, мы сократим затраты времени на исправление ошибок до 2 часов в неделю, фактически получив 8 свободных часов, которые можно вложить во что-то другое. Прогнозируемая окупаемость составляет 200 %[35] (8 часов, сэкономленных на исправлении ошибок, делим на 4 часа, потраченных на тестирование).

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

Рассматривайте архитектурные решения как инвестиции и анализируйте связанную с ними окупаемость; это полезный метод оценки реалистичности и практичности имеющихся вариантов.

Джордж Маламидис (George Malamidis) — разработчик программного обеспечения в компании TrafftcBroker (Лондон). До этого был ведущим консультантом и ведущим техническим специалистом в ThoughtWorks. Участвовал в разработке и внедрении критических приложений в разных областях, от сетевых и финансовых приложений до Web 2.0.

Даже если вы создаете сверхсовременную систему на базе новейших технологий, для вашего преемника она станет унаследованной (legacy). С этим ничего не поделаешь! Современному программному обеспечению свойственно быстро устаревать. Если вы ожидаете, что ваша система будет запущена в реальную эксплуатацию и просуществует хотя бы несколько месяцев, смиритесь с тем, что сопровождающим ее разработчикам придется вносить в нее исправления. Отсюда вытекает ряд требований к системе:

• Ясность: должно быть сразу понятно, какую роль играет тот или иной компонент или класс.