Программист-фанатик - [41]

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

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

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

Действуй!

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

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

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

Совет 28 Восьмичасовое пламя

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

Боб Мартин,[16] один из корифеев сообщества экстремального программирования, перевернул эту фразу таким образом, что умудрился примирить с ней обе партии, не отступая от первоначальных постулатов Кента Бека. Мартин переименовал сорокачасовую рабочую неделю в «восьмичасовое пламя». Основная идея состоит в том, что человек должен работать настолько интенсивно, что просто не сможет работать больше восьми часов.

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

Когда дело доходит до работы, меньшее может превратиться в большее. Экстремальные программисты любят повторять, что уставший человек не может работать с той же эффективностью, что и отдохнувший. Когда мы доходим до предела, творческий подход угасает, а качество работы существенно снижается. Мы начинаем делать глупые ошибки, которые стоят нам времени и денег.

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