Чи справді «Чистий код» дійсно такий чистий і корисний? [зачинено]

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

За останні кілька місяців я помітив цю релігійну прихильність до Clean Codeпрактик, і книга була як біблія для розробників.

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

Я розумію, що цей чистий код - це довгострокова інвестиція, яка полегшить наступне обслуговування та вдосконалення коду, але ... чи справді варто цього суєти?

Чи хтось поділиться своїм досвідом роботи щодо чистого кодексу та будь-якої думки, чи я занадто консервативний, чи це лише тимчасова тенденція.

Я розумію, що цей чистий код - це довгострокова інвестиція, яка полегшить наступне обслуговування та вдосконалення коду, але ... чи справді варто цього суєти?

Абсолютно.

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

Звичайно, але врахуйте, що велика компанія, ймовірно, має чисті роки чи десятиліття поганого коду. На це піде багато часу і сил.

Головне усвідомити, що ви обоє праві. "чистий код" дуже важливий, а "Чистий код" - це загальновизнаний спосіб потрапити туди. Оскільки компанія тільки починала цей шлях, вони будуть сприйматися до книги більше, ніж група, яка має більше досвіду. Як тільки вони це зроблять ненадовго, вони почнуть вивчати, що працює, а що ні. Як тільки вони зрозуміють це краще, вони (сподіваємось) дотримуватимуться більш прагматичного та природного підходу, який підтримує чистий код, але не призводить до 70 найменувань функцій char.

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

Мені завжди не подобалися правила без коментарів , оскільки є випадки, коли коментарі необхідні для запобігання майбутнього злому коду. Зазвичай їх слід обмежувати тим, що робиться і чому. Економно використовуйте їх, коли код робить щось несподіване або потрібно замінити алгоритм.

Подумайте про продуктивність під час читання або підтримки коду. Протягом життя коду це може бути важливіше, ніж продуктивність при написанні коду. Чи допоможуть ці практики підвищити продуктивність у виконанні цих завдань?

Із досвідом ці практики повинні стати вкоріненими, а меншою мірою - вбивцями. Вибір правильного імені може зайняти більше часу, оскільки ви роз'яснюєте, що потрібно робити з коду. (Це уточнення може пришвидшити кодування та налагодження.) Чи призводить це до коду, який виконує лише те, що потрібно, або має менше помилок? Який вплив це на продуктивність?

Час, відведений на вибір правильної назви методу, швидше за все, окупиться, щоб краще зрозуміти, яка мета методу. Порівняйте назви методів "iterateOverCustomers" з "locateActiveCustomers". Який з них передає наміри функції? Який із них буде легше переробляти за потреби?