Мы говорили о недавнем внедрении в работу особого типа инженерных практик, а именно о Code Review. Думаю, не лишним будет вкратце напомнить, что под Code review мы понимаем систематическую проверку кода с целью обнаружения ошибок, недочетов, расхождений, не замеченных на начальной стадии разработки. Инспекцию кода проводят периодически так называемые ревьюеры, при этом ими контролируется не только сам код (его соответствие стандартам, корректность и прочее), но и общая логика реализации задачи.

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

В подтверждении своих слов ниже приведу описание положительных тенденций, которые мы пронаблюдали после введения Code Review.

1. Обнаружение большего числа дефектов до передачи в QA стало возможным в силу нескольких причин:

  • Быстрая работа над ошибками. Если ревьюер знает разработчика, имеет опыт работы с его кодом, то без особых усилий может “отловить” характерные ошибки своего коллеги;
  • Опыт. Ревьюер, будучи более подкованным и опытным программистом, вполне возможно, уже сталкивался с решением подобной задачи и знает потенциально слабые места программного кода;
  • Взгляд со стороны. Каждый может пропустить ошибку, а повторный просмотр снижает вероятность ее наличия.
  • Дополнительная мотивация. Если разработчик знает, что код будет просматриваться, то сам вполне заинтересован в том, чтобы допускать как можно меньше ошибок.

2. Улучшение качества кода за счет обсуждения реализации между разработчиками:

  • Логика и подходы к решению задачи, алгоритмы, имена сущностей и другие детали работы – все можно обсудить и найти наиболее подходящий вариант, отвечающий непосредственно данной проблеме;
  • Разработчик видит не только свой код, но и код коллеги, может сравнить их и при необходимости использовать в своей работе.

3. Упрощение поддержки кода стало возможным, благодаря совместной работе над ним.

4. Code Review как инструмент обучения сотрудника

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

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

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

Из первых рук: мнения разработчиков о Code Review

“Я участвовал в проекте, предусматривавшем перекрестный ревьюинг кода: два разработчика, соответсвенно, просмотр кода друг друга. Скажу честно: удобно, нужно, нетрудозатратно. Если в цифрах, то поначалу ревьюинг обнаруживал примерно 10-15 ошибок, а затем 0-5 ошибки на один и тот же объем кода. А по времени в день весь процесс занимал не более 20 минут, поэтому, как мне кажется, смысл в такой работе есть точно.”

Алексей Романенко, PHP-разработчик

Константин Медведев, Project Manager

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

Николай Джулай, Project Manager

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

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

На что смотреть во время инспекции

Архитектура/Дизайн

  • Принцип «одной ответственности». Идея в том, что у каждого класса должно быть только одно назначение. На самом деле реализовать это труднее, чем кажется. Я обычно применяю это правило и к методам. Если возникает нужда в союзе «и» при описании того, что делает метод, то это знак, что стоит разделить его на несколько более простых.
  • Принцип «Открыт/Закрыт». Если язык объектно-ориентированный, то открыты ли ваши объекты для расширения, но закрыты для модификации? Что произойдет, если нам нужно будет добавить еще один экземпляр класса x ?
  • Дупликация кода. Я придерживаюсь правила «трех раз» . Если код повторяется один раз, то я закрою на это глаза, хоть это и выглядит некрасиво. Но если один и тот же кусок используется три раза или больше, то необходимо вынести его в отдельный метод.
  • Слепой тест. Если расфокусировать зрение, то выглядит ли форма кода, на который вы смотрите, идентичной другим кускам кода? Если нет, то это может быть сигналом к тому, что код нуждается в рефакторинге.
  • При изменении кода всегда пытайтесь его улучшить. Обычно, если я исправляю какую-то часть кода, которая работает неправильно или выглядит некрасиво, у меня всегда возникает искушение просто исправить несколько строчек и на этом закончить. Я рекомендую не останавливаться на этом и сделать код лучше, чем он был.
  • Потенциальные баги. Просматривайте код на наличие ошибок-на-единицу, нарушений условий циклов и т.д.
  • Обработка ошибок. Достаточно ли хороша обработка ошибок? Введены ли кастомные исключения? Если да, то полезны ли они?
  • Эффективность. Если используется какой-либо алгоритм, эффективна ли его реализация? Например, пробег по всем ключам словаря - не лучший способ найти нужное значение.

