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

Вероятно, большинство читателей согласится с тем, что поиск первоклассных разработчиков требует проведения основательного технического собеседования. Но что следует понимать под «основательным»? Это вовсе не означает, что кандидат должен ответить на трудные вопросы о малоизвестных технических нюансах. Разумеется, проверка конкретных технических навыков является частью процесса, но превращение собеседования в сертификационный экзамен не гарантирует успеха. Вам нужны разработчики-энтузиасты, обладающие навыком поиска решений. Инструменты, которые вы используете сейчас, наверняка изменятся; вам нужны люди, способные успешно пойти на штурм задачи независимо от доступных технологий. Даже если человек может наизусть перечислить все методы API, это практически ничего не скажет вам о его склонностях и о его стремлении решать задачи.

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

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

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

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

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

Программы на самом деле не существуют

Чед Лавинь

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

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

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

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