Hacker News 의견

• 어떤 사람들은 특정한 것에 대해 매우 교조적일 수 있음. 이런 것들을 복음처럼 받아들이는 이유를 이해할 수 없음

  • 80자 라인 제한을 넘길 때마다 화를 내는 사람들을 상대해야 했던 경험이 있음
  • 프로그래밍 스타일, 패턴, 관용구뿐만 아니라 기술 스택과 솔루션 아키텍처에서도 이런 경향이 더 심함
  • 책이나 블로그에서 읽은 내용을 그대로 인용하는 사람들과의 대화는 매우 답답함
  • NoSQL과 마이크로서비스 열풍 때 특히 심했으며, PAAS/SAAS와 컨테이너화에서도 여전히 느껴짐
  • 기본적인 기능을 수행하는 앱이나 람다, 변환 작업이 유지보수 부담만 늘리고 가치가 없음
  • 책이나 블로그를 쓴 사람과 나의 차이는 그들이 글을 썼다는 것뿐임. 그들의 의견이 사실이 아님을 항상 염두에 두어야 함

• Uncle Bob의 추천을 맹목적으로 따르는 프로젝트를 경험하면 그 가치가 얼마나 낮은지 알 수 있음

  • 소프트웨어 엔지니어링을 개선하려는 시도에 대해 몇 가지 텍스트를 생성했지만, 끔찍한 조언으로 가득 차 있음
  • 그의 성공은 가이드를 찾는 주니어 개발자들의 끝없는 필요에 의해 이루어짐
  • 많은 간접성을 가진 코드가 작업하기 어려운 상태로 만들어짐

• Clean Code는 좋은 소프트웨어 엔지니어의 도구 상자 중 하나임

• 몇몇 사람들은 함수가 재사용되거나 논리적으로 의미가 있을 때 분리하는 대신 단순히 가까이 있는 줄을 묶어 "리팩터링" 함

  • 대학 시절 Clean Code를 읽었을 때, Uncle Bob의 일반적인 분위기를 느꼈음
  • 함수가 X 줄이어야 한다는 사고방식에서 비롯된 것 같음
  • 현대 IDE의 인라인 기능에 감사하며 코드를 이해하기 위해 재구성함

• 주석의 중요성에 대해 언급하지 않은 중요한 사례가 있음

  • USB 장치 드라이버 소프트웨어를 작성할 때, 장치를 잘못된 상태로 만들기 쉬움
  • 해결 방법을 구현할 때마다 주석을 추가하여 문서화함
  • 주석 없이 다른 사람이 코드의 의도를 이해하기 어려움

• "A Philosophy of Software Design"을 강력히 추천함

  • 추상화의 품질을 복잡성의 비율로 측정하는 것이 핵심임
  • 다른 프로그래밍 조언 책을 읽은 후 코드가 더 나아지지 않았음

• Clean Code 운동 이전에 소프트웨어 산업의 실제 문제에 대한 반응이었음

  • Clean Code는 더 나은 방향으로 나아갔지만 과도하게 수정됨
  • 사람들이 다시 거대한 메서드와 깊게 중첩된 조건문으로 돌아갈지 알 수 없음

• Bob의 주석에 대한 의견은 이상함

  • 잘못된 주석에 대한 편집증은 터무니없음
  • 명확하지 않은 코드로 인해 낭비한 시간이 많음
  • 이상한 그림을 만드는 대신 알고리즘을 간단히 설명하거나 링크를 제공하는 것이 더 쉬울 것임

• Uncle Bob의 책은 시간이 지나면 벗어나게 됨

  • Clean Code의 가이드를 따르면서 "과도한 분해"에 대해 배움
  • 작은 함수들이 결국 아무것도 하지 않게 됨
  • 좋은 코드를 쓰고 싶다면 좋은 코드를 읽고, 자신에게 맞는 취향을 개발해야 함

• Clean Code의 이름에 대한 불만이 있음

  • 코드의 청결함을 객관적으로 측정할 수 없음
  • "깨끗한 코드"를 쓰는 것이 당연히 좋은 것이라는 무의식적인 요소가 문제를 일으킴
  • "Uncle Bob"의 기반은 처음부터 부패했음