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

взаимодействия возрастают более чем вдвое по сравнению с командой из двух человек.

• Наши оценки — отнюдь не точная наука. Кто из нас не попадал в ситуацию, когда реализация какой-то функции оказывалась намного сложнее, чем предполагалось вначале.

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

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

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

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

Демонстрируйте результаты как можно скорее. Люди редко понимают, что им нужно, пока не получат какой-нибудь результат. В известном комиксе[18] представлена эволюция проекта детских качелей: что сказал заказчик и как его требования поняли участники проекта, выполняющие те или иные роли. В итоге получается хитроумное сооружение, лишь отдаленно напоминающее качели. А на последнем рисунке под названием «Чего хотел заказчик» изображены простейшие качели из автомобильной покрышки на веревке. Когда у заказчика есть что-то, что он может самолично испытать, решение порой оказывается проще, чем предполагалось. При первоочередной реализации самых важных функций вы в качестве обратной связи получаете самую важную информацию на ранней стадии, когда она нужна больше всего.

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

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

Ответственное руководство важнее внешнего впечатления

Барри Хокинс

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

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

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

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

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

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

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

У программной архитектуры есть этические аспекты

Майкл Найгард

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

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

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

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

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

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

Неэтично усложнять