Как обработать несогласие в обзоре кода относительно маловероятного случая кромки?

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

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

Я приведу пример:

Я провел день, записывая тестовые примеры для изменения алгоритма поиска перехода, который я сделал. Он предположил, что я справляюсь с неясным случаем, который вряд ли произойдет - на самом деле я не уверен, что это возможно даже для этого. Код, который я сделал, уже работает во всех наших оригинальных тестовых случаях и некоторых новых, которые я нашел. Код, который я сделал, уже проходит наши 300+ симуляций, которые запускаются в ночное время. Однако, чтобы справиться с этим неясным случаем, мне понадобилось бы 13 часов, которые можно было бы потратить, пытаясь улучшить производительность робота. Чтобы быть ясным, предыдущий алгоритм, который мы использовали до сих пор, также не справлялся с этим неясным случаем, и не один раз, в 40-килограммовых отчетах, которые были сгенерированы, когда-либо происходило. Мы запускаем и нуждаемся в разработке продукта.

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


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

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

186 голосов | спросил Klik 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 03:46:22 +0300000000amSun, 05 Feb 2017 03:46:22 +030017 2017, 03:46:22

22 ответа


225
  

неясный случай, который крайне маловероятен, - на самом деле я не уверен, что это возможно даже

Неисследованное поведение в коде может быть очень важным. Если часть кода запускается, например, 50 раз в секунду, один из миллиона шансов будет происходить примерно каждые 5,5 часов работы. (В вашем случае шансы кажутся ниже.)

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

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

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

ответил 9000 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 04:16:39 +0300000000amSun, 05 Feb 2017 04:16:39 +030017 2017, 04:16:39
319

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

Когда Ariane 4 разрабатывались значения из бокового accelerometers были масштабированы, чтобы вписаться в 16-разрядное целое число со знаком и потому, что максимальный возможный выход акселерометров при масштабировании может никогда превышать 32767, а минимум может никогда упал ниже -32768, было «нет необходимости в накладных расходах». Обычно все входные данные должны быть проверены диапазоном перед любым преобразованием, но в этом случае это будет пытаться поймать невозможный угловой случай.

Несколько лет спустя разрабатывался Ariane 5 , и код для масштабирования боковых акселерометров был повторно использован с минимальным тестированием, поскольку это было «доказано в использовании». К сожалению, большая ракета могла ожидать больших боковых ускорений, поэтому акселерометры были модернизированы и могли производить более крупный 64-разрядный float .

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

Введите изображение здесь »> </a> </p>

<p> То, что я пытаюсь сделать, заключается в том, что вы не должны игнорировать тестовые примеры как  never ,  extreme  маловероятно и т. д .: стандарты, которые они кодировали для вызывается для проверки диапазона значений <strong> всех </strong> внешних входных значений. Если бы это было проверено и обработано, возможно, это было предотвращено. </p>

<p> <strong> Примечание </strong>, что в Ariane 4 это не было ошибкой,  (поскольку все работало хорошо для любого возможного значения)  - это было несоблюдение стандартов. Когда код был повторно использован в другом сценарии, он потерпел катастрофу, а если диапазон значений был обрезан, он, скорее всего, потерпел неудачу изящно, и наличие тестового примера для этого <strong>  могло бы  </strong> привели к пересмотру значений. Стоит также отметить, что, хотя кодеры и тестеры пришли к некоторой критике со стороны следователей после взрыва, руководство, QA & лидерство осталось с большей частью вины. </p>

<H2> Разъяснение </h2>

<p> Хотя не все программное обеспечение критично критично и не так впечатляет, когда оно терпит неудачу, я хотел подчеркнуть, что «невозможные» тесты могут по-прежнему иметь ценность. Это самый драматический случай, о котором я знаю, но робототехника также может привести к некоторым катастрофическим последствиям. </p>

