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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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