97 этюдов для архитекторов программных систем
Шрифт:
Мы СОЗДАЕМ ИНСТРУМЕНТЫ. Создаваемые нами системы служат единственной цели (не считая того, что нам за них платят) — помогать кому-то (обычно кому-то другому) что-либо делать.
Мартин Хайдеггер (Martin Heidegger), известный немецкий философ XX века, исследовал, как люди воспринимают инструменты (и вообще «оборудование»). Человек использует инструмент для достижения определенной цели, причем сам инструмент является всего лишь вспомогательным средством.
Для успешного применения инструмент должен быть zuhanden («подручным», то есть «ложащимся в руку»). Иначе говоря, такой инструмент воспринимается непосредственно, он используется
Допустим, вы бьете молотком по гвоздю или пишете ручкой. Представьте себе всю непосредственность этих действий. Подумайте о том, каким образом инструмент становится естественным продолжением вашего тела.
Возможна и другая ситуация (обычно она свидетельствует о возникших проблемах): пользователь воспринимает инструмент как vorhanden («наличествующий», то есть «находящийся в руке»). Инструмент отделяется от цели; он находится перед вами, требуя вашего внимания. Он становится объектом отдельного исследования. Пользователь уже не может двигаться к цели; он должен разобраться с инструментом, прежде чем тот сможет хоть как-то приблизить его к ней. Нам как техническим специалистам свойственно воспринимать создаваемые нами для пользователей системы как vorhanden– инструменты — и в ходе работы над ними, и позднее, когда мы получаем сообщения о дефектах. Инструмент вполне закономерно является для нас объектом рассмотрения, предметом размышлений, исследовательской задачей. Это нечто требующее изучения.
Однако (и это очень важно!) пользователи смогут добиться успеха, применяя наш продукт, только в том случае, если для них это zuhanden-инструмент. Спроектированы ли ваши системы так, чтобы становиться «невидимыми» при использовании? Насколько естественно «ложится в руку» пользовательский интерфейс? Или же ваша система постоянно требует внимания, отвлекая пользователя от его цели?
Биография автора приведена ранее.
Найдите и удерживайте энтузиастов
Чед Лавинь
Формирование команды незаурядных разработчиков — одна из самых важных задач, решение которых обеспечивает успех программного проекта. О сохранении существующей команды говорят значительно реже, но эта задача не менее важна. Итак, вы должны тщательно отбирать команду разработчиков и старательно оберегать ее в ходе дальнейшей деятельности.
Вероятно, большинство читателей согласится с тем, что поиск первоклассных разработчиков требует проведения основательного технического собеседования. Но что следует понимать под «основательным»? Это вовсе не означает, что кандидат должен ответить на трудные вопросы о малоизвестных технических нюансах. Разумеется, проверка конкретных технических навыков является частью процесса, но превращение собеседования в сертификационный экзамен не гарантирует успеха. Вам нужны разработчики-энтузиасты, обладающие навыком поиска решений. Инструменты, которые вы используете сейчас, наверняка изменятся; вам нужны люди, способные успешно пойти на штурм задачи независимо от доступных технологий. Даже если человек может наизусть перечислить все методы API, это практически ничего не скажет вам о его склонностях и о его стремлении решать задачи.
С другой стороны, если вы попросите человека объяснить свой подход к диагностике проблем быстродействия, вы получите ясное представление о его методах решения задач. Хотите узнать, умеет ли разработчик извлекать опыт из полученных уроков? Спросите, что он изменил бы в своем последнем проекте, если бы получил возможность начать его заново. Хорошие разработчики относятся к своей работе с энтузиазмом. Этот энтузиазм
Потратив немало сил на формирование сильной команды, сделайте все, что в ваших силах, для ее сохранения. Возможно, некоторые удерживающие факторы (например, оплата) вам неподвластны, но позаботьтесь по крайней мере о тех мелочах, которые помогают сохранить здоровую рабочую среду. Хороших разработчиков часто стимулирует признание их заслуг. Используйте это обстоятельство и отмечайте выдающиеся достижения. Найти хорошего разработчика трудно; показать человеку, что его ценят, легко. Не упускайте простые возможности поднять дух и повысить производительность команды.
Будьте осторожны с порицанием. Избыток негатива подавляет творческое мышление, снижает производительность и, что еще хуже, разобщает команду. Хорошие разработчики умны и знают, что не могут все время ошибаться. Постоянно выискивая в их работе мелкие огрехи, вы потеряете их уважение. Ограничивайтесь конструктивной критикой и не требуйте, чтобы каждое решение выглядело так, будто вышло из ваших рук.
Важность правильного подбора команды разработчиков трудно переоценить. В любой команде есть «тяжеловесы», которым поручаются самые трудные задачи, но, когда дело доходит до оценок, все участники рассматриваются на равных. Позаботьтесь о сплоченности стартового состава, а когда вы успешно сформируете команду победителей, не пожалейте усилий на то, чтобы сохранить ее.
Биография автора приведена ранее.
Программы на самом деле не существуют
Чед Лавинь
Разработку программного обеспечения часто сравнивают с такими устоявшимися дисциплинами, как гражданское строительство. Однако у подобных аналогий имеется серьезный недостаток: в отличие от материальных продуктов, создаваемых в ходе строительства, программы в реальности не существуют — по крайней мере, в традиционном смысле слова. Обитатели мира нулей и единиц не связаны физическими законами, которые накладывают ограничения на классические инженерные парадигмы. Хотя в фазе проектирования ПО применение инженерных принципов дает достаточно хороший результат, предположение о том, что вы сможете воплотить созданный дизайн таким же образом, как это делается в традиционных инженерных подходах, выглядит малореалистичным.
Как бизнес, так и программное обеспечение — живые, динамичные сущности. Бизнес-требования быстро меняются под влиянием таких факторов, как появление новых деловых партнеров и маркетинговых стратегий. По этой причине очень сложно использовать в программном проекте те же подходы, что и в традиционном конструировании (например, строительстве мостов). Вряд ли вас попросят изменить местоположение моста в разгар строительства. В то же время с появлением нового делового партнера вполне может оказаться, что в приложение придется включить поддержку управления контентом на уровне организации. Мы часто говорим, что программные архитектурные решения трудно изменять, но все же это намного проще, чем изменять объекты, воплощенные в камне (как в буквальном, так и в переносном смысле).
Если вы изначально знаете, что создаваемые вами продукты пластичны, а предъявляемые к ним требования могут измениться, вы находитесь в совершенно ином положении, чем инженер, создающий статичный объект.
В инженерных проектах физического характера гораздо проще реализовать принцип «сначала план работ, потом работы по плану». К построению программных продуктов обычно приходится подходить по принципу «сначала план работ, потом подгонки плана».
Эти различия не обязательно ставят нас в невыгодное положение — иногда из них можно извлечь пользу. Например, вы не связаны требованием строить компоненты программных систем в определенном порядке, а значит, можете начать работу с самых рискованных вопросов. Это радикально отличает программный проект от строительства моста, где порядок выполнения задач обусловлен множеством жестких физических ограничений.