<p> Лично я бы сказал, что, как только кто-то выделил угловой случай для тестовой команды, нужно проверить тест, чтобы проверить его. Руководитель команды реализации или руководитель проекта <strong> может </strong> решить не пытаться выявить обнаруженные ошибки, но должен знать, что существуют какие-либо недостатки. В качестве альтернативы, если тестирование слишком сложное или дорогостоящее для реализации, проблема может быть поднята во всех используемых трекерах и /или в регистре рисков, чтобы было ясно, что это непроверенный случай - что ему может понадобиться которые должны быть рассмотрены до смены использования или предотвращения ненадлежащего использования. </p></div>
										<div class=ответил Steve Barnes 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 14:15:16 +0300000000pmSun, 05 Feb 2017 14:15:16 +030017 2017, 14:15:16

84

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

ответил kevin cline 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 04:51:15 +0300000000amSun, 05 Feb 2017 04:51:15 +030017 2017, 04:51:15
53

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

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

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

ответил Karl Bielefeldt 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 05:21:28 +0300000000amSun, 05 Feb 2017 05:21:28 +030017 2017, 05:21:28
38

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

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

ответил JacquesB 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 13:12:46 +0300000000pmSun, 05 Feb 2017 13:12:46 +030017 2017, 13:12:46
21

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

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

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

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

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

ответил Neil Slater 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 13:04:02 +0300000000pmSun, 05 Feb 2017 13:04:02 +030017 2017, 13:04:02
15

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

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

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

ответил WorldSEnder 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 17:09:16 +0300000000pmSun, 05 Feb 2017 17:09:16 +030017 2017, 17:09:16
13

Поскольку вы, кажется, новичок там, вы можете сделать только одну вещь - проконсультируйтесь с руководителем группы (или руководителем проекта). 13 часов - деловое решение; для некоторых фирм /команд, много; для некоторых - ничего. Это не ваше решение, еще нет.

Если в свитке говорится «обложка этого дела», штраф; если он скажет «нах, вверните его», штраф - его решение, его ответственность.

Что касается обзоров кода вообще, расслабьтесь. Если задача возвращена вам один или два раза, это абсолютно нормально.

ответил Tom 6 FebruaryEurope/MoscowbMon, 06 Feb 2017 04:16:40 +0300000000amMon, 06 Feb 2017 04:16:40 +030017 2017, 04:16:40
7

Одна вещь, которую я не думаю, что я видел обращенный в натуральной форме, хотя это было вызвано в @SteveBarnes:

Каковы последствия отказа?

В некоторых полях ошибка является ошибкой на веб-странице. Синие экраны ПК и перезагрузка.

В других областях это жизнь или смерть - самовозгорание автомобиля блокируется. Медицинский производитель темпов перестает работать. Или в ответе Стива: всякие взрывы приводят к потере миллионов долларов.

В этих крайностях существует мир .

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

Вы должны быть в состоянии дать хорошее предположение о том, что будет стоить того. Будет ли ваш робот просто замедляться или останавливаться? Деградированная производительность? Или может произойти сбой робота от материального ущерба? Потеря жизни?

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

ответил WernerCD 7 FebruaryEurope/MoscowbTue, 07 Feb 2017 05:57:19 +0300000000amTue, 07 Feb 2017 05:57:19 +030017 2017, 05:57:19
5

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

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

ответил Konstantin Petrukhnov 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 13:55:06 +0300000000pmSun, 05 Feb 2017 13:55:06 +030017 2017, 13:55:06
5

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

Действуйте как Колумбо .

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

Я думаю, что это также связано с сократическим методом .


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

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

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

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

Что они видят, что вы не видите? Как вы видите, что они не видят? Будучи младшим разработчиком, вы действительно находитесь в отличной позиции, потому что вы естественно должны задавать вопросы. В другом ответе кто-то упоминает, как удивительно вероятно, что дело в углу. Итак, вы можете начать с: «Помогите мне понять, у меня сложилось впечатление, что X, Y и Z - что мне не хватает? Почему виджет будет очерчен? У меня создалось впечатление, что он будет искажен в сложных условиях. swizzle stick фактически вытесняет кисти ANZA? »

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

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

ответил Wayne Werner 7 FebruaryEurope/MoscowbTue, 07 Feb 2017 17:07:49 +0300000000pmTue, 07 Feb 2017 17:07:49 +030017 2017, 17:07:49
3

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

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

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

