Как определить приоритет и серьезность «улучшения кода»?

15

У нас есть поля "приоритет" и "серьезность" в нашей системе отслеживания ошибок. Мы определяем серьезность как «как это влияет на пользователя» и приоритет как «как это влияет на продукт».

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

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

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

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

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

Седат Капаноглу
источник

Ответы:

16

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

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

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

maple_shaft
источник
4
+1, как только вы видите улучшение кода как отдельную задачу, вы получаете дрянной код, потому что он всегда имеет низкий приоритет. Только не считайте другие задачи выполненными, если качество кода не соответствует требованиям стандарта компании. Выполнение проверки кода здесь обязательно.
Deadalnix
1
@deadalnix Отличный отзыв об обзорах кода. Если они сделаны с самого начала, то качество кода теоретически поддерживается по умолчанию. С сохранением устаревших приложений, хотя это не всегда так, и улучшение кода должно решаться на ходу.
maple_shaft
2
С устаревшим кодом лучший способ по-прежнему заключать его в чистый интерфейс, чтобы не распространять дерьмо по всей базе кода. Затем проводится массовое тестирование модулей, поэтому мы уверены, что можем положиться на него и, в случае необходимости, прикоснуться к унаследованному коду без свертывания всего проекта.
Deadalnix
1
+1 Особенно для «Если моя задача заключается в том, чтобы я прикоснулся к классу или к некоторому исходному коду, который давно не просматривался». Вы должны только улучшить код, который должен быть изменен. Если это не обязательно должно быть изменено, оставьте это в покое.
MarkJ
1
Для особенно крупных проектов и команд все еще имеет смысл сохранить улучшение кода как отдельную задачу - пока только один разработчик может работать над новой функцией. Обычно я резервирую 2-3 недели в год, чтобы моя команда внедряла улучшения и рефакторинг (на практике это длится дольше, поскольку, как правило, только часть группы может быть отключена в любой момент времени)
blueberryfields
2

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

Вы также можете ввести новую категорию в свою систему отслеживания ошибок, чтобы классифицировать такие задачи как задачи «Рефакторинг». Таким образом, вы будете знать, как интерпретировать значение приоритета; то есть более высокий приоритет означает большее влияние и, следовательно, требуется больше испытаний.

Бернард
источник
2
Чтобы добавить к этому, технический долг (из-за отсутствия рефакторинга) действительно влияет на продукт, потому что его становится все труднее обслуживать и вносит большую вероятность ошибок. Как только продукт подвергается воздействию, пользователь подвергается воздействию ... В нашей команде есть задачи «Улучшения», которые мы используем для рефакторинга и улучшения процессов / инструментов
Atif
2

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

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

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

JeffO
источник
1

Интересный вопрос.

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

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

Затем установите пороговые значения для этих уровней соответствия приоритету и серьезности.

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

Ozz
источник
1

Давайте начнем с двух предположений здесь.

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

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

Майкл Браун
источник
1

Я бы украл голосование у Agile движения:

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

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

Майкл Даррант
источник