В книге «97 вещей, которые должен знать каждый программист» под номером 8 содержится «Правило бойскаута» («The Boy Scout Rule»), описанное дядей Бобом.

Перевод фрагмента:

У бойскаутов есть правило: «Всегда оставляй лагерь чище, чем был до тебя». Если ты видишь мусор на земле, ты убираешь его, независимо от того, кто его оставил. Первоначальное правило сформулировал Роберт Баден-Пауэлл, отец скаутского движения: «Постарайся оставить после себя мир лучше, чем ты его нашёл».

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

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

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

  

Все могут использовать «правило бойскаута»

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

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

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

Главное — это неравнодушие к замеченным проблемам!

Тоже самое можно делать не только с кодом и интерфейсом, но и с аналитикой и процессами команды.

Автомеханик — профессионал

Представьте, что вы сдали своё авто в ремонт с небольшой неисправностью. Сами вы «под капотом» не разбираетесь. Помимо известной неисправности в итоге выяснится, что ещё и охлаждающая жидкость подтекает. Что вы предпочтёте?

• Чтобы автомеханик: 1) смотрел узко, только на проблему, с которой вы обратились и не тратил ваше время, а о неисправности вы узнаете где-нибудь в дороге и сами разберётесь; 2) по-пути посмотрел смежные узлы на наличие проблем и обнаружил течь? Даже, если вы не заказывали диагностику всё равно проводил беглый осмотр?
• Когда автомеханик заметил течь: 1) ничего не делал; 2) предложил заменить прокладку и подтянуть соединения? А также оценил риски, если не чинить сейчас и сообщил вам?

Хороший профессионал не нуждается в разрешении сделать то, что должно быть сделано — что входит в его понимание «хорошей работы». Хороший автомеханик не будет игнорировать проблему или даже идти на поводу у клиента, если ему дорога́ репутация и жизнь клиента.

Простое правило — большой культурный сдвиг

Казалось бы, такая мелочь: разреши себе оглядеться и улучшить, что тебе не нравится. Но возникает несколько культурных преград:

• Не хватает намётанности глаза и не толерантности к «плохому», чтобы его постоянно находить и не воспринимать как должное. Не всем даётся это упражнение, особенно без регулярных тренировок. А для тренировок нужна подходящая среда, где ты калибруешься о других.
• Необходимость выделения времени и переноса сроков. Мелкие улучшения и приборка должны делаться сразу, без обсуждений — это часть работы и здорового процесса. Большие исправления должны выноситься на обсуждение, включая риски, если оставить всё как есть.
• Нет уверенности, что твой вариант лучше, что ты действительно что-то улучшаешь. Особенно неуверенность наблюдается у новичков. Культура поощрения «стремления вносить улучшения» в долгосроке приведёт к тому, что за несколько итераций оптимум будет найден, даже, если разово ситуация ухудшается. В противном случае улучшения не случаются вовсе. А в особо ответственные места новичков обычно не пускают, как минимум без наставника.
• Риск возникновения конфликтов с предыдущими авторами. Что важнее в команде: показать какой-ты крутой и всё заранее продумал, или культивировать среду непрерывных улучшений?

«Работает — не трожь!» — вредное правило

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

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