В настоящее время я прохожу стажировку в крупной корпорации, и они претерпевают много изменений в структуре поставки программного обеспечения (переход на Agile).
В последние пару месяцев я заметил эту религиозную привязанность к Clean Codeпрактикам и то, что книга для разработчиков напоминает библию.
Теперь одна из самых важных особенностей чистого кода - это не требующий пояснений код, который основан на понятном именовании и строгом ре-факторинге. За этим следует no commentingправило.
Я понимаю, что этот чистый код - это долгосрочное вложение, которое облегчит последующее сопровождение и совершенствование кода, но ... действительно ли это стоит всей этой суеты?
Кто-нибудь поделится своим опытом в отношении Чистого кода и любым мнением, слишком ли я консервативен или это просто временная тенденция?
источник
CalculateFoonicityMetric()говорит вам точно, что он делает, и хорошо написанный код покажет вам, как ... но ни один из них не скажет вам почему . Код может быть очевиден в том, что (умножьте это на это, разделите на другое, возведите в квадрат, добавьте этот бит ...), но неясно, почему (фактор = a * b / c; квадрат для учета отрицательного foo, отрегулируйте для дрифта ...). Я ценю быстрый комментарий, который объясняет почему.Ответы:
Абсолютно.
Конечно, но учтите, что у крупной компании, вероятно, есть годы или десятилетия плохого кода для очистки. Это займет много времени и усилий, чтобы сделать это.
Главное понять, что вы оба правы. «Чистый код» очень важен, и Чистый код - это универсальный способ добиться этого. Так как компания только начала идти по пути, она будет признательна книге больше, чем группа, которая имеет больше опыта. Как только они это сделают, они начнут изучать, что работает, а что нет. Как только они поймут это лучше, они (надеюсь) последуют более прагматичному и естественному подходу, который поддерживает чистый код, но не приводит к 70 именам функций char.
источник
Я изначально писал комментарий. Я постараюсь дать меньше ответа, чем рассмотреть перспективы. Тем не менее, я абсолютно одобряю методы «чистого кода», такие как понятное именование и рефакторинг.
Мне всегда не нравились правила отсутствия комментариев , так как есть случаи, когда комментарии необходимы для предотвращения поломки кода в будущем. Они обычно должны быть ограничены тем, что делается и почему. Используйте их экономно, когда код делает что-то неожиданное, или требуется заменить алгоритм.
Учитывайте производительность, когда вы читаете или поддерживаете код. Во время жизни кода это может быть важнее производительности при написании кода. Помогут ли эти практики повысить производительность в этих задачах?
С опытом, эти методы должны стать укоренившимися, а не убийцей производительности. Выбор правильного имени может занять больше времени, потому что вы разъясняете, что должен делать код. (Это уточнение может ускорить кодирование и отладку.) В результате получается код, который выполняет только то, что требуется, или содержит меньше ошибок? Как это влияет на производительность?
Время, выбранное для выбора правильного имени метода, скорее всего, сразу окупится, чтобы лучше понять, какова цель метода. Сравните имена методов "iterateOverCustomers" с "locateActiveCustomers". Какой из них передает цель функции? Какой из них будет легче реорганизовать в случае необходимости?
источник