Чтобы расширить ответ rvanider, выполнение цикломатического анализа сложности кода сделало чудеса, чтобы привлечь внимание к большой проблеме метода; когда я ушел, работа над тем, чтобы заставить людей меняться, все еще находилась в процессе разработки (слишком много движений в сторону больших методов).
Переломным моментом стало то, что мы начали связывать цикломатическую сложность с базой данных ошибок. CC более 20, который не был заводским, гарантированно имел несколько записей в базе данных ошибок, и часто эти ошибки имели «родословную» (исправление ошибки A вызвало ошибку B; исправление ошибки B вызвало ошибку C; и т. Д.). На самом деле у нас было три CC более 100 (максимум 275), и эти методы составляли 40% случаев в нашей базе данных ошибок - «вы знаете, может быть, функция с 5000 строками не такая хорошая идея ...»
Это было более очевидно в проекте, которым я руководил, когда начинал там. Цель состояла в том, чтобы сохранить CC как можно ниже (97% были моложе 10 лет), и конечным результатом был продукт, который я в основном перестал поддерживать, потому что 20 ошибок, которые я не стоил, исправлять
Безошибочного программного обеспечения не произойдет из-за коротких методов (и это может быть аргумент, который вам придется учитывать), но исправления ошибок выполняются очень быстро и часто не имеют побочных эффектов, когда вы работаете короткими и лаконичными методами.
Хотя написание модульных тестов, вероятно, излечит их от длительных методов, ваша компания, вероятно, не использует модульные тесты. Риторика заходит так далеко и редко работает на разработчиков, которые застряли на своем пути; покажите им цифры о том, как эти методы создают больше работы и программного обеспечения с ошибками.