The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Я решил написать этот блог-пост после рассмотрения этого запроса на включение изменений. Что там произошло? Автор PR не смог понять “правильный” способ его реализации, а проверяющий кода ждал и ждал. В конечном итоге, проверяющий обратился ко мне, так как я был архитектором, и пожаловался, что это занимает слишком много времени, и он не смог заработать деньги за выполненный им обзор. Затем автор изменений объяснил, что он не смог закончить из-за препятствий и несоответствий дизайна; он также не смог заработать деньги, которые заслуживал за исправление проблемы. Что я сказал? Я сказал: Забудьте о качестве, просто закончите это любым возможным способом.
Шутил ли я? Вовсе нет.
Я искренне считаю, что программисты не должны заботиться о качестве. Они должны заботиться только о скорости - закрывать задачи как можно скорее, что означает зарабатывать деньги.
Не разрушит ли такое отношение проект и не превратит ли кодовую базу в беспорядок?
Если проекту не важно его качество.
Должен существовать постоянный конфликт между проектом и его программистами: 1) проект должен быть настроен отвергать все, что снижает качество его артефактов, и 2) программисты должны быть заинтересованы внесением изменений в эти артефакты. Проект заботится о качестве, программисты заботятся о быстрой доставке модификаций.
Что я имею в виду, говоря о том, что проект отвергает низкое качество? Вот список профилактических мер, которые он может предпринять, чтобы невозможно было подвергнуть качество опасности:
“Read-only master branch;” - “Ветка master только для чтения;”
Высокая планка покрытия тестами;
Обязательный статический анализ;
Многоэтапные код-ревью.
Что я имею в виду, говоря о том, что программисты должны быть заинтересованы в внесении изменений? Они должны быть мотивированы для завершения задач. Не только участвовать в проекте, но и доставлять результат. Вот что они могут сделать, чтобы закрыть задачи быстрее:
Сделайте изменения меньшими;
“Не изучайте код, просто изменяйте его;”
Не чувствуйте себя ответственным за весь код, просто сосредоточьтесь на соответствующих модулях/классах;
Не бойтесь ломать вещи.
Если мы поставим эти два интереса в противоречие, мы получим качественный продукт, который растет очень быстро. Проект будет поддерживать качество, программисты будут двигать код вперед, делая изменения быстро и часто.
К сожалению, большинство проектов имеют совсем другую философию. Они делегируют контроль качества программистам, надеясь, что они “не сделают зло”. Это приводит к разочарованию, тревоге, постоянному страху совершить ошибку, длительным задержкам, обвинениям и унижению. И проект, и программисты терпят поражение.
Программисты не должны быть ответственными за качество! Им не должно быть важно, что они могут или будут нарушать. Им не должно быть важно, насколько хорошим является написанный ими код. Они не должны “чувствовать себя ответственными” за общий результат. Вместо этого они должны сконцентрироваться на том, чтобы зарабатывать деньги для своих семей, путем написания наибольшего количества кода и закрытия большего числа задач.
Не потому, что они невежественны и эгоистичны, а потому что это правильный баланс ответственности. Так проект получит наибольшую отдачу от своих разработчиков, освободив их умы от ненужных и неэффективных забот о качестве и позволив им сосредоточиться на том, что они делают лучше всего - на написании кода.
Конечно, не каждый проект сможет сконфигурировать себя наиболее эффективным образом. Большинство проектов даже не знают, как это сделать. В таких проектах, если вы, как разработчик, нажмете на педаль скорости, вы скорее всего испортите их кодовую базу за несколько дней. Поэтому вышеуказанные рекомендации применимы только к тем, кто действительно знает, что делает.
Мы знаем, что мы делаем в наших проектах. Мы не позволяем разработчикам трогать любые части нашего кода, если “стена качества” достаточно высока и прочна. Насколько высока эта стена в ваших проектах? Можете ли вы сказать, что независимо от того, насколько плохой является некоторый код и насколько хитро его автор его вводит, он будет отклонен?
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 16:36
