Сохраняйте небольшие изменения

Будучи младшим инженером, я стал плодотворно вносить большие и радикальные изменения. Я видел проблему и сразу брался за нее.

Обычно это означало, что я отправлял гигантские обзоры кода. Я коснулся всего, от пользовательского интерфейса до базы данных - одним изменением.

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

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

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

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

Теперь это моя суперсила.

Преимущества внесения дополнительных изменений

Постепенные изменения дают много преимуществ.

  • Меньше конфликтов слияния. Чем больше файлов вы изменяете, тем выше вероятность того, что кто-то другой одновременно изменяет подмножество этих файлов. Избегайте конфликтов слияния, внося небольшие изменения и быстро регистрируя их.
  • Более быстрая проверка кода. Людям легче просмотреть пять файлов, чем 50+. Легче просматривать изменения, которые можно быстро объяснить, в отличие от изменений, требующих 10-минутного личного разговора, прежде чем кто-либо даже начнет изучать код. Инженеры могут быть ленивыми - если они увидят большой обзор кода, они будут надеяться, что вместо этого работу сделает кто-то другой. Вам может потребоваться больше времени, чтобы найти кого-нибудь, кто рассмотрит ваши большие изменения кода.
  • Раннее исправление курса. Эксперты, проверяющие код, могут не согласиться с выбранным вами направлением. Они могут попросить вас все переделать. В этом нет ничего страшного, если вы потратили всего пару часов на изменение. Гораздо больнее, когда вы потратили два дня или больше на совершенствование сквозного сценария.
  • Более быстрое тестирование. Если вы затронули все, от пользовательского интерфейса до базы данных, возможно, вам придется повторно протестировать весь продукт. Если вы вносите небольшие изменения, вам может понадобиться протестировать только те части, которые вы изменяете. Это преимущество становится особенно заметным, если вам нужно учесть большое количество отзывов о проверке кода или если вам нужно объединить много кода перед проверкой. Повторное тестирование всего может занять много времени, особенно если некоторые тесты выполняются вручную.
  • Меньше ошибок. Небольшие изменения означают, что вам не нужно держать в голове весь мир одновременно. Вы можете сосредоточиться на небольшом уголке, который вы улучшаете, и убедиться, что у вас все получается хорошо. (Я видел инженера, который был настолько ошеломлен своими крупными изменениями, что он взял в привычку просто надеяться на лучшее, проверять и исправлять ошибки постфактум. Не будьте таким человеком. Даже если ни один клиент никогда не замечает , вы будете чертовски раздражать своих коллег-инженеров. Они перестанут доверять вашему коду.)
  • Упрощение устранения неполадок. Если вы все-таки что-то сломаете, будет легче найти основную причину, если изменение будет незначительным.
  • Поэтапное развертывание. Если вам интересно, как вы сможете развернуть что-то без простоев, скорее всего, вам помогут небольшие, инкрементные изменения (но не все).
  • Отменить изменение проще. Возникают ошибки. Чем меньше ваша сдача, тем легче ее отменить. Если вы отметили гигантское изменение, а несколько человек впоследствии изменили одни и те же файлы, вы можете оказаться в болезненной ситуации, когда вам придется выбирать между возвратом большого количества изменений или быстрым возвратом исправить (что может не сработать). Если ваша производственная среда горит, для всех будет гораздо меньше стресса, если вы можете просто отменить исходное плохое изменение.
  • Более простой откат развертывания. Если при однократном развертывании обновляется веб-служба и сразу же появляется функция пользовательского интерфейса, зависящая от обновления службы, вы не сможете отменить изменение службы без сначала удалите функцию пользовательского интерфейса. В зависимости от того, как работают ваши развертывания, возврат обоих изменений с нулевым временем простоя может быть нетривиальным. Было бы лучше зарегистрировать и развернуть изменение веб-службы самостоятельно.
  • Меньший риск. Это действительно следствие всего вышеперечисленного.

Оплата вперед

Отзывы о проверке кода, которые я получил от старшего инженера в тот день, оказались лучшими отзывами инженеров, которые я получал за всю мою карьеру.

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

Он будет лучшим инженером.