저는 현재 대기업에서 인턴십을하고 있으며 소프트웨어 제공 구조에 많은 변화가 있습니다 (Agile로 이동).
지난 몇 달 동안 나는 Clean Code관습에 대한 이 종교적 애착과이 책 이 개발자들을위한 성경과 같은 것으로 나타났습니다 .
이제 깨끗한 코드의 가장 중요한 기능 중 하나는 이해하기 쉬운 이름 지정 및 엄격한 리팩토링을 기반으로하는 자체 설명 코드입니다. 그 뒤에 no commenting규칙 이 따릅니다 .
이 깨끗한 코드는 장기적인 투자로 코드 유지 관리 및 개선을 쉽게 수행 할 수 있지만 ...
Clean Code에 대한 경험과 내가 너무 보수적이거나 일시적인 추세인지에 대한 의견을 공유하겠습니까?
1
많은 좋은 질문은 전문가 경험을 바탕으로 어느 정도의 의견을 생성하지만이 질문에 대한 답변은 사실, 참조 또는 특정 전문 지식이 아닌 의견에 거의 근거한 경향이 있습니다.
—
gnat
나는 그 책에 대해 매우 높은 의견을 가지고 있지 않습니다 (저자에도 불구하고). 일반적으로 너무 독단적이지 않습니다. 대부분의 프로그래밍 권장 사항은 실제로 작동하는 것으로 나타 났지만 절대 사실은 아니므로 너무 걱정하지 마십시오. 계속해서 읽고 더 정확한 느낌을 가지고 가십시오. 그러나 바퀴를 재발 명하지 마십시오. 우리보다 더 나은 솔루션을 이미 찾은 것보다 똑똑한 사람 일 가능성이 있습니다.
—
DPM
70 자 이름을 가진 메소드는 아마도 둘 이상의 일을합니다. SRP 위반이 맞습니까?!
—
Tombatron
깨끗한 코드에 관심이 적은 회사의 개발자 인 지금부터 5 년에서 10 년 사이에 또 다른 생각이 있습니다.이 교의적인 연습에 정말 감사하겠습니다.
—
Tombatron
"의견 없음"하에서 (간결하게) 일한 결과, 나는 그것이 규칙보다 강력한 지침 이 되기를 매우 선호한다 . 일반적으로 모호한 비즈니스 논리에서 주석이 필요한 경우가 있습니다. 호출 된 메소드
—
anaximander
CalculateFoonicityMetric()는 정확히 수행중인 작업을 알려주며 잘 작성된 코드는 방법을 보여 주지만 둘 다 왜 그런지 알려주지 않습니다 . 코드는 무엇인지 (이 곱하기, 다른 것으로 나누기, 제곱하기,이 비트 추가하기 ...)에 분명 할 수 있지만 왜 (factor = a * b / c; 음수 foo를 고려하기위한 square, 조정하십시오) 드리프트를 위해 ...). 이유를 설명하는 빠른 의견에 감사드립니다.