Действительно ли практики «чистого кода» настолько чисты и полезны? [закрыто]

В настоящее время я прохожу стажировку в крупной корпорации, и они претерпевают много изменений в структуре поставки программного обеспечения (переход на Agile).

В последние пару месяцев я заметил эту религиозную привязанность к Clean Codeпрактикам и то, что книга для разработчиков напоминает библию.

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

Я понимаю, что этот чистый код - это долгосрочное вложение, которое облегчит последующее сопровождение и совершенствование кода, но ... действительно ли это стоит всей этой суеты?

Кто-нибудь поделится своим опытом в отношении Чистого кода и любым мнением, слишком ли я консервативен или это просто временная тенденция?

Я понимаю, что этот чистый код - это долгосрочное вложение, которое облегчит последующее сопровождение и совершенствование кода, но ... действительно ли это стоит всей этой суеты?

Абсолютно.

Рефакторинг очень важен, но тратить 75% своего времени на перемещение методов и тратить кучу времени на выбор правильного названия не кажется таким продуктивным.

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

Главное понять, что вы оба правы. «Чистый код» очень важен, и Чистый код - это универсальный способ добиться этого. Так как компания только начала идти по пути, она будет признательна книге больше, чем группа, которая имеет больше опыта. Как только они это сделают, они начнут изучать, что работает, а что нет. Как только они поймут это лучше, они (надеюсь) последуют более прагматичному и естественному подходу, который поддерживает чистый код, но не приводит к 70 именам функций char.

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

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

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

С опытом, эти методы должны стать укоренившимися, а не убийцей производительности. Выбор правильного имени может занять больше времени, потому что вы разъясняете, что должен делать код. (Это уточнение может ускорить кодирование и отладку.) В результате получается код, который выполняет только то, что требуется, или содержит меньше ошибок? Как это влияет на производительность?

Время, выбранное для выбора правильного имени метода, скорее всего, сразу окупится, чтобы лучше понять, какова цель метода. Сравните имена методов "iterateOverCustomers" с "locateActiveCustomers". Какой из них передает цель функции? Какой из них будет легче реорганизовать в случае необходимости?