Стиль

  • Имена методов. Давать имена различным вещам - одна из самых сложных задач в программировании. Если метод называется get_message_queue_name() , но делает что-то кроме этого, например, убирает HTML из входных данных, тогда это имя не подходит ему.
  • Имена переменных. foo и bar - не самые лучшие имена для структур данных. e также не настолько красноречиво, как exception . Будьте как можно лаконичнее. Говорящие имена переменных облегчат чтение кода в будущем.
  • Длина функций. Я придерживаюсь правила, говорящего, что функция не должна быть длиннее 20 строк. Если я вижу метод больше 50 строк, я пытаюсь разбить его на два.
  • Длина классов. Классы должны быть меньше 300 строк, а в идеале - меньше 100. Скорее всего, если в вашем коде есть длинные классы, то их можно разбить на несколько, что облегчит понимание их предназначения.
  • Длина файла. Для Python 1000 строк в одном файле - предел. Если их становится больше, то, возможно, стоит разбить файл на несколько, с более специфичным предназначением. Чем больше файл, тем меньше читабельность кода в нем.
  • Документация. Сложные методы лучше задокументировать так, чтобы было понятно, за что отвечает каждый аргумент. Разве это не очевидно?
  • Закомментированный код. Стоит удалить закомментированные строки кода, чтобы не было ничего лишнего.
  • Количество аргументов в методе. Посмотрите, сколько аргументов передается в ваш метод. Больше трех? Это знак того, что они могут быть сгруппированы по-другому.
  • Читабельность. Легко ли разобраться в вашем коде? Часто ли вы делаете паузы во время чтения, чтобы разобраться в нем?

Тестирование

  • Полнота тестов. Мне нравится, когда нововведения тестируются. Но насколько эти тесты продуманы? Могут ли они заставить ваш код упасть? Легко ли они читаются? Насколько они хрупки? Насколько они большие? Медленные ли они?
  • Тестирование на правильном уровне. Когда я рассматриваю тесты, я должен убедиться в том, что они проводят тестирование на правильном уровне. Иными словами, тестируется ли тот уровень приложения, который нужно тестировать для проверки функциональности? Гарри Бернардт рекомендует такое соотношение - 95% юнит-тестов и 5% интеграционных тестов. Особенно это относится к проектам, использующим Django.
  • Количество объектов-имитаций. Имитационные объекты хороши, но не стоит пихать их везде. Если в тесте их более трех штук, нужно его переписать. Либо тест, либо сама функция, для которой он предназначен, охватывают слишком большую часть кода. В обоих случаях это стоит обсудить.
  • Соответствование требованиям. Обычно в конце инспектирования я смотрю на задачу или баг, для которого был предназначен тест. Если он не соответствует каким-то критериям, то лучше провести тестирование заново.

Сначала проинспектируйте свой код сами

Перед совершением коммита просмотрите свой код на следующие вещи:

  • Оставили ли вы какие-нибудь комментарии или TODO?
  • Говорят ли сами за себя имена переменных?
  • …что угодно из того, что я перечислил выше?

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

Как проводить инспектирование кода

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

  • Задавайте вопросы. Задавайте вопросы, которые подтолкнут разработчиков к обсуждению. Например, как работает этот метод? Если изменится какое-то требование, то что нужно будет поменять в коде? Как сделать код более поддерживаемым?
  • Делайте комплименты и поощрения. Одна из самых важных вещей в тестировании — награждение разработчиков за рост и приложение усилий. Немногое может сравниться с похвалой от тимлида. Я стараюсь сделать настолько много положительных комментариев, насколько это вообще возможно.
  • Обсуждайте детали наедине. Большие архитектурные изменения лучше обсуждать всей командой, в то время как про мелкие детали лучше говорить наедине с разработчиком, который ответственен за них, дабы не вовлекать лишних людей.
  • Объясняйте причины. Всегда лучше рассказать или спросить, почему предложенные изменения необходимы. Порой может возникнуть чувство, что они несущественны, до тех пор, пока вы не объясните повод.
  • Дело в коде. Обсуждайте сам код, а не разработчиков, которые его писали. Это создаcт непринужденную атмосферу, тем более, программисты ни при чем - инспектирование призвано улучшить качество кода.
  • Указывайте на важность изменений. Обычно я предлагаю множество изменений, не все из которых обязательны. Если вы считаете, что ваше предложение важно, то стоит сказать об этом, тогда на него обратят внимание и быстрее начнут двигаться в нужном направлении, что создаст видимость результата.

