Отпуска и качество программного кода

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

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

Некоторые при этом склонны считать, что количество выходных непосредственно связано с уровнем экономики – мол, с народными гулянками в России с Украиной неудивительны низкие экономические рейтинги. Для меня этот аргумент не самый убедительный – в той же Дании отпуск составляет 6 недель, а в Австрии и все 7, между тем и в плане ВВП, и дохода на душу населения обе страны далеки от нищеты.

Разнобой среди американских компаний позволяет проводить интересные сравнения касательно влияния отпускной политики на другие внутренние процессы.

Например, в Yahoo! у меня было 10 дней отпуска. С каждым годом службы добавлялось еще по одному, и так аж до максимальных 15. Зато копить эти отпускные можно было в течение 5 лет, и если на работе торчать уж совсем все время, то за 5 лет можно было набрать теоретический максимум в 10 + 11 + 12 + 13 + 14 = 60 дней, т.е. 12 рабочих недель.

Отпускная политика Facebook отличается как по количеству дней, так и по накоплению – в год дают 21 отпускной, однако сгорают они через 1,5 года. Легче всего эту схему понять так – после года работы у человека будет 168 отпускных часов (в понятии HR рабочий день = 8 рабочих часов), с каждой проработанной неделей количество этих часов будет пропорционально увеличиваться, однако после 252 часов ничего расти не будет – достигнут максимум.

Политика отпусков, являясь обычно уделом HR-отдела компании, зачастую вносит стратегические изменения в другие процессы. Если первая описанная схема акцентирует внимание на накоплении отпускных (чем многие и занимались в Yahoo!, периодически срываясь на длительный тур в места весьма удаленные), то второй практически заставляет сотрудника уходить в отпуск весьма часто. В итоге получается, что народ в такой компании планирует несколько отпусков в течение года, варьируя конкретные точки в зависимости от климата и семейных предпочтений.

Как же это влияет на разработку?

1. Командная ответственность вместо личной. Отпуск перестает быть из ряда вон выходящим событием и становится явлением обыденным. Ни один кусок кода не идет в релиз без предварительного одобрения другим разработчиком в той же команде, поскольку весьма реально, что автор будет в отпуске как раз в тот момент, когда все начнет ломаться. Для каждого еженедельного релиза генератор случайных сотрудников назначает «смотрящего» от каждой команды (и этот генератор тоже умеет залезать в нужную базу данных и смотреть, кто из команды находится в отпуске). Если во время релиза задания спускаются «смотрящему», он чаще всего отдает баги изначальному разработчику, однако если того нет на месте (вероятность в 8%, основываясь на 21 дне отпуска и 52 x 5 = 260 рабочих дней в году), баг уходит человеку, который этот кусок кода одобрил, если же нет и того, «смотрящий» должен опираться на специфику своей команды. Сделать коммит крупного непротестированного куска кода и уехать в отпуск в неделю релиза – лучший способ очернить профессиональную репутацию.
2. Юнит-тесты. Из пункта 1 понятно, что немалая доля ответственности ложится на человека, сделавшего code review. Поэтому он вправе требовать написания дотошнейших юнит-тестов до того, как кусок кода уйдет в коммит. Причем сообщения об ошибках должны быть предельно понятными человеку, который начал работу в компании буквально вчера и содержать инструкции по возможным причинам сбоев. Т.е. сообщение об ошибке «Получено нулевое значение для переменной X» не пройдет, а сообщение «Х не содержит правильного ID пользователя, возможно, упала база данных, или этот кусок кода каким-то образом выполняется для незалогиненных пользователей» пройдет. Когда этих юнит-тестов набирается добрая куча, их можно прогонять на всякий случай ежечасно. Итого имеем вроде как и test-driven development, но процесс не навязан свыше, а выстрадан мучениями команд.
3. Создание отпусков автоматизировано. В большинстве компаний для ухода в отпуск нужно заполнить специальную форму (в Yahoo! эта форма была еще бумажной) и заверить у менеджера. В Facebook для этого существует онлайн-инструмент, позволяющий декларировать отпускные. Код этого инструмента виден другим разработчикам, итого периодически он обрастает приятными удобностями. Можно подписываться на отпускные оповещения других, а люди, работа которых опирается на ваше присутствие, могут подписываться на ваши оповещения. Менеджеры подписаны на оповещения своих подчиненных автоматом. Вся эта информация интегрирована как в различные инструменты разработчика (если добавлять к code review человека в отпуске, он будет помечен специальной иконкой), так и в Outlook, календари и другие корпоративные системы.
4. Возрастают требования к документации. Каждый раз, когда пишешь новый модуль, пользоваться которым могут другие разработчики (а в коде веб-сайта это, по сути, каждая функция и класс), по умолчанию документируешь читабельным языком причину его написания, примеры использования, всяческие нюансы, которые полезно знать. Если разработчик назначен рецензентом на чужой код и видит новый фрагмент без такой документации, код возвращается на доработку.
5. Повышенные требования к инструментам мониторинга. Наблюдать за процессами в дистрибутивной среде в большинстве случаев нетривиально. Если у вас всего один веб-сервер, то его лог можно смотреть в режиме реального времени. Если база данных одна, нагрузку и логи можно смотреть непосредственно на железе, где она крутиться. Когда и серверы, и хранилище данных распределены, возникают естественные вопросы «А как узнать, работает ли оно?» и «А вот если оно сломается, как мы узнаем об этом?» В итоге код для нетривиального и труднопроверяемого функционала чаще всего должен снабжаться каким-то инструментом для мониторинга, чтобы любой случайный человек мог зайти на страничку с мониторингом и сказать «А что у нас случилось с загрузкой фоток под Internet Explorer 7 два часа назад?»
6. Отключаемость кода после релиза. В редких случаях определенный функционал нужно отключить, не выкатывая релиз заново. Это может произойти по вине разработчика (не просчитал все варианты исполнения, что-то сломалось, а человек в отпуске), по вине системы (упал сервер отгрузки пользовательских видео, или ушел сервер поиска), либо по вине партнера (броузеры на Motorola RAZR , если ваша страница превысила 10 КБ HTML'а). Для разработчика это еще один способ успокоить рецензентов, так как гарантирует им, что в случае появления самых невероятных проблем в его отсутствие новый код можно будет отключать легким движением руки.

Запись в итоге превратилась в подобие «Вещей, которые должен знать технический руководитель», что неудивительно. Большинство презентаций о полезности тестирования либо мониторинга начинаются с весьма черного вопроса «Что делать, если разработчик попал под поезд?» И один из практических примеров проверки того, зависит ли группа разработчиков от конкретного человека, либо же является распределенным организмом – это мотивировать народ почаще уходить в отпуск.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365