Допустим, один работает в гипотетической компании, в которой есть несколько разработчиков, которые редко работали вместе над проектами, и Босс не верил, что проверки кода стоят времени и затрат.
Какие различные аргументы могут быть представлены в этом сценарии, которые будут отражать преимущества анализа кода? Кроме того, каковы потенциальные аргументы против проверки кода здесь и как им можно противостоять?
Если вы должны оправдать себя за такие базовые вещи, у вас есть большая проблема.
Вы эксперт, ваша команда должна решить, какие методы вы используете. Может быть, вы должны начать убеждать своего начальника в этом очень важном принципе.
Ваш босс должен решить, ЧТО делать и, что важнее, ЗАЧЕМ это делать. Вы должны позаботиться о том, КАК построить его
(это не значит, что вы не можете подсказать, что и зачем делать в вашей компании, конечно). Великий начальник должен поощрять своих сотрудников к участию в стратегии предприятия)
Однако вот как я смотрю рецензии кода:
Поскольку программирование - это очень интенсивная интеллектуальная работа, один человек не может гарантировать, что все идеально. Поэтому проверка кода гарантирует, что:
Все получают прямые выгоды от этого:
Обзор кода может познакомить нескольких разработчиков с одним и тем же кодом. Это хорошая вещь. Что если оригинальный автор решит уйти или хуже, с ним случится что-то плохое. Если проверки кода выполняются регулярно, другие могут быстро приступить к работе.
Возможно, коллеги обнаружат потенциальные ошибки или проблемы с производительностью во время проверки кода. Это уменьшает QA и усилия по разработке. Это может компенсировать дополнительные расходы, связанные с проверкой кода.
Обзоры кода способствуют обмену знаниями. Пэры могут рассказать о лучших способах или альтернативных способах делать вещи. Я сам многому научился у своих коллег по обзорам кода.
Обзоры кода помогают усилить руководящие принципы кодирования, которым руководствуется команда. Если у команды его нет, это нужно исправить. Код предназначен для написания один раз и чтения много раз. Правила кодирования - это шаг к читабельному коду. Код предназначен для чтения читателями. Что может быть лучше, чем обзоры кода для обеспечения читабельности?
источник
Здесь много хороших ответов. Некоторые вещи, которые я бы добавил:
Когда вам приходится объяснять код кому-то еще, часто в ходе объяснения разработчик может внезапно понять, что у него есть ошибка. Я видел, как это происходит снова и снова, когда разработчик останавливается на месте и говорит: «О, подождите, это неправильно», прежде чем рецензент понял это достаточно хорошо, чтобы увидеть ошибку.
Знание того, что ваш код будет проверен кем-то другим, дает вам больше стимулов использовать стандарты кодирования (облегчая обслуживание) или использовать менее «ковбойские» методы, которые никто, кроме вас (а иногда и даже вы сами), никогда не поймет. Вы не хотите смущаться, когда вы показываете свой код кому-то другому, поэтому вы лучше справляетесь с этим. Из-за фактора смущения он оставляет меньше кода с комментариями: «Я не знаю, почему это работает, но не связывайтесь с ним». в кодовой базе.
Разработчики, которые нуждаются в более широком надзоре или обучении, легко идентифицируются. Так и откровенно некомпетентны. Чем раньше вы сможете найти и решить проблемы с производительностью, тем лучше будет команда в целом и тем выше будет качество приложения. Хорошо узнать эту информацию, прежде чем взять нового парня, который нуждается в обучении, и назначить его для самой сложной, самой важной части вашего приложения.
Иногда это просто вопрос исправления неправильного восприятия, которое спасет от повторения той же ошибки в куче других мест. Например, мы недавно просматривали некоторые SQL для сложных отчетов и обнаружили, что у некоторых наших новых разработчиков было одинаковое недопонимание относительно того, где найти конкретную часть информации в базе данных (по общему признанию место, которое они выбрали, казалось логичным, что является проблемой проектирования базы данных, которую мы также необходимо исправить), что будет иметь решающее значение для правильного написания всех отчетов. Обнаружив проблему и исправив ее в первых отчетах, которые они написали, она сохранила ту же ошибку, что и в остальных отчетах. И кое-что старшие (во времени, работающие здесь, а не в возрасте) разработчики настолько привыкли к тому, что не думали, что это нужно объяснять.
Младшие могут извлечь уроки из более сложного кода, написанного старшими (которые, например, лучше понимают перехват ошибок и крайние случаи), а старшие могут узнать из новых методов, используемых младшими, с которыми они еще не сталкивались.
Иногда люди, работающие над разными, но связанными частями приложения, понимают, что они движутся в двух разных и взаимоисключающих направлениях. Упс, проще исправить
Не так легко проникнуть в жестко закодированные значения, которые со временем изменятся, просто чтобы заставить вещь работать сейчас. Это предотвращает множество будущих ошибок, таких как вещи, которые меняются в начале каждого финансового года.
Иногда я зацикливался на том, как что-то сделать, и изучал новую технику, которая была именно тем, чего я хотел от просмотра кода чужих вещей.
Если вы знакомы с тем, как думают другие члены вашей команды (какой анализ кода поможет вам в этом разобраться), вам будет легче решать проблемы позже, потому что вы начнете с понимания того, как Джо подошел бы к такому виду. проблема.
источник
Помимо обмена знаниями, упомянутого другими, найдите примеры ошибок, которые могли бы быть обнаружены во время обзора кода, и оцените, сколько времени они потратили на исправление - это включает время, потраченное на исследование проблемы и выпуск исправленной версии, а также фактическое время исправления ошибки.
Возьмите эту стоимость, которая, вероятно, займет минимум пару дней, и сравните ее со временем, которое вы потратили бы на проверку кода и на результат.
Это покажет вашему боссу, что проверки кода стоят затрат.
источник
Обзоры кода могут:
Cons
Если это так, то почему у нас всегда есть время, чтобы сделать что-то два или три раза для одного и того же клиента, но у нас никогда не хватает времени, чтобы сделать это правильно с первого раза.
источник
Если вам нужно сослаться на документ, я бы посмотрел не что иное, как «Код завершен». В ней описывается, сколько ошибок выявляется при юнит-тестах и рецензировании. Это поразительно. Модульные тесты, если память мне не изменяет, отлавливают только ~ 30% всех ошибок, в то время как формальные рецензии - ~ 70%.
Возьми эту информацию, покажи ему в книге и обратись к его финансовой стороне. Требуется намного больше времени и намного дороже, чтобы пропустить ошибки, чем рано их выявлять.
источник
Как насчет запуска демонстрации (однонедельный проект типа «микки маус»), выполняемой параллельно двумя командами, одна из которых использует проверку кода, а другая - нет.
В конце недели, оцените качество работы каждой команды, я вполне уверен, что рецензенты кода будут лучше.
источник
От Convex от Стива Макконнела В данном разделе приведено экономическое обоснование лучших практик программного обеспечения и разработки программного обеспечения (LHF). Из последнего «LHF, которому не будет противостоять высшее руководство», перечислены инспекции.
источник
Представляя это, сосредоточьтесь на большей картине.
Перечислите преимущества (лучший код, меньше ошибок, меньше переписываний и т. Д.) И упомяните проверку кода как один из методов, которые вы бы порекомендовали.
Я хотел бы сделать это частью более широкой картины мастерства программного обеспечения
Будьте готовы проделать большую работу самостоятельно в продвижении этих принципов.
Большинство из них не ожидают, что убеждение будет чем-то вроде «одной встречи и сделано».
Вы должны строить дело со временем спокойно и последовательно. Когда вас больше всего раздражают ошибки, которые могли бы быть исправлены лучшими методами, зачастую это самое плохое время для обоснования вашего мнения, поскольку вы, скорее всего, будете чрезмерно эмоциональны и менее рациональны. Это может показаться странным, но это то, чему я научился за 30 лет программирования. Очевидно, мммм.
источник