Схватка и рефакторинг

Ответ 1

Я не думаю, что это имеет такое же отношение к Scrum, как и к философии управления проектами.

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

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

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

Ответ 2

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

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

Ответ 3

Я думаю, вы, вероятно, говорите о масштабном рефакторинге, а не о непрерывном рефакторинге, которое вы делали бы во время всего цикла red-green-refactor.

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

Ответ 4

Если все в Scrum связано с функциональными вещами, которые пользователь может видеть (...)

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

Ответ 5

bta: Независимо от того, использует ли проект Scrum или нет, многие руководители проектов не любят, когда разработчики тратят время на "ненужные" вещи, такие как рефакторинг или реструктуризация кода, которые не направлены непосредственно на один из выдающиеся функциональные требования.

Определенно заслуживающее внимания наблюдение; мое решение для этого было бы следующим:

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

Если ваш менеджер нуждается в более убедительном, бросил "поддерживающий" в качестве пользователя и описал некоторые истории пользователей для них, а затем "функции" - это такие вещи, как "код полностью комментируется комментариями xml doc" и " код не вызывает никаких предупреждений от ReSharper '

Ответ 6

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