Биография автора приведена ранее.
Архитектор — прежде всего разработчикМайк Браун
Вы когда-нибудь слышали о судье, который не был бы юристом, или о заведующем хирургическим отделением, который не был бы хирургом? Даже достигнув того, что может считаться венцом их карьеры, люди, занимающие такие должности, продолжают осваивать новые разработки в своей области. Мы, архитекторы программного обеспечения, обязаны соответствовать тем же стандартам.
Как бы качественно ни было спроектировано решение, успех его реализации в существенной степени определяется тем, сможете ли вы привлечь на свою сторону разработчиков. А самый быстрый способ сделать это — завоевать их уважение и доверие. Всем известно, как проще всего завоевать доверие разработчика: ваш код — ваша «визитная карточка». Если разработчики будут знать, что вы не какой-то абстрактный мечтатель, не способный написать ни строчки кода, они будут меньше ворчать по поводу ухищрений, на которые вы «заставляете» их идти для отображения данных на странице, ведь вы способны с полным на то основанием сказать: «Можно сделать проще, всего лишь привязав датасет к гриду», — и им будет нечего возразить.
И хотя это не является моей непосредственной работой, я часто беру на себя некоторые наиболее сложные задачи. Во-первых, это интересно и помогает мне поддерживать на уровне свои навыки программирования; во-вторых, этим я наглядно показываю своим разработчикам, что мои слова не пустое сотрясание воздуха.
Архитектор должен стремиться к созданию решения осуществимого, удобного в сопровождении и, конечно, отвечающего сути задачи. Одним из критериев осуществимости решения является возможность адекватно оценить объем работы и усилия, необходимые для реализации элементов решения. Поэтому я считаю, что если вы проектируете систему, вы должны быть способны ее реализовать.
Майк Браун (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). С этим ничего не поделаешь! Современному программному обеспечению свойственно быстро устаревать. Если вы ожидаете, что ваша система будет запущена в реальную эксплуатацию и просуществует хотя бы несколько месяцев, смиритесь с тем, что сопровождающим ее разработчикам придется вносить в нее исправления. Отсюда вытекает ряд требований к системе:
• Ясность: должно быть сразу понятно, какую роль играет тот или иной компонент или класс.
• Удобство тестирования: насколько легко проверить вашу систему?
• Корректность: работает ли система так, как было задумано? Исключите исправления, вносимые на скорую руку.
• Трассируемость: сможет ли специалист-«пожарник», никогда прежде не видевший ваш код, диагностировать ошибку в работающей системе и исправить ее? Или же на то, чтобы войти в суть дела, ему потребуются два месяца?
Попробуйте представить себе, что будет, если какая-то другая команда откроет вашу базу кода и попытается в нем разобраться. Это наиважнейший аспект хорошей архитектуры. Систему необязательно чрезмерно упрощать или документировать до мельчайших подробностей; хороший дизайн во многих отношениях документирует сам себя. Кроме того, дизайн может проявлять себя в поведении системы во время эксплуатации. Например, система с «разросшейся» архитектурой, опутанной уродливыми зависимостями, в эксплуатации часто ведет себя, как зверь в клетке. Подумайте о других (обычно менее опытных) разработчиках, которым придется исправлять ошибки в вашей программе и отлаживать код.
В кругах разработчиков не любят термин «унаследованный», но на самом деле этот ярлык несет на себе любая программная система. И в этом нет ничего плохого, потому что такое определение может означать лишь то, что ваша система долговечна, соответствует ожиданиям пользователей и обладает коммерческой ценностью. Если программную систему никогда не называли унаследованной, ее, скорее всего, отправили пылиться на полке, так и не запустив, а это вряд ли можно считать свидетельством удачной архитектуры.
Дейв Андерсон (Dave Anderson) — главный специалист по разработке ПО в компании Liberty IT (Белфаст), которая поставляет IT-решения для компании Liberty Mutual, входящей в список Fortune 100. Дейв обладает более чем 10-летним опытом разработки ПО для многих ведущих IT-компаний в разных отраслях и странах.
Когда видите единственное решение, спросите другихТимоти Хай
Вероятно, вам уже доводилось слышать это высказывание. Каждый опытный архитектор знает: если он видит только одно решение задачи, это плохой признак.
Создание архитектуры программного обеспечения сводится к поиску наилучшего решения задачи при некоторых заданных ограничениях. Редко когда удается обеспечить выполнение всех требований и уложиться во все ограничения с первым же решением, которое пришло вам в голову. Обычно приходится идти на компромиссы, выбирая решение, лучше всего удовлетворяющее тем требованиям, которые определяются важнейшими приоритетами.
Если вы видите только одно решение текущей проблемы, это означает, что у вас отсутствует свобода выбора для поиска таких компромиссов. Вполне возможно, что это единственное решение окажется неудовлетворительным для некоторых заинтересованных в проекте сторон. Это означает также, что при смене приоритетов, обусловленной изменениями бизнес-окружения, у вашей системы не будет возможности адаптироваться к новым требованиям.
Такая ситуация крайне редко возникает из-за реального отсутствия альтернатив. Гораздо более вероятное объяснение — неопытность архитектора в предметной области конкретной задачи. Если вы знаете, что это относится к вам, не постесняйтесь обратиться за советом к кому-нибудь из более опытных в этом вопросе коллег.
Другое, более коварное проявление этой проблемы встречается при проектировании архитектуры «по привычке». Архитектор может иметь богатый опыт применения одного архитектурного стиля (например, трехуровневая система типа клиент-сервер), но ему не хватает знаний, чтобы определить, когда этот стиль неуместен. Если вы оказались в ситуации, когда решение известно вам сходу, без сопоставления с другими возможными вариантами, задержитесь, сделайте шаг назад и попытайтесь придумать другой способ решения той же задачи. Если это не получается, возможно, стоит обратиться за помощью.