Что произойдет, ваш менеджер приколит вас к «go-getter» и начнет доверять вам, и ваши коллеги начнут видеть вас в качестве ведущего bc, которым вы начинаете владеть программой. И тогда, когда такие вещи, как то, о чем вы упоминаете, происходят в будущем, вы будете больше говорить, потому что вы по сути звезда команды, и товарищи по команде откажутся, если вы не согласитесь с ними.

ответил foreyez 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 06:23:35 +0300000000amSun, 05 Feb 2017 06:23:35 +030017 2017, 06:23:35
3

Обзор кода служит нескольким целям. То, о чем вы, очевидно, знаете, есть: « Является ли этот код подходящим? ». Другими словами, это функционально корректно; он адекватно проверен; - неочевидные части, которые были прокомментированы; Соответствует ли это соглашениям проекта?

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

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

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

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

Сделав множество общих утверждений выше, как это относится к вашей конкретной ситуации? Надеюсь, теперь очевидно, что мой совет - ответить на обзор с открытыми вопросами и обсудить , какой подход имеет наибольшее значение. Для вашего примера, в котором предлагается дополнительный тест, тогда что-то вроде «Да, мы можем проверить это, я полагаю, что для его реализации потребуется <time> . Как вы думаете, это выгодно это? И есть ли что-то еще, что мы можем сделать, чтобы гарантировать, что тест не нужен? »


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


Наконец, в качестве общего комментария к оценке кода (и в качестве содержательного резюме того, что я сказал выше), мне нравится это утверждение, в Контейнеры не уменьшают Daniel Vetter :

  

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

ответил Toby Speight 6 FebruaryEurope/MoscowbMon, 06 Feb 2017 13:51:52 +0300000000pmMon, 06 Feb 2017 13:51:52 +030017 2017, 13:51:52
3

Код может ВСЕГДА быть лучше.

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

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

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

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

Как вы это исправите? Ну, попросите вашего менеджера дать вам DOD и сказать вам, нужно ли всегда выполнять все комментарии. Если человек, о котором идет речь, является вашим менеджером, тогда ответ очевиден.

ответил user261610 6 FebruaryEurope/MoscowbMon, 06 Feb 2017 07:33:46 +0300000000amMon, 06 Feb 2017 07:33:46 +030017 2017, 07:33:46
3

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

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

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

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

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

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

ответил Jimmy Breck-McKye 7 FebruaryEurope/MoscowbTue, 07 Feb 2017 20:47:41 +0300000000pmTue, 07 Feb 2017 20:47:41 +030017 2017, 20:47:41
2
  

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

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

  

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

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

ответил Brad Thomas 6 FebruaryEurope/MoscowbMon, 06 Feb 2017 17:18:39 +0300000000pmMon, 06 Feb 2017 17:18:39 +030017 2017, 17:18:39
2

Предложения для рецензентов кода для повышения деловой пользы вашего обзора кода (вы, как OP, должны предлагать такое изменение):

  • Отметьте свои комментарии по типу. «Критический» /«Обязательный» /«Необязательный» /«Рекомендуемые улучшения» /«Приятно иметь» /«Я размышляю».

    Если это кажется слишком CDO /аналом /сложным, по крайней мере используйте 2 уровня: «Необходимо исправить, чтобы пройти проверку и разрешить объединить изменения» /«Все остальные».

Предложения по обработке рекомендаций по обзору кода, которые кажутся менее критическими:

  • Создайте открытый билет в своей системе выбора билетов (ваша команда использует, надеюсь,?), отслеживая предложение

  • Поместите билет # в качестве комментария к элементу проверки кода, если ваш процесс позволяет отвечать на комментарии, такие как Fisheye или отзывы по электронной почте.

  • Обратитесь к рецензентам и явным образом спросите, есть ли этот элемент в «необходимо исправить или не будет объединен /выпущен».

    • Если ответ «Да», но вы не согласны, позвольте ответственному за управление проектами (PM, ваш менеджер и т. д.) принять решение - полностью и честно представить несогласие. Это не о том, кто из вас «прав», а о том, что лучше для проекта, поэтому работа PM /менеджера.

