Как делать их хорошо

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

Многие люди не знают о Rolls Royce, что им требуется почти шесть месяцев, чтобы построить одну машину от начала до конца. Ага, вы не ослышались: всего одна модель. Если сравнивать с такими компаниями, как Ford или Toyota, вряд ли они занимают 17–18 часов. Не то чтобы ребята из Rolls Royce тормозили или собирали машину вручную. Поверьте мне, в их распоряжении лучшие инженеры, самые высокотехнологичные роботы и огромные конвейерные ленты.

Что делает процесс долгим, так это постоянные проверки, строгие проверки и внимание к деталям в их автомобилях. У них есть много процессов и правил, связанных с производством автомобилей, некоторые автоматизированные, некоторые ручные. Они не хотят и не могут ставить под угрозу качество своих автомобилей, потому что хотят, чтобы это было известно. Вы не можете просто присоединиться к Rolls Royce и начать производство автомобилей. Вы обучены тому, как правильно строить автомобили.

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

Пункты, о которых я упомянул выше, очень распространены, и почти все о них знают. Но если вы примете во внимание мой пример Rolls Royce, даже Ford знает, как производить автомобили, но то, что отличает Rolls Royce от Ford, - это процесс проверки, постоянная проверка и гарантия качества. В контексте разработки программного обеспечения они называются проверкой дизайна и кода.

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

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

Проверка кода - это способ улучшить ваш код, а также повысить качество работы вашей команды. Это процесс обратной связи и предложений по улучшению кода члена команды (PR) до того, как он будет объединен и развернут в производственной среде.

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

Великая цель

Есть известная цитата Джона Вудса:

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

Чтобы понять смысл этой цитаты, люди должны перестать воспринимать программирование как должное, или делать это ради карьеры или ради заработка.

Представьте, что вы идете в пятизвездочный ресторан и после часа ожидания получаете полусырые грибные равиоли, потому что шеф-повар не интересовался готовкой. Думаю, большинство из нас пошло бы на психоаналитика Энтони Хопкинса («Молчание ягнят») у шеф-повара. Может быть, я преувеличиваю, но дело не в этом. Я пытаюсь подчеркнуть образ мышления шеф-повара.

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

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

Проверка кода не иерархическая. Быть самым высокопоставленным лицом в команде не означает, что ваш код не нуждается в проверке. Неважно, стажер автор или технический директор. Неважно, имеет ли автор три месяца или 30 лет опыта. Кодирование - деликатная задача, и вещи могут легко ускользнуть, поэтому всегда полезно иметь еще одну пару глаз. Даже если в редком случае код безупречен, обзор дает возможность для наставничества и сотрудничества и минимально разнообразит понимание кода в базе кода.

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

Лучшее качество продукции

Тики-така - не все слышали эти слова, но в мире футбола это, пожалуй, одна из величайших тактических революций, которая помогла Барселоне и Испании доминировать в мировом футболе за последние два десятилетия. Тики-така продемонстрировал мастерство совместной командной игры на высочайшем уровне футбола. Барселона одержала все эти победы не только потому, что у них были игроки мирового класса, которые умели играть в хороший футбол в команде, такие как Месси и Вилла. Они выиграли, потому что все играли вместе и улучшали игру друг друга.

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

Меньше ошибок в коде

Согласно исследованию, проведенному Stripe в партнерстве с Harris Poll:

«В среднем разработчики тратят более 17 часов в неделю на решение таких проблем, как отладка и рефакторинг, и около четверти этого времени тратится на исправление плохого кода. Это почти 300 миллиардов долларов потери производительности каждый год ».

Хотя проверки кода на самом деле не проводятся для устранения ошибок (да ладно, у нас есть тесты, руководства по стилю и CI для этого), иногда они помогают - например, рецензент иногда может в конечном итоге идентифицировать некоторую базовую импортированную функцию, которую они написали, которая может действовать в производстве.

Более того, партнерские проверки оказывают психологическое воздействие и на членов команды: исследование Cisco Systems, проведенное компанией SmartBear, показало, что выборочная проверка от 20% до 33% кода привела к снижению плотности дефектов с минимальными временными затратами для компаний, которые практиковали экспертные проверки кода, потому что это не позволяли людям распространять плохой код своим коллегам.

Улучшение навыков межличностного общения

Все мы знаем, что кодирование - это технический навык (или сложный навык). Это обучаемая и измеримая способность. Мы можем узнать его, прочитав чужой код или просто скопировав его из Интернета (большинство из нас это делают; довольно легко, правда?). Теперь самое сложное - убедить кого-то, что код, который они написали (или скопировал), не соответствует требованиям или содержит ошибки. Трудно убедить кого-то изменить свой код в лучшую сторону, и это очень часто случается во время проверки кода.

