Hacker News 의견

• "클린 코드"는 브랜드 개선이 필요함

  • 클린 코드의 목적은 코드를 더 단순하고 유지보수하기 쉽게 만드는 것
  • 소프트웨어의 가치는 시간이 지남에 따라 변화할 수 있는 능력에 있음
  • 리팩토링이 유지보수를 더 어렵게 만들었다면 그것은 클린 코드가 아님
  • 원 개발자와 리팩토링에 대해 논의하지 않은 것은 클린 코드와는 별개의 문제

• 코드 중복이 때로는 좋을 수 있지만 클린 코드가 나쁘다는 증거는 아님

  • 10줄의 반복되는 수학 계산을 함수로 대체했다면 더 클린해질 수 있음
  • PR을 리뷰하고 기준에 맞지 않으면 거절해야 함
  • 클린 코드의 중요성을 무시하는 태도는 결국 아무도 작업하고 싶어하지 않는 코드베이스로 이어짐
  • 더 나은 커뮤니케이션과 절제가 필요한 교훈

• 동료가 복사 및 붙여넣기로 많은 코드를 작성함

  • 리팩토링은 리뷰를 위해 올라가야 함
  • 상사가 직접 개입하여 되돌리라고 지시하는 것은 나쁜 신호
  • 복사 및 붙여넣기가 함수 작성보다 낫다는 교훈이 아님

• 클린 코드 버전이 더러운 코드를 대체했을 가능성이 높음

  • 팀에서 일하는 방법에 대한 교훈이 필요함

• 코드 변경 시 동료 리뷰가 필요함

  • 좋은 프로세스가 부족한 것을 인식해야 함
  • 코드 리팩토링은 필요할 때만 해야 함

• 금융 분야에서는 유사하지만 다른 제품을 다루는 경우가 많음

  • 과도한 추상화를 피하고 클린 코드를 유지하는 것이 중요함

• Haskell과 같은 언어는 언어 수준에서 추상화를 극대화함

  • 프로젝트별 추상화를 최소화하면서도 학습 비용이 높음

• 반복되는 수학 계산을 별도의 함수로 이동시키는 것이 클린 코드에 해당함

  • 인터페이스 형성으로 보이는 리사이즈 함수들을 리팩토링하는 것은 잘못됨

• 나쁜 추상화에 대한 설명

  • 미래 사용을 충분히 고려하지 않고 설계하는 것이 문제임

• Rob Pike는 "조금의 복사가 조금의 의존성보다 낫다"고 말함

  • DRY 원칙은 때로는 추상화를 추가하지만, 추상화가 충분히 직교하지 않으면 오히려 문제를 악화시킴