О Windows из первых рукНе слабо внести правку?

Рэймонд Чен (Raymond Chen)

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

Если им не окажетесь вы.

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

Но попытка добиться третьей «победы» подряд была предотвращена. Третья попытка оказалась предпоследним возвратом после правки, а не последним. Завершающий возврат после правки был произведен одним из моих коллег, не только внесшим финальную правку в Windows 2000, но также начавшим новую династию, произведя последний возврат после правки для Windows XP.

Один из ироничных моментов игры в «не слабо внести правку» заключается в том, что выигрывают ее зачастую собранные люди (от которых этого меньше всего ожидаешь). Учтите, это не потому, что их код плох. Будучи хорошо подготовленными, они находятся в гораздо лучшем положении для выполнения завершающей проверки кода, даже если он находится не в том компоненте, за который они обычно несут ответственность.

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

• Разработчик выполняет возврат после правки в своем подпроекте.
• Сборочное средство подпроекта вмешивает изменение за ночь и предоставляет сборку утром.
• Группа тестеров подпроекта корпит над кодом неделю или больше, прежде чем одобрить выпуск возврат правки в ствол проекта.

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

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

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

На этом этапе происходит небольшая игра в «сирано». Группа представляет изменение хорошо подготовленному разработчику и разработчик создает образы диска, проверяет ограничения сборки и затем указывает группе тестеров сервер своего частного выпуска. Если тестеры находят проблему, группа разработчиков придумывает новое исправление и передает его хорошо подготовленному разработчику.

Другими словами, хорошо подготовленный разработчик выступает как виртуальное средство сборки для группы. Когда все довольны, он производит возврат после правки. Именно поэтому хорошо подготовленные разработчики выигрывают игру в «не слабо внести правку». Не потому, что на них еще висит исправление какой-то проблемы, – потому, что они готовы помочь тем, на ком оно висит.

**Рэймонд Чен (Raymond Chen)**на своем веб-узле The Old New Thing (Хорошо забытое старое) и в одноименной книге (издательство Addison-Wesley, 2007 г.) рассказывает об истории развития Windows, программирования в среде Win32 и взрывающихся кофейных автоматах.