Хорошо ли просматривать программы со старшими и начальниками, даже если они работают нормально?


18

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

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

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


6
как вы можете быть уверены, что он работает нормально без проверки кем-то, кто не знает особенностей, к которым вы привыкли, когда проводите собственное тестирование
ratchet freak

потому что они проверяют код после полного тестирования модуля командой тестирования.
Химаншу

15
@Himanshu: Обзор после тестирования, безусловно, слишком поздно . Обзор (ы) должны быть сделаны на незавершенной работе.
Ян Худек

3
Примите эту практику. Я отчаянно желаю, чтобы мы делали это в моих командах. Это помогает устранить накопления знаний (огромная проблема для нас) и гарантирует, что ваши товарищи по команде могут работать с вашим кодом. Если ваши отзывы означают, что ваш код иногда переписывается, это хорошо. Даже великие программисты иногда пишут плохой код; некоторые из нас хотели бы больше времени, чтобы вернуться и почистить его. Это должно быть шансом получить большой опыт обучения с людьми более опытными, чем вы. Не воспринимайте это как людей, нападающих на ваш код; воспринимайте это как людей, пытающихся помочь вам стать более опытным программистом.
jpmc26

1
Если обычно «работающий нормально» код разбирается на части во время проверки кода в той степени, в которой члены команды считают, что много импульса теряется, то, возможно, вам следует подумать о парном программировании, чтобы код проверялся во время его работы. написано.
Buhb

Ответы:


38

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

Хороший код - это как минимум:

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

(Некоторые из этих требований фактически совпадают, но их следует рассмотреть индивидуально ...)

Обзоры кода служат не только «рабочей» части, что можно сделать с помощью автоматических тестов.

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

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


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

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

12

Я интерпретировал ваш вопрос как «Может ли мой функциональный код быть уничтожен в обзоре до такой степени, что он даже больше не будет компилироваться?» ,

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

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

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


3

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

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

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

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

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


1
Интеграционные тесты также чрезвычайно полезны для обнаружения поломок.
jpmc26
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.