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

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

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

Нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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