Что я должен делать, ожидая обзора?

Прежде чем задать свой вопрос, я должен объяснить ситуацию.

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

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

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

У меня вопрос, что мне делать? Должен ли я ждать его обзора?

РЕДАКТИРОВАТЬ: дополнение к вопросу. Мне интересно еще один вопрос.

Я хочу быть свободным при кодировании. Как я могу завоевать доверие к свободе развития?

_{Некоторые объяснения: я говорил с ним об этом. Но это не помогло. Мы уже используем систему отслеживания проблем, но нет никаких задач для обзоров. Есть только задачи по разработке и тестированию.}

Так что мой код тоже опоздал.

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

И для вашего редактирования:

Я хочу быть свободным при кодировании. Как я могу завоевать доверие к свободе развития?

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

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

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

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

Я хочу быть свободным при кодировании. Как я могу завоевать доверие к свободе развития?

Чтобы выяснить это, нужно сначала понять цель проверки кода. Вы упомянули доверие - это хорошее «приближение», но не совсем точное.

• ^{Например, в одном из моих недавних проектов разработка была сделана мини-командой из меня и моего коллеги. Мы полностью доверяли друг другу и уважали друг друга, но, несмотря на это, мы просмотрели 100% кода. Мы делали это, потому что это позволило нам найти и быстро исправить некоторые ошибки и, что также очень важно, потому что обзоры не занимали много времени и не блокировали нашу работу.}

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

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

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

В зависимости от проекта, в какой-то момент ваш код может даже считаться достаточно безопасным, чтобы вообще пропускать проверки, оставляя обнаружение ошибок тестировщикам (но это не обязательно произойдет, см. Мой пример выше).

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

• Если ваша главная проблема - «я пропускаю сроки», нет. Вы двое совместно пропускаете сроки. Можете ли вы (с уверенностью) сказать: «Я сделаю это через час, можем ли мы тогда выполнить проверку кода»? Этого может быть достаточно. Можете ли вы заполнить код за день до крайнего срока? Это должно быть обильным буфером. Завершаете ли вы свой код с достаточным количеством буфера между «пожалуйста, просмотрите» и крайним сроком? Если последнее, это даже не совместная ошибка, я бы сказал.

• Код всегда должен быть пересмотрен. Я ничего не могу проверить без (по крайней мере) второго набора глаз и другого человека, идущего "все в порядке". Это относится к проектам, в которых я являюсь ведущим программистом, а также к проектам, в которых я обычно не участвую (но мне удалось найти ошибку, затрагивающую меня, которую я хочу исправить). Тем не менее, строгость обзора во многом основана на доверии. Если я верю, что человек, желающий представить код, хорошо знает кодовую базу, я не буду настолько строг, как если бы я не знал, насколько хорошо человек знает кодовую базу.

У меня вопрос, что мне делать? Должен ли я ждать его обзора?

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

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

Я хочу быть свободным при кодировании. Как я могу завоевать доверие к свободе развития?

Есть некоторые правила, которые требуют, чтобы старший проверял работу младшего (я думаю, что медицинский стандарт ISO 62304 требует этого). Если это так, вы ничего не можете сделать.

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

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

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

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

Страница Википедии о парном программировании

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

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

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

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

Не полный ответ сам по себе, просто дополнение к превосходным ответам выше ...

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

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

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

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

Некоторые или все эти предложения могут быть сделаны, ожидая, пока кто-то еще просмотрит ваш код.

Я думаю, что выполнение ручных проверок кода - это ... ну ... вроде 80-х годов. Ну, может быть, 90-е.

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

Давай, люди. Вот для чего нужны наборы изменений (или списки изменений). Вы заставляете своих программистов кормить голодных пастей вашей системы контроля версий. Затем ваш сервер непрерывной интеграции включит целую кучу целевых сборок (ну, надеюсь, только ежедневная сборка, но некоторые из нас увлекутся). Если что-то сломается, вы кладете трофей обезьяны с кодом (обычно пластиковую игрушку, которую кто-то нашел в ящике с хлопьями Lucky Charms) на стол преступника и откатываете список изменений. Ну, некоторые системы непрерывной интеграции автоматически отправляют уведомления по электронной почте / IM / рабочему столу всем сотрудникам группы / отдела / организации о том, что сборка повреждена, вместе с изящной гиперссылкой, чтобы показать всем, кто именно нарушил сборку, в каком файле или тесте. Теперь это несчастный программист

Когда этот процесс продолжается, включается система проверки кода (опять же, запускаемая при регистрации). Список квалифицированных членов команды уведомляется о том, что список изменений передается в систему контроля версий, в системе проверки запускается проверка, и все начинают комментировать изменения в списке изменений. Надеюсь, все скажут "LGTM". Если программист умен, он не забудет молиться / подкупать / прятаться. Если есть серьезные проблемы, рецензенты могут создать дефект (который может быть подключен к системе отслеживания ошибок) или даже потребовать отмены списка изменений. Да, отклоненные изменения наносят ущерб не только эго, но и разуму, это правда. Это хорошая приправа для начинающих разработчиков, чтобы реинтегрировать отклоненные списки изменений.

Если в вашей среде разработки отсутствует CI или система проверки кода, вам следует серьезно изучить их. Несколько ссылок могут помочь вам:

Atlassian Crucible
JetBrains TeamCity
reitveld
Круиз-контроль

Если вы собираетесь получить CI-сервер, вам также следует серьезно подумать о модульных тестовых средах. Если вы C # dev, посмотрите что-то вроде NUnit, чтобы начать.

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