The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Хорошо, заголовок не совсем точен. Я пропустил слово “может”. Распределенная команда может создавать код намного более высокого качества, чем команда, находящаяся в одном месте, и сейчас я объясню почему. Конечно, не каждая распределенная команда может это сделать. Большинство из них даже не может создать работающий код, не говоря уже о качественном коде. Но если команда, распределенная команда, управляется в соответствии с принципами, которые я сейчас объясню, качество будет намного выше, чем то, что эта же команда может достичь, находясь в одном месте. Я покажу вам, что работа в удаленном режиме, если это делается правильно, гарантирует более высокое качество кода. Удивлены?
В основе успеха лежат четыре простых ингредиента… знаете что, на самом деле есть один основной ингредиент, и его название - контроль. Если мы хотим, чтобы качество было на определенном уровне, мы должны обеспечить его. Мы не можем просто заявить об этом; мы должны сделать его высоким.
Как команды разработчиков создают код высокого качества? О, есть множество проверенных методов. Во-первых, вам нужен очень современный офис, где программисты сидят на мягких стульях, играют в настольный теннис, пьют смузи и наносят диаграммы на стены. Во-вторых, вы должны купить для них много книг. Книги должны быть везде в офисе, и они должны быть о всем, начиная от Python и Haskell, заканчивая Docker, Agile и lean-стартапами. Чем больше книг, тем выше качество кода, который они пишут. И в-третьих, вы должны хорошо платить им. Чем дороже разработчик, тем выше качество кода, который он или она пишет.
Я уверен, что вы понимаете, что я шучу. Ни один из этих “проверенных методов” не гарантирует качество или мотивирует серьезных программистов. Качество может быть достигнуто только при контроле и обеспечении. И это также то, что лучше всего мотивирует программистов - факт, что качество настолько важно для управления, что они находят механизмы контроля и обеспечения, и вкладывают в них. Настольный теннис и книги о lean-стартапах даже близко не подходят к этим механизмам.
Итак, давайте обсудим те четыре ингредиента обеспечения качества, которые мы практикуем в наших проектах:
Чаты запрещены. Любое изменение в нашей кодовой базе, даже самое незначительное, должно быть представлено в виде запроса на включение изменений (pull request). Обязательно проводится кодовый ревью в рамках запроса на включение изменений. Мы строго запрещаем неформальное общение между программистами, включая чаты, телефонные звонки, электронную почту или личные встречи. Это означает, что вероятность компромиссов в качестве из-за дружеских отношений, неформальных соглашений и уступок очень низкая.
Build Is Fragile. Мы считаем, что чем выше планка качества, тем сложнее изменять любой участок кода без поломки сборки. Мы внедрили множество проверок качества прямо в сборку, чтобы усложнить жизнь программистам. Хотя это не наша цель, но так случается. Код должен пройти все проверки статического анализа, достичь порога покрытия тестами, порога мутационного покрытия и многих других. Это означает, что плохой код никогда не попадет в репозиторий.
Микро-оплаты за выполненные задания. Мы платим только за закрытые тикеты, и они каждый очень маленькие (до двух часов). Мы не платим за время, проведенное в офисе или перед компьютером. Мы платим только, когда тикеты закрыты - без закрытия, без оплаты. Это означает, что программисты мотивированы только на их закрытие, ничего более.
Таким образом, как видите, здесь сознательно создан конфликт. С одной стороны, программистам нужно закрывать заявки и предоставлять работающий код. С другой стороны, это довольно сложно, потому что уровень качества высокий, нет места для компромиссов и нет технической возможности обойти проблему. Хорошие программисты выживают в этом конфликте и умудряются выполнить работу и получить оплату. Хорошо оплачиваемую.
А теперь перейдем к основной теме этого блога - вы считаете возможным создать все это в команде, находящейся в одном месте? Я так не думаю. Прежде всего, вы не сможете запретить неформальное общение. Независимо от того, сколько раз вы просите разработчиков общаться посредством заявок, они будут решать большую часть своих технических вопросов лицом к лицу. Это неизбежно.
Во-вторых, вы не сможете оплачивать только результаты, потому что программисты будут жаловаться, что они много общаются в офисе и это тоже должно быть оплачено. На самом деле, они будут тратить два-три часа в день на написание кода, а остальное время будет уходить на кофе-перерывы, разговоры о Трампе и просмотр Facebook. Опять же, это неизбежно.
И, наконец, люди - это люди. Никто не хочет достигать высокого уровня качества несколько раз в день. Они будут жаловаться, и в конечном итоге вы дадите им прямой доступ к основной ветке. Сначала вы дадите его архитектору, затем нескольким старшим разработчикам, затем нескольким хорошим друзьям, которым вы абсолютно доверяете. Затем всем, на всякий случай. Это неизбежно.
В заключение, я считаю, что команды, находящиеся в одном месте, просто не предназначены для качественного программирования. Для развлечения - да. Для творчества - может быть. Для траты денег инвесторов - абсолютно. Для качества - не совсем.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-17 at 16:13
