Не нужно обрушивать на начальника всю собранную информацию. Для начала поинтересуйтесь его мнением. Это может быть простой вопрос: «Я думал о том, как X влияет на способность делать Y, и хотел бы знать, что вы думаете по этому поводу». Предоставляя возможность откровенно высказаться, вы показываете, как важно для вас мнение руководства.
Организации не любят признавать, что сотрудники уходят из-за качества кода и принятых практик разработки, но это происходит сплошь и рядом. Если удастся собрать информацию о причинах ухода людей из команды и показать, что это связано со сложностью кода, это может стать невероятно убедительным аргументом в пользу выделения ресурсов на рефакторинг.
Рефакторинг — совсем другое дело. Какие бы усилия ни прилагались к улучшению существующей реализации, нужна гарантия неизменности ее поведения. Уверенно утверждать, что новое решение работает как старое, можно только тогда, когда оно успешно проходит весь набор тестов исходной реализации. Для предупреждения возможных регрессий перед началом рефакторинга важно проверить две вещи. Убедиться, во-первых, в том, что исходная реализация имеет тестовое покрытие, во-вторых, в полноте и адекватности этого покрытия.
Метрики покрытия кода При разработке нового функционала есть разные подходы к тестированию. Например, при разработке через тестирование (test-driven development, TDD) сначала пишется полный набор тестов, а после реализация функционала повторяется, пока тесты не будут пройдены.
NPath-сложность В 1988 году Брайан Неджми предложил NPath-сложность — альтернативу существующим метрикам. По его утверждению, фокусировка внимания на ациклических путях выполнения не позволяет адекватно смоделировать соотношение между конечными подмножествами и множеством всех возможных путей.
Цикломатическая сложность Предложенная в 1976 году Томасом Маккейбом цикломатическая сложность — количество линейно независимых маршрутов через программный код.
