Должны ли мои коллеги просматривать код друг друга из системы контроля версий?

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

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

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

Я бы сказал ДА!

Две быстрые причины для этого:

1) Если код находится в производстве, вы не можете предполагать, что он правильный. Любое изменение в другом месте системы может привести к ошибкам. Я думаю, что очень важно регулярно проверять код. Таким образом, рефакторинг выполняется на регулярной основе, сохраняя код аккуратным и «более» правильным (обновленная версия, вероятно, лучше).

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

Я не думаю, что вы должны чувствовать шпионаж. Примите любую критику, которую кто-то дает вам (если она действительна, конечно). И не стесняйтесь давать другим людям ДЕЙСТВИТЕЛЬНУЮ критику. Это способ, которым мы учимся. Как только мы перестаем учиться (или хотим остановиться), возникают большие проблемы.

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

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

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

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

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

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

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

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

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

Вы чувствуете, что шпионят за (!)? Но с точки зрения вашего коллеги, я бы сказал, что он делает правильные вещи для развития своей карьеры. Читайте чужой код и узнайте, как они проектируют и реализуют логику, это принесет вам много пользы!

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

В течение 6-7 месяцев я делал то же самое. Не для шпионажа, а для контроля качества. Каждая строка кода для активно развивающегося приложения, выделенная для центрального репозитория, 2 основных языка, несколько других языков, огромные make-файлы для 4 платформ.

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

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

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

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

Я надеюсь, что у вас есть более зрелая аудитория.

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

Не обижайтесь и не чувствуйте, что на вас смотрят. Думайте об этом как о защитной сетке и опыте обучения.

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

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

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