В конце двухнедельного спринта, и у задачи есть проверка кода, в обзоре мы обнаруживаем функцию, которая работает, доступна для чтения, но она довольно длинная и имеет несколько запахов кода. Простая работа рефакторинга.
В противном случае задача соответствует определению выполненного.
У нас есть два варианта.
- Сбой проверки кода, чтобы билет не закрывался в этом спринте, и мы немного пострадали от морали, потому что мы не можем выдать билет.
- Рефакторинг - это небольшая часть работы, которая будет выполнена в следующем спринте (или даже до того, как он начнется) в виде крошечной истории с половиной баллов.
У меня вопрос: есть ли какие-то проблемы или соображения, связанные с поднятием заявки с обратной стороны обзора, а не с ошибкой?
Ресурсы, которые я могу найти и которые читают подробные обзоры кодов, обычно составляют 100% или ничего, но я считаю, что это обычно нереально.
agile
code-reviews
Эрдрик Айронроуз
источник
источник
Ответы:
Не по своей сути. Например, реализация текущего изменения, возможно, обнаружила проблему, которая уже существовала, но не была известна / очевидна до сих пор. Отказ от билета был бы несправедливым, поскольку вы потерпели бы неудачу из-за чего-то, не связанного с фактически описанной задачей.
Тем не менее, я предполагаю, что эта функция добавлена текущим изменением. В этом случае билет должен быть не пройден, так как код не прошел тест на запах.
Где бы вы нарисовали линию, если не там, где вы ее уже нарисовали? Вы явно не думаете, что этот код достаточно чистый, чтобы оставаться в кодовой базе в его текущей форме; так почему бы вам тогда подумать о выдаче билета?
Мне кажется, что вы косвенно утверждаете, что пытаетесь дать этому билету пропуск, чтобы повысить моральный дух команды, а не улучшить качество кодовой базы.
Если это так, то у вас смешанные приоритеты. Стандарт чистого кода не следует менять просто потому, что он делает команду счастливее. Правильность и чистота кода не зависят от настроения команды.
Если реализация исходного тикета вызвала запах кода, то к нему следует обратиться в оригинальном тикете. Вы должны создавать новый билет только в том случае, если запах кода нельзя напрямую отнести к оригинальному билету (например, сценарий «соломинка, которая сломала спину верблюда»).
Проход / неудача по своей сути является двоичным состоянием , которое по своей сути является всем или ничем.
Я думаю, что здесь вы имеете в виду больше то, что вы интерпретируете обзоры кода как требующие идеального кода или иным образом его не выполняющие, а это не так.
Код не должен быть безупречным, он должен просто соответствовать разумным стандартам чистоты, применяемым вашей командой / компанией. Приверженность этому стандарту является бинарным выбором: он придерживается (проходит) или нет (не проходит).
Исходя из вашего описания проблемы, ясно, что вы не думаете, что это соответствует ожидаемому стандарту кода, и поэтому его не следует передавать по скрытым причинам, таким как командный дух.
Если бы «он выполнял свою работу» был лучшим эталоном качества кода, то нам не пришлось бы изобретать принцип чистого кода и хорошую практику для начала - компилятор и модульное тестирование уже были бы нашим автоматическим процессом проверки и Вам не понадобятся обзоры кода или аргументы стиля.
источник
Почему это всплывает в конце спринта? Проверка кода должна произойти, как только вы думаете, что код готов (или даже раньше). Вы должны проверить свое определение готово с каждой историей, которую вы закончите.
Если вы заканчиваете рассказы так незадолго до просмотра демонстрации / спринта, что не можете выполнить это «крошечное» задание, тогда вам нужно лучше оценивать свою работу. Да, эта история не закончена. Не из-за проверки кода, а потому, что вы не планировали вносить изменения из проверки кода. Это все равно что оценивать «тестирование» на нулевое время, потому что «если вы запрограммировали его правильно, оно просто сработает, верно?». Это не так, как это работает. Тестирование обнаружит ошибки, а проверка кода найдет, что изменить. Если этого не произойдет, это будет большая трата времени.
Итак, подведем итог: да, DoD является двоичным. Проход или провал. Обзор кода не является двоичным, он должен быть больше похож на текущую задачу. Вы не можете потерпеть неудачу . Это процесс, и, в конце концов, это сделано. Но если вы не спланируете должным образом, вы не доберетесь до стадии «выполнено» вовремя и застрянете на «не выполненной» территории в конце спринта. Это не хорошо для морального состояния, но вы должны учитывать это при планировании.
источник
Просто: вы просматриваете изменения . В противном случае вы не просматриваете состояние программы. Если я исправлю ошибку в функции 3000 строк, то вы убедитесь, что мои изменения исправят ошибку, и все. И если мое изменение исправляет ошибку, вы принимаете это изменение.
Если вы считаете, что функция слишком длинная, вы добавляете запрос на изменение, чтобы сделать функцию короче, или разделяете ее после того , как мое изменение было принято, и тогда этот запрос на изменение может быть расставлен по приоритетам в соответствии с его важностью. Если будет принято решение о том, что у команды есть более важные дела, то это будет выполнено позже.
Было бы смешно, если бы вы могли определять приоритеты разработки во время проверки кода, и отклонение моего изменения по этой причине было бы попыткой определить приоритеты разработки.
Таким образом, абсолютно приемлемо принять изменение кода и немедленно поднять заявку, основываясь на том, что вы видели при просмотре изменения. В некоторых случаях вы даже сделаете это, если само изменение вызвало проблемы: если более важно иметь изменения сейчас, чем исправлять проблемы. Например, если другие были заблокированы в ожидании изменений, то вы хотите разблокировать их, пока код можно улучшить.
источник
Кажется, это проблема.
Теоретически вы знаете, что должны делать, но это близко к крайнему сроку, поэтому вы не хотите делать то, что знаете, что должны делать.
Ответ прост: делайте все, что бы вы ни делали, если бы вы получили тот же код для проверки кода в первый день спринта. Если это будет приемлемо, то это должно быть сейчас. Если бы не было, то не было бы сейчас.
источник
Огромная часть процесса - решить, что значит сделать, и придерживаться своего оружия. Это также означает, что вы не должны чрезмерно фиксировать и своевременно проводить коллегиальные обзоры, чтобы позволить тестированию убедиться, что работа также завершена функционально.
Когда дело доходит до проблем с проверкой кода, есть несколько способов справиться с этим, и правильный выбор зависит от нескольких факторов.
Суть в том, что когда вы закончите с работой, вам нужно покончить с ней. Если есть проблемы больше, чем то, над чем работал разработчик, поднимите флаг и продолжайте. Но вы не должны находиться в положении, когда до конца спринта остаются часы, и вы только что приступили к рецензированию. Это пахнет как чрезмерная передача ваших ресурсов или откладывание на рецензии. (запах процесса).
источник
Нет проблем, связанных с удалением приоритетов при проверке кода, но похоже, что основными вопросами, с которыми вы, как команда, должны согласиться, являются:
Все это сводится к тому, что команда согласилась с определением «Готово». Если прохождение проверки кода с нулевыми ошибками является определением выполненного для рабочего элемента, вы не можете закрыть элемент, который не соответствует этому требованию.
Это так же, как если бы во время модульного тестирования провалился модульный тест. Вы бы исправили ошибку, а не игнорировали модульное тестирование, если прохождение модульных тестов было требованием для завершения.
Если команда не согласилась с тем, что проверки кода являются определением «Готово», то проверки кода не являются проверочным приемочным тестом для рабочего элемента. Это командная деятельность, которая является частью вашего процесса ожидания, чтобы найти дополнительную работу, которая может потребоваться. В этом случае любые обнаруженные вами проблемы не связаны с требованиями исходного рабочего элемента и являются новыми рабочими элементами, которые команда должна расставить по приоритетам.
Например, для группы может быть вполне приемлемым удаление приоритетов в исправлении опечаток в именах некоторых переменных, поскольку это не влияет на предоставленную бизнес-функциональность, даже если команда действительно ненавидит видеть имя переменной «myObkect».
источник
Ответы с более высоким рейтингом здесь очень хороши; это касается угла рефакторинга.
В большинстве случаев большая часть работы по рефакторингу заключается в понимании существующего кода; изменение его после этого - обычно меньшая часть работы по одной из двух причин:
Если просто сделать код более понятным и / или лаконичным, необходимые изменения очевидны. Часто вы получили понимание кода, попробовав изменения, которые казались чище, и увидели, действительно ли они работали, или пропустили некоторые тонкости в более сложном коде.
Вы уже имеете в виду конкретный дизайн или структуру, которая необходима для облегчения создания новой функции. В этом случае, работа по разработке этого дизайна была частью истории, которая породила потребность в нем; это не зависит от того, нужно ли вам проводить рефакторинг, чтобы добраться до этого дизайна.
Изучение и понимание существующего кода - это значительный объем работы для непостоянной выгоды (через месяц кто-то может многое забыть о коде, если он не будет продолжать читать или работать с ним в течение этого времени), и поэтому не имеет смысла делать это, кроме тех областей кода, которые вызывают у вас проблемы или которые вы планируете изменить в ближайшем будущем. В свою очередь, поскольку это основная работа по рефакторингу, вам не следует выполнять рефакторинг кода, если только он не вызывает у вас проблем или вы не планируете изменить его в ближайшем будущем.
Но есть одно исключение: если кто-то в настоящее время хорошо понимает код, который со временем утечет, использование этого понимания для того, чтобы сделать код более ясным и более быстрым для понимания в дальнейшем, может быть хорошим вложением. Это ситуация, в которой находится тот, кто только что закончил разработку истории.
В этом случае вы думаете о создании отдельной истории для рефакторинга, это предупреждающий знак по нескольким направлениям:
Вы не думаете о рефакторинге как о части кодирования, а как о отдельной операции, которая, в свою очередь, делает возможным падение под давлением.
Вы разрабатываете код, который будет более трудоемким для понимания в следующий раз, когда кому-то понадобится работать с ним, что сделает истории более длительными.
Возможно, вы тратите время и силы на рефакторинг вещей, от которых вы не получаете большой пользы. (Если изменение произойдет намного позже, кому-то все равно придется заново понимать код, в любом случае; это более эффективно сочетается с заданием рефакторинга. Если изменение не произойдет позже, рефакторинг не помог цель вообще, кроме, возможно, эстетической.)
Таким образом, ответ здесь состоит в том, чтобы провалить элемент, чтобы прояснить, что что-то в вашем процессе не удалось (в данном случае это разработчик или команда, не выделяющая время на проверку и внесение изменений, вытекающих из проверки), и попросить разработчика немедленно продолжить работу на предмет.
Когда вы перейдете к оценке для следующей итерации, переоцените существующую историю как оставшуюся часть работы, чтобы она прошла проверку и добавила ее к вашей следующей итерации, но сохранив оценку из предыдущей итерации. Когда история будет завершена в конце следующей итерации, задайте общий объем работы за прошлый период равным сумме первой и второй оценок, чтобы вы знали, сколько оценочной работы действительно было вложено в нее. Это поможет получить более точные оценки подобных историй в будущем при текущем состоянии вашего процесса. (То есть, не думайте, что ваша кажущаяся недооценка больше не повторится; предположите, что это случится снова, пока вы успешно не закончите подобные истории, выполняя меньше работы.)
источник
Я удивлен отсутствием ответа в ответах и комментариях на понятие «провал» проверки кода, потому что это не концепция, с которой я лично знаком. Я также не был бы доволен этой концепцией или кем-либо из моей команды, использующей эту терминологию.
Ваш вопрос явно призывает к «гибкой практике», поэтому давайте вернемся к гибкому манифесту (выделение мое):
Поговорите с вашей командой. Обсудите рассматриваемый код. Оцените затраты и выгоды и решите - как сплоченная группа экспертов - реорганизовать ли этот код сейчас, позже или никогда.
Начни сотрудничать. Хватит проваливать проверки кода.
источник
В обзоре мы обнаруживаем функцию, которая работает, доступна для чтения, но она довольно длинная и имеет несколько запахов кода ...
Есть ли какие-то проблемы или соображения, связанные с поднятием заявки с обратной стороны обзора, а не с ошибкой?
Никаких проблем вообще (по мнению моей команды). Я предполагаю, что код соответствует критериям приемлемости, указанным в билете (т.е. он работает). Создайте элемент журнала невыполненных работ, чтобы указать длину и любой запах кода, и расставьте приоритеты, как любой другой тикет. Если это действительно маленький, то просто расставьте приоритеты для следующего спринта.
Одно из высказываний, которое мы имеем: «Выбирай прогрессивное улучшение вместо отложенного совершенства».
У нас очень плавный процесс, и мы создаем довольно много функций «проверки концепции» (1 или 2 на спринт), которые проходят через разработку и тестирование, но никогда не проходят проверку внутренними заинтересованными сторонами (хм, можем ли мы сделать это вместо этого? ?), альфа или бета ... некоторые выживают, некоторые нет.
В текущем проекте я потерял счет того, сколько раз мы создавали определенную функцию, передавали ее в руки заинтересованных сторон, а один или два спринта полностью удаляли ее, потому что направление продукта изменилось или требования вызвали полный пересмотр того, как эта функция должна быть реализована. Любые оставшиеся задачи «уточнения» для удаленной функции, или не соответствующие новым требованиям, удаляются, а также часть очистки отставания.
источник
Есть два способа взглянуть на эту проблему по моему мнению:
С академической точки зрения, большинство процессов проверки кода существуют для сбоя при развертывании PBI (элемент невыполненной работы продукта), когда не выполняется стандарт качества кода.
Тем не менее, никто в реальном мире не придерживается гибкого подхода к Т, так как по разным причинам многие отрасли предъявляют разные требования. Таким образом, исправление кода сейчас или взятие на себя технического долга (вы, скорее всего, создадите новый PBI) должны решаться для каждого конкретного случая. Если это может скомпрометировать спринт или релиз, или привести к необоснованному риску, заинтересованные стороны должны быть вовлечены в решение.
источник
Ни один . Если он не проходит проверку кода, то задача не выполнена. Но вы не можете не проверять отзывы о личном мнении. Код проходит; перейти к следующему заданию.
Это должен быть простой вызов, и тот факт, что это не говорит о том, что у вас нет достаточно четких записанных правил для проверки кода.
«Функция довольно длинная». Запишите: функции должны быть длиной менее X строк (я не предполагаю, что правила о длине функции - это хорошо).
«Есть некоторые запахи кода». Запишите: публичные функции должны иметь модульные тесты на функциональность и производительность, использование ЦП и памяти должно быть в пределах x и y.
Если вы не можете количественно определить правила для прохождения проверки кода, то вы получите эти примеры того, что по сути является «кодом, который вам не нравится».
Если вы провалите «код, который вам не нравится»? Я бы сказал нет. Вы, естественно, начнете проходить / не проходить, основываясь на не кодовых аспектах: вам нравится человек? Они решительно отстаивают свое дело или просто делают, как им говорят? Они передают ваш код при просмотре?
Кроме того, вы добавляете не поддающийся количественному измерению шаг в процессе оценки. Я оцениваю задачу, основываясь на том, как я думаю, что она должна быть запрограммирована, но затем в конце я должен изменить стиль кодирования.
Как долго это добавит? Будет ли тот же рецензент выполнять последующую проверку кода и соглашаться с первым рецензентом, или они найдут дополнительные изменения? Что делать, если я не согласен с изменением и откладываю его, пока ищу второе мнение или аргументирую дело?
Если вы хотите, чтобы задачи выполнялись быстро, вы должны сделать их как можно более конкретными. Добавление расплывчатых ворот качества не поможет вашей производительности.
Re: невозможно записать правила!
Это не так уж сложно. Вы действительно имеете в виду «я не могу выразить то, что имею в виду под« хорошим »кодом» . Как только вы это поймете, вы увидите, что это, очевидно, проблема с кадрами, если вы начнете говорить, что чья-то работа не на пустом месте, но вы не можете сказать почему.
Запишите правила, которые вы можете, и обсудите с пивом, что делает код «хорошим».
источник