Это хорошая идея запланировать регулярное время для очистки кода? [закрыто]

42

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

Было бы неплохо запланировать регулярное время, скажем, 1 неделю каждые 2 месяца, чтобы просто очистить нашу кодовую базу?

user84667
источник
9
Я бы предпочел сначала начать регистрировать все вещи, требующие очистки, в инструменте отслеживания проблем . Анализ проблем, зарегистрированных в трекере, может дать лучшую (намного лучшую) идею о том, какой подход будет наиболее подходящим для конкретного проекта
gnat
4
Было бы лучше запланировать регулярное время для проверки кода
l46kok
1
Что вы имеете в виду, когда говорите «очистить»? Это предварительное кодирование или обработка всех тегов FIXME и TODO, или повышение производительности за счет быстрого написания кода? Или что-то другое? Любой из них может быть классифицирован как очистка, но я бы назначил разные приоритеты для каждого из них.
Пол
Еще один "закрытый как слишком популярный", а, ребята?
MGOwen

Ответы:

100

Нет.

Исправьте это, пока вы работаете над этим:

  • Если вы будете ждать рефакторинга части, над которой вы работаете, вы многое об этом забудете, и вам придется потратить время, чтобы снова ознакомиться с ней.
  • Вы не получите «позолоченный» код, который никогда не будет использоваться, потому что требования изменились
MGOwen
источник
2
Мои деньги на этот ответ ..
Soner Gönül
2
+1 за отличный ответ. Вы не получите «позолоченный» код, который никогда не будет использоваться, потому что требования изменились
Md Mahbubur Rahman
8
На идеальном проекте с идеальным менеджментом и командой одинаково великих разработчиков этот ответ будет верным. К сожалению, я никогда не видел и не слышал о таком проекте за десять лет работы в отрасли.
Бен
3
Попробуйте сделать это, но когда вы не можете (и это произойдет из-за нехватки времени или потому, что вы просто пока не знаете, как это сделать правильно), создайте заявку в своей системе заявок. Таким образом, вы можете надеяться вернуться к нему, пока проблема еще свежа в вашем уме, а не только тогда, когда она в конечном итоге начинает вызывать проблемы.
Сариен
1
Я думаю, что это хороший совет, но не отвечает на заданный вопрос. Haivng руководил командой с ужасной кодовой базой (до того, как я туда попал, было ужасно). Это было очень хорошо потраченное время, чтобы заняться рефакторингом и очисткой определенных функций. Мы назвали их инфраструктурными проектами и проработали их в каждом спринте. Часто эти вещи были элементами, которые не были частью другого изменения, но были вещами, которые команда определила как проблемные области. Мы делали квартальные ретроспективы и будем регулярно обновлять этот список.
Билл Липер
21

Мое личное мнение: это абсолютно необходимо для 90% проектов.

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

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

Обычно существует два типа проблем, возникающих таким образом:

  • Небольшие, которые могут быть легко исправлены, но могут быть системными, например, с неправильно названными параметрами, неполной обработкой ошибок и т. Д. Они, как правило, будут иметь небольшое влияние вне блока кода, где они появляются. Лучший способ справиться с этим - это проверка кода и проверка кода во время его написания / изменения. Как уже говорили другие, нет необходимости выделять специальный цикл рефакторинга для исправления этих ошибок.
  • Большие, которые могли возникнуть из-за неполных спецификаций или плохих дизайнерских решений на ранних стадиях, или две разработчики / команды, создающие два разных решения одной и той же проблемы. Как правило, их гораздо сложнее исправить, и для их устранения требуются согласованные усилия. В результате они обычно откладываются до тех пор, пока не станут вечными неприятностями. Проблемы такого рода требуют отдельного периода времени для устранения.

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

PSWG
источник
1
Я не понимаю, что увеличение количества больших толчков является гибкой проблемой.
Джефф
2
@JeffO Нет, это не проворная проблема. Это проблема управления. Однако из того, что я видел, компании, которые находятся под сильным влиянием продаж, стремятся к агрессивным циклам выпуска и большим наборам функций. Гибкие стратегии имеют тенденцию привлекать эти компании (независимо от того, действительно ли они следуют этим стратегиям или нет). Хотя мне нравится гибкая разработка, мой опыт показывает, что когда компания называет себя «гибкой», это обычно означает, что я могу ожидать, что в кодовой базе будет значительная техническая задолженность.
PSWG
Я думаю, что если у них нет методологии, они могут называть себя как хотят. Так как Agile, является текущим модным словом, это наиболее привлекательным. Это было некоторое время, так как я был на проекте водопада; это была такая катастрофа во многих других отношениях, что я никогда не использовал ее в качестве аргумента против методологии.
Джефф
В любом проекте, гибком или нет, рефакторинг и очистка кода - это то, что вы делаете на ходу, чтобы постоянно сводить технические долги к минимуму. Если вы не учитываете это в своих оценках, вам придется начать это делать. Вы не можете позволить техническому долгу накапливаться до тех пор, пока вам не понадобится остановить все, чтобы это исправить. Вместо этого следуйте правилу разведки: «Всегда оставляйте код чище, чем вы его нашли».
Кристофер Хаммарстрем
По моему опыту, неопытные команды, начинающие с scrum, без соблюдения хороших принципов кодирования (например, XP), иногда могут быть слишком сосредоточены на функциональности (истории). Вместо этого они должны сказать, что история не закончена, пока код не станет «достаточно хорошим», но не у всех есть достаточно основы, чтобы сделать это в приближающемся сроке. А с Agile у вас, как правило, больше сроков в более короткие сроки, поэтому я связываю это и с Agile-методами, тогда как я прекрасно понимаю, что они не являются причиной.
markijbema
11

