Чед Фаулер - Программист-фанатик

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

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

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

А как быть, если ошибка приводит к необходимости модернизации подсистемы приложения? Но то же самое относится к исправлению ошибок, не так ли? Проект может оказаться старым и допотопным, а вся система заполненной разбитыми окнами. [15] Подробно «разбитые окна» описываются в книге Дэйва Томаса и Энди Ханта The Pragmatic Programmer: From Journeyman to Master («Программист-прагматик. Путь от подмастерья к мастеру»). Это возможность испытать твои навыки переделки. Насколько элегантной можно сделать эту систему? Насколько быстрее можно будет исправить или улучшить этот раздел в следующий раз после выполненной сейчас переделки?

Отдел технической поддержки также может стать местом свободы и творчества.

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

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

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

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

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

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

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

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