Вот тогда в игру вступают мягкие навыки. Лидерство, открытость к критике, убеждение, адаптируемость и эффективные коммуникативные навыки гораздо важнее и сложнее в освоении для инженеров-программистов, чем кодирование, и это то, что отличает программиста от программиста! Выполнение обзоров кода часто оттачивает наши межличностные навыки, когда мы пытаемся общаться и заставлять наших коллег понять намерения, стоящие за нашими отзывами.

Обнаружение случайных ошибок / слепых зон / опечаток

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

Беспрепятственный прием новых членов команды / стажеров

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

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

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

Право собственности на код разделено между командой, а не является обязанностью одного человека

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

Во время проверки рецензент может объяснить изменение с разумным уровнем детализации другим разработчикам. Это гарантирует, что детали кодовой базы известны более чем одному человеку, что приводит к позитивному взаимодействию и укреплению социальных связей между членами команды, что помогает нарушить образ мышления «мой код, моя собственность» (что очень токсично!) .

Что проверять отзывы

Стандарты кодирования

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

Сложность кода

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

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

Исходя из опыта функционального программирования, я смог понять принцип DRY (не повторяйтесь) и насколько важно минимизировать объем кода. Рецензенты должны попытаться сообщить авторам, как поддерживать и реализовывать минимализм и абстракцию кода. В конце концов, кодирование не должно быть борьбой или ощущением битвы; скорее, он должен быть как можно более беспечным.

Ремонтопригодность кода

Одна из самых заметных и недооцененных способностей хорошей команды инженеров - это то, насколько хорошо они поддерживают свой код. Рецензенты должны задавать такие вопросы, как «добавил ли автор тесты к написанному им коду?» "Нарушает ли это изменение обратную совместимость?" и «можно ли обновить кодовую базу для будущих сценариев использования?» самого себя, а также автора.

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

Производительность кода

Вернемся к основам, ладно? Рецензенты могут быстро проверить, используются ли в коде правильные структуры данных (потому что никто не любит задержки), обновляются ли версии подключаемых модулей со временем или соблюдается ли соблюдение безопасности в коде или нет.

Читаемость кода

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

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

Исходя из моего личного опыта, удобочитаемость кода - одна из самых простых вещей, потому что это буквально перевод мыслей при написании кода. Тем не менее, много времени мы склонны игнорировать это в основном из-за нехватки времени. Документация на уровне кода или строки документации, комментарии, сообщения фиксации, readme, wiki - все это способствует этому. Рецензенты и авторы должны убедиться, что эта документация также обновляется с изменениями кода. (Вспомните случай, когда вы увидели устаревший файл readme, сообщение о неверном коммите, отсутствующий комментарий к коду или неполную вики, и как вы на это отреагировали).

Как делать обзоры

Мышление

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

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

Следует иметь в виду следующее:

Доброжелательность

Цените, цените, цените! Осознайте силу доброты. В конце концов, мы все поднимаемся, поднимая других, верно? Проверка кода - это не средство унижения или критики кого-либо. Попробуйте начать с чего-то положительного, оценивая авторов, находя то, что они сделали правильно.

Избегайте притяжательных местоимений, особенно в сочетании с такими оценками, как «В вашем коде есть ошибка», «Мне не нравятся ваши соглашения об именах» и т. Д. Избегайте абсолютной проницательности вроде «Мы здесь не так кодим» или « Вы делаете это неправильно ». Поэтому вместо того, чтобы спрашивать: «Вы вообще проводили тесты?» вы можете сказать: «Я вижу, что тесты не проходят. Пожалуйста, исправьте свой код, чтобы они прошли ».

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

1 PR = 1 проблема

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

Ты не твой код

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

Проведение проверки кода лично

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

Не просматривайте слишком много кода за один раз

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

Используйте контрольный список проверки кода

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

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

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

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

Я согласен с тем, что проверка кода может быть сложной задачей. Может быть слишком много вещей, которые нужно проверить за ограниченное время, но многое из того, что я упомянул выше, можно легко автоматизировать. Codegrip, PMD, FindBugs, Checkstyle - одни из самых известных инструментов проверки кода. Существует множество инструментов покрытия кода (например, Cobertura, Coverage.py, Sbt-scoverage и т. Д.), Инструментов проверки стиля (таких как Scala-Style-Guide и Google Java Style Guide) или инструментов сборки (таких как Jenkins CI / CD и GitLab. CI / CD). Всего в поиске Google есть сотни других инструментов, которые могут легко автоматизировать большую часть процесса проверки кода и сэкономить ваше драгоценное время.

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

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

Большое спасибо за уделенное время. Ваше здоровье!