Идеальный код — это иллюзия

Даниэл Ирвайн рассказал о главной иллюзии любого разработчика.

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

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

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

Не зацикливайтесь на догмах

Единственное, что нужно от кода – чтобы он работал. Простой способ проверить это – полностью покрыть кодовую базу тестами и удостовериться, что они выполняются. За пределами этого любые измерения качества будут субъективными.

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

Создавайте короткие стандарты кодирования или вообще не создавайте

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

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

А из искры записанных правил иногда может разгореться пламя.

В одной из команд, в которой я работал, было правило: «Ни одна функция не должна превышать 7 строчек кода». Оглядываясь назад можно сказать, что нашей команде было бы лучше без этого правила. Хотя я все еще согласен с этим правилом, но оно вызывало множество проблем и дискуссий. Одно это правило вызывало множество комментариев к пул реквестам, за которыми следовали изменения. Людям постоянно надо было напоминать о нем. Некоторые никогда в него не верили. В общем, мы потратили много времени и сил на то, чтобы следовать ему.

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

Хотя я до сих пор пишу короткие методы – обычно гораздо меньше, чем 7 строк – я не потрудился записать его.

Пусть база кода будет сама себе стандартом, а не следует записанным правилам.

Не позволяйте пул реквестам задерживать вас

Часто я объединяю пул реквесты, даже если они очевидно улучшают код. Я делаю это по двум причинам. Во-первых, ожидание исправления может задержать других членов команды. Вторая причина более тонка. Очень важно, чтобы база кода оставалась податливой – это означает, что она должна быть готовой и ожидающей изменений. Культура «идеального пул реквеста» препятствует этому. Она показывает, что код в главной ветке является «золотым» стандартом и не должен изменяться. Если мы вместо этого позволим в главной ветке существовать неидеальному коду, мы поощрим внесение больших изменений. Команда учиться всегда задавать вопрос: «Код, на который я смотрю, достаточно чистый?».

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

Так какой лучший подход к рассмотрению пул реквестов?

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

Я меньше всего комментирую вопросы стиля, вроде нехватки пробелов или плохо прописанного списка параметров. Если код податлив, кто-нибудь почистит его когда-нибудь в будущем. А пока эти стилистические ошибки никого не ранят.

Отпустите великое видение

Для всего, что больше нескольких десятков строк кода, совершенство в глазах смотрящего. Если вы ожидаете, что все начнут решать задачи точно так же, как и вы, то вы ошибаетесь. Если у вас есть большое видение того, как должна выглядеть ваша база кода, то вы будете разочарованы.

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

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

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

Григорий Петров: Стандарт оформления кода: и не стандарт, и не оформления, и не только кода