Не забывайте о своих обязанностях

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

Купить "Мольба " можно за 250 руб.

О фильмах "Мольба", "Покаяние"
Тенгиз Абуладзе знает скверную механику беззаконной власти, ее закулисье, все эти внезапные разносы подчиненным за правонарушения, все эти ухмылки, с которыми их, черт с ними, прощают (сцена грозы над Доксопуло, который в нерве подслушивает, удастся ли благоволящей ему секретарше утишить гнев Вар-лама), — но он знает про беззаконие и нечто иное и большее.

Беззаконие (так движется мысль в "Покаянии") не только посягает на чьи-то жизни, ломает их и отнимает их; беззаконие есть посягательство на жизнь в высшем смысле этого слова.

Беззаконие проедает бытие. Если в суде оказываются люди в мантиях и в париках, если на всадниках, спешившихся во дворе, где стоит грузовик с арестантами, оказываются латы и кольчуги, если в разоренном храме звучит по радио речь Эйнштейна и по своим делам шмыгает какой-то выходец из Босха в наряде XV века и с тяжелым крысьим хвостом, — это не каприз режиссера и не карнавал персонажей, а знак того, как беззаконие разъело время. На улицах города, взятого Варламом и им терзаемого, вполне могут скакать всадники, которые вырезали Грузию при монголах или при турках; злу открылись щели в проеденном времени; старое зло в щели лезет, всплывает со дна времен, хватает живых.

Фильм "Покаяние" сделан в глубоком сознании того, что преступление смущает мир и заражает его смутой. [...]

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

Варлам также знает, что он делает, когда преследует чету Баратели: в союзе Сандро и Нино есть то, на чем мир стоит, держится; в нем наполненность должным. Это люди чести, люди семьи, люди товарищества, люди отечества, на земле которого стоит старый храм. [...]

В систему творческих импульсов Тенгиза Абуладзе входят и живая образность дома, и корневая образность народной памяти, и грозная и гротескная образность "потрясенного естества". Свобода, с которой эти импульсы соединяются, удивительна. Какой-то слой памяти (нашей, зрительской) воспринимает, до чего же "те самые" — эти составленные в пустой комнате праздничные круглые транспарантики с портретом, один из которых отчаянно ломает и топчет Нино; какой-то иной, несравненно более глубокий слой памяти воспринимает традиционность древнего жеста моления, когда бедная женщина тут же склоняется перед самим вошедшим владыкой; но память может и не проснуться, все равно захватит суть: суть волнения и горя, суть верности, суть немилосердия. Среди творческих импульсов, властных над создателями этой картины,— ощущение кровной близости. Не то, чтобы Тенгиз Абуладзе стремился засвидетельствовать: вот как было с нами. Напротив, в "Покаянии" есть разгадывание общей модели, модели разлада мира, в котором обосновывается беззаконие и истребляется то, на чем мир стоит. Но как, разгадывая такую модель, не думать о своем.

Не поэтому ли той женщиной, которая плачет над клейменым стволом в сцене на путях, Тенгиз Абуладзе представлял себе свою жену и снял ее. Не поэтому ли тем серьезным маленьким мальчиком, который заглядывает в окно подвала и передает живущим там слух про бревна, Тенгиз Абуладзе видел своего внука и снял его. [...]

Вряд ли следует видеть в образности "Покаяния" образность, рождающуюся по законам лирического творчества — самораскрытия, поэтического самоизъявления. Вольность и острота образных сцеплений и ассоциаций в "Покаянии" иные по своей природе. Дар Тенгиза Абуладзе прежде всего в органике и силе воображения, откликающегося на нечто, что вне художника; в органике и силе вживания в чужое, не с ним лично бывшее. Он не изживает в творчестве собственные свои, преследующие его и ищущие воплощения образы и состояния, а вживается, проникаясь тем состраданием и ужасом, которые, по закону трагической поэзии, должны очищать душу. Режиссер "Покаяния" отдает себя боли и муке других так, как актер школы переживания отдает себя боли и муке того другого, кем предстает на сцене. Не свое состояние "до-сценическое", "до-экранное" выражает, а вникает в чужое, проникается чужим.

Творческая память Абуладзе — память, принимающая то, что ей передано, наследующая; в известной мере сыновняя память.

В русском фольклоре есть постоянное обращение — "отецкий сын"; "добрый молодец, отецкий сын". Казалось бы, образ не содержателен — кто ж без отца. Но по достоинству и вежеству в мужчине узнают воспитавшего его мужчину, узнают перенятый и оберегаемый закон. Человек не безроден. В этом-то смысле Тенгиз Абуладзе — "отецкий сын", и "отецким сыном" предстает в его картинах всякий, кто достоин уважения, живет ли он в героическом древнем доме-крепости, как в "Мольбе", или в завешанной холстами квартире, как в "Покаянии". [...]

В природе вещей, как ее понимает Важа Пшавела и как ее понимает Тенгиз Абуладзе, снимая "Мольбу" по его поэмам, есть трагизм; трагизм — природное наполнение жизни. Человек угрожает юной плакальщице, пробирающейся на кладбище; горит сжигаемый односельчанами дом Алуды, и истомленный горной дорогой отверженец с женой и детьми то ли исчезает, то ли приближается к нам в леденящем тумане. В трагедии человек может погибнуть, но не может исказиться, как не искажается и природа вещей. Искаженность караулит где-то рядом — там, где накладывает лапу ухмыляющийся собеседник поэта, его туго знающий свое дело антагонист, возникающий в первых же кадрах "Мольбы" и почесывающий за разговором голое пузо. […]

[...] Шут в фильме "Покаяние", как и в "Мольбе", на святом месте выламывается, ломает комедию. Именно что ломает и выламывается — это его дело. Шут против творца (знающие это дело подтвердят, что и в русской средневековой культуре улыбка есть атрибут неба, ад озвучен хохотом басов. Шутом, чтобы не поминать его истинного имени, называют того же, кого называют нечистым и лукавым). [...]

Не доказательству того, что негодяи — отпетые плуты, и даже не разгадке естества, потрясенного преступлением, служит картина. А уж скорее тому, о чем сказано во фреске "Уверение Фомы", которую разглядывала девочка Кето. Можно задуматься над ее сюжетом: апостол трогает язву, смерть от которой неминуема, и удостоверяется, что перед ним живой; будь стоящий перед апостолом мертв, самая мысль влагать персты в язвы мертвого не могла бы прийти.

Тенгиз Абуладзе своим фильмом удостоверяет, что мы живы. [...]

СОЛОВЬЕВА И. Королевская мысль // ИК. 1987. № 8.

У вашего проекта сменился разработчик и он говорит, что старый код невозможно использовать? Новая команда тратит много времени на решение простых задач? Как только удаётся справиться с одной проблемой, тут же ломается что-то другое? Скорее всего, проблема в качестве кода.

Что такое качественный код

Не существует точного определения этого термина. Как правило, понимание того, как должен выглядеть качественный исходный код, основывается на многолетнем опыте специалиста. Некоторые программисты придерживаются абстрактного принципа KISS, который расшифровывается как Keep It Simple, Stupid! («Делай это проще, тупица!»). Отчасти этот метод проектирования справедлив, так как отражает главное правило хорошего кода — простота и ясность. Однако простоту часто путают с упрощением, поэтому о качестве исходного кода в профессиональной среде судят ещё по нескольким свойствам:

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

Чтобы облегчить понимание кода в профессиональной среде, у каждого языка программирования есть свой Code Style — стандарт оформления. Именно он диктует правила: где ставить пробелы или скобки, как отделять строки или называть переменные. Может показаться, что эти нюансы не так важны, однако их соблюдение значительно облегчает понимание кода для тех, кто видит его впервые.

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

Как повысить качество кода?

Одна из самых популярных и при этом довольно простых в реализации техник носит название Code Review. Её смысл в том, чтобы любые изменения, вносимые программистом, попадали в основное хранилище кода и в релизную версию ПО только после того, как их проверят остальные участники команды.

Этот процесс состоит из нескольких этапов.

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

На втором этапе члены команды, или ревьюеры, отсматривают код и оставляют свои комментарии. Некоторые компании, практикующие Code Review, фокусируются только на поиске багов, но для реального повышения качества кода нужно также указывать на архитектурные недочёты, неправильное использование инструментов и плохой стиль написания — непонятный или плохо воспринимаемый.

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

Плюсы Code Review

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

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

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