Теперь обработайте этот билет как любой другой запрос на разработку.

  1. Если после эскалации будет принято срочное решение, обратитесь к нему как к любому срочному запросу. Отмените другую работу и поработайте над этим.

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

ответил DVK 6 FebruaryEurope/MoscowbMon, 06 Feb 2017 23:21:34 +0300000000pmMon, 06 Feb 2017 23:21:34 +030017 2017, 23:21:34
2

Вам следует не эскалировать это управление.

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

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

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

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

ответил Claudiu Creanga 7 FebruaryEurope/MoscowbTue, 07 Feb 2017 14:22:18 +0300000000pmTue, 07 Feb 2017 14:22:18 +030017 2017, 14:22:18
1

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

Если вы считаете, что что-то не так, и , вы относительно эксперт в своей области, то вероятность того, что вы правы .

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

  • Мне было предложено сделать X, обозреватель кода предлагает также делать Y, должен ли я это делать или мне нужно перейти к более важным материалам?
  • Вы предлагаете мне Y, так что вы можете найти хотя бы один тестовый пример, который поймал бы такое поведение, чтобы я мог его проверить? Я считаю, что код не будет вызываться.
  • Может быть, нам не следует сначала разрабатывать безопасный запас для непокрытых случаев? Таким образом, мы поймаем их на ранней стадии и исправим на ходу, чтобы мы могли сосредоточиться на более важных вещах.
  • Хорошо, в то время как я реализую Y, вы могли бы так любезно написать несколько тестовых примеров для этого, чтобы мы сделали эту вещь раз и навсегда ?
  • Мне было предложено сделать X, и я думаю, что смогу сделать Y, если нет других приоритетов. В следующий раз, почему вы не отправляете запрос функции вместо того, чтобы помещать его в качестве комментария к моему коду ? По крайней мере, мы можем услышать дальнейшие мнения других членов команды по этой функции перед ее внедрением (обычно любой важный материал должен быть функцией и должен обрабатываться более чем одним человеком; обычно обзор кода должен быть рассмотрен кода и решений, остальное - исправление ошибок и функции).

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

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

В общем, старайтесь избегать двух следующих действий:

  • Вы не выполняете то, что было запрошено.
  • Вы делаете свой рецензент глупым.

Если он действительно просматривает ваш код, это потому, что управление доверяет ему больше, чем вам.

ответил GameDeveloper 6 FebruaryEurope/MoscowbMon, 06 Feb 2017 16:25:16 +0300000000pmMon, 06 Feb 2017 16:25:16 +030017 2017, 16:25:16
-1

Когда в обзоре кода о области видимости есть несогласие:

  1. Документируйте область действия, которая фактически покрывается кодом. Никто не любит неприятные сюрпризы.
  2. Реализовать эту область действия - деловое решение. Сфера действия должна быть известна к моменту начала работы над функцией, но если это не так, вы всегда можете попросить разъяснения позже.

Если рецензент кода является тем, кто принимает бизнес-решения, он может изменить область действия в любое время, даже во время проверки кода, но он не делает этого в своей роли рецензента кода.

ответил Peter 10 FebruaryEurope/MoscowbFri, 10 Feb 2017 21:05:56 +0300000000pmFri, 10 Feb 2017 21:05:56 +030017 2017, 21:05:56
-1

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

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

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

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

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

ответил Zenilogix 13 FebruaryEurope/MoscowbMon, 13 Feb 2017 02:31:30 +0300000000amMon, 13 Feb 2017 02:31:30 +030017 2017, 02:31:30
-2

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

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

Какой из них вам подходит, и как обращаться со вторым видом - это больше вопрос для workplace.stackexchange.

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

ответил gnasher729 5 FebruaryEurope/MoscowbSun, 05 Feb 2017 23:07:58 +0300000000pmSun, 05 Feb 2017 23:07:58 +030017 2017, 23:07:58

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132