Нужны ли обзоры кода для начинающих разработчиков?

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

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

Однако во второй компании руководителям группы не требовалось проводить какие-либо проверки кода, а просто проверяли функциональность и проблемы с дизайном.

Так что я в замешательстве. Действительно ли необходим процесс проверки кода? Если это так, почему? А если нет, то почему бы и нет?

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

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

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

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

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

РЕДАКТИРОВАТЬ: Причина в том, что рецензент кода сегодня точно так же, как сопровождающий позже. Если код не имеет смысла для него сегодня, он не будет иметь смысла позже, делая ошибки более дорогими для исправления. Следовательно, ДЕЛАЙТЕ это понятным сегодня, пока разработчик все еще помнит код. Также рецензент может увидеть ошибки или упущения, которые пропустил разработчик.

К сожалению, очень немногие хотят это сделать, но с точки зрения бизнеса это должно быть обязательным.

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

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

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

Часто, что я видел в обзоре кода, так это то, что самому объяснению чего-то другому разработчик включит лампочку в своей голове и поймет, что есть ошибка, которую обозреватель не увидел.

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

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

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

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

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

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

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

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

Обзоры кода могут выявлять дефекты на ранних этапах жизненного цикла программного обеспечения, когда проблемы легче (и дешевле) устранить. В SmartBear мы разработали инструмент для рецензирования кода. а также провели много исследований о том, как сделать рецензирование кода эффективным. По данным наших клиентов, дефекты, обнаруженные в обзоре кода, в 8-12 раз дешевле найти и исправить, чем дефекты, обнаруженные в QA. Одна только экономия на затратах делает обзор кода стоящим, но есть больше ценности, чем просто это. Обзор кода - отличный способ для всех в команде учиться и совершенствоваться как разработчики программного обеспечения.

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

Я думаю, что пересмотр кода ВСЕ КОДЫ излишним. Количество времени, необходимое для просмотра всего кода, лучше потратить в другом месте. Alterntivley Я думаю, что критический код и / или особенно сложные части требуют пересмотра кода, но, конечно, не каждая строка кода.

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

Но как насчет тех компаний, которые не пересматривают код? Вероятно, это компании, у которых много технических проблем и, как говорят потребители, "вылетает" ;-).

Итак, позвольте мне ответить на все ваши вопросы:

• Да, процесс обзора необходим.
• Зачем? По причинам, которые я изложил выше.

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

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

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

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

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

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

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

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

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

Подобный анализ кода бесполезен, но проверка кода с компетентной командой часто может пролить свет на что-то о дизайне (например, почему вы должны делать X и Y, а не Z) или указать фактический недостаток (например, выполнение X приведет к сбою Y по неверным причинам).

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

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

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

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

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

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

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

Они абсолютно необходимы, так как у них мало опыта.