Мои разработчики убирают свой код перед регистрацией (Subversion) или слиянием с основной веткой разработки (Git).

У меня они делают следующее:

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

Для более крупных проектов код проверяется формально до слияния из ветви разработки в основную ветку.

Я думаю, что «выделение времени» будет означать, что оно может быть отложено или отложено из-за большого объема работы. Благодаря тому, что разработчики делают это на каждой регистрации (что равняется запросу / проблеме изменения в JIRA), это намного более управляемо.

Сэм
источник
Просто из любопытства: почему вы используете два разных VCS?
Eekhoorn
2
Была / проходит фаза миграции. Сейчас мы перенесли большинство SVN-репозиториев, я упомянул оба для некоторого контекста.
Сэм
Это то, что я делаю. Очистите код перед проверкой и проведите рефакторинг, если я вернусь к коду для улучшения функциональности.
Barfieldmv
1
Это не решит эти острые проблемы, которые скрываются в тех областях, которые могут не входить в запрос функций от команды разработчиков продукта.
Билл Липер
9

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

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

Telastyn
источник
Ваше второе предложение противоречит первому. Вы сказали нет, но потом сказали, что работаете с такими вещами в каждом спринте. Таким образом, это планирование времени, чтобы сделать это.
Билл Липер
2
@BillLeeper - расширение Когда я слышу «обычное время», это означает, что есть некоторый регулярный интервал для выполнения работы по очистке. ИМО, это неправильно - все время подходящее время для уборки.
Теластин
1
Хороший вопрос, я согласен, что обычное время не работает хорошо. Слишком часто приоритеты вызывают его отмену и т. Д.
Билл Липер
4

Я бы определенно сказал «да» с оговоркой: это следует делать часто, желательно еженедельно. Я считаю, что запланированный регулярный обзор кода в сочетании с фактическим воздействием на элементы, выходящие из обзора кода, окупается очень быстро. Смотрите ответ PSWG

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

Мауриц Хансен
источник
Мы делаем «Технический долг вторник» для этого. Его половина пути привела к тому, что израильская рабочая неделя позволила нам сделать шаг назад, чтобы разобраться с проблемами
Захари К
1

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

Вы не должны использовать это как оправдание, чтобы не делать правильные вещи [применение принципов SOLID, соответствующих модульных тестов, проверок и т. Д.] В первую очередь.

Джаян
источник
1

Я думаю, что в настоящее время два популярных ответа «Нет», «Да» являются двумя аспектами одной и той же истины. Помните, что ОП говорит о группе, которой он управляет, а не только о себе как о личности. Мы не можем предполагать, что все разработчики в группе достаточно дисциплинированы, чтобы писать чистый, легко читаемый код; и есть проблема внешнего давления и методологий гибкого стиля. Кроме того, даже несмотря на все усилия людей, их различия в стиле будут означать, что они могут писать код, который будет считаться чистым, когда он отделен, но нечистым, когда рассматривается вместе с другими людьми (не говоря уже о скрипучих интерфейсах).

С другой стороны, «исправить это, работая над этим», на мой взгляд, идеал, к которому нужно стремиться. Вы можете сделать свой код еще более "исправленным"

  • осторожный сверстник CRing
  • написание модульных тестов вместе с самим кодом
  • принятие руководящих принципов кодирования
  • используя автоматические форматеры и линтеры (но YMMV)
  • и т.п.

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

einpoklum - восстановить Монику
источник
1

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

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

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

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

Билл Липер
источник
1

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

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

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

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

В конце концов, вам не нужно устанавливать время.

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

JeffO
источник
-1

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

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

Рикардо Могг
источник
Это называется рефакторингом, используете ли вы TDD или нет. Этот вопрос не имеет ничего общего с TDD ...
Бен Ли