Благодаря Code Review снижается так называемый bus-фактор, или «фактор автобуса». Так называют число, означающее количество участников команды, которых должен сбить автобус, чтобы все знания о проекте были потеряны. К примеру, в проекте занято четыре человека, если два из них по каким-то причинам уйдут, то оставшиеся смогут закончить работу, а если команду покинут трое — последний участник не справится в одиночку.

Минусы Code Review

По сути, главный и единственный минус этого процесса — его длительность. Всем участникам Code Review приходится тратить время на то, чтобы посмотреть и при необходимости прокомментировать код, а разработчику — на исправление ошибок.

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

Когда использовать Code Review?

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

К примеру, нет смысла проводить Code Review при разработке прототипа или MVP — минимально жизнеспособного продукта. Главная задача такого проекта — получить от пользователей обратную связь, чтобы построить гипотезы для дальнейшего развития. Структура этих приложений делается максимально простой, и в дальнейшем код всё равно предстоит переписывать кардинальным образом.

Ещё Code Review не нужен в работе над простыми приложениями, которые делаются раз и навсегда. Так что если вы не планируете в будущем изменять или дорабатывать свой проект, можно сэкономить время.

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

Помимо этого текста вы можете посмотреть ролик из нашего видеоблога , в котором я подробно рассказал о качественном коде и Code Review:

25 Sep 2013

Решил разбавить тематику и написать что-то вроде справочника, на который всегда можно дать ссылку и обновить. Некоторые вещи лучше не внедрять без объяснений. Нельзя сказать, завтра вы будете применять agile, парное программирование, tdd, так как это делают все крутые ребята.

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

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

Саморазвитие

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

Знание проекта

Знание проекта, того что в нем происходит, не проходит мимо тебя. Ты знаешь, что делает или сделал сосед. Иначе, можно дать просто права на push всем участникам, и каждый будет писать свой проект. Если вам не повезет, и каждый из участников проекта делает индивидуально большой кусок кода от 0 до 100 процентов, то через полгода вы не сможете вернуть свои глаза на место при необходимости внести даже небольшие изменения. Это равносильно тому, что программиста с улицы взять и посадить писать код. Будут только вздохи, охи, ахи, периодическая ругань. Одни эмоции и переживания, никакого кодинга. Возможна и другая ситуация, что вы железный дровосек без сердца, и можете только рубить лес от точки А до точки Б, не задумываясь о том, зачем этот лес посадили, и почему вы вырубаете именно эту часть леса.

Мы одна команда, одной крови

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

"$a = %d, $b = %d, $a + $b = %d" , $a , $b , $c ); ?>

$value ) { # code... } for ($i = 0 ; $i < $countElements = $count ($array ); $i ++ ) { # code... } $i = 0 ; $countElements = $count ($array ); while ($i < $countElements ) { # code... } ?>

Со временем даже от таких мелочей проект превращается в помойку. Сначала мы получаем два стиля в разных кусках кода, постепенно они перемешиваются, и...

Со сложными примерами, когда какая-то логика приложения делается по-разному, результат еще более близок к могиле. Вы либо получаете дублирование кода, либо первый результат в более плачевном виде. Например, кто-то бросает эксепшины, кто-то возвращает true/false, кто-то в строковом виде сообщение об ошибке, четвертый создает методы "черные дыры".

При код ревью команда самоорганизуется, выбирая те или иные правила, соглашения, best practice, и придерживается их. В результате сам код проекта - единое целое. Его можно теперь разделить по времени: "что мы вот так писали очень давно, были молоыде и не опытные, а вот так еще раньше". Но невозможно будет сказать, что это Вася гавнокодит так, а это вот Петькина козюлька. Никаких личностей.

Звезда по имени Я

Проходит звездность, приходит профессионализм. Это чаще всего заметно на "новичках". Всю жизнь ты писал так и никак иначе, а тут тебе на ревью: "что за ерунда?". Главное правильно отнестись к этому. Через это все прошли, никто не родился архитектором, никто не получил опыт при рождении.

Банальности

В заключении стоит привести какие-то очевидные плюсы:

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

Парное программирование

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

Очень часто, вы что-то прочитаете, услышите, а применить и самому написать некогда. Большая вероятность, что сосед уже это пишет и вам нужно только просто глянуть;).

Полезные ссылки

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

Posted by fightmaster code reviewclean codehandbook Категории clean code, code review, handbook