GN⁺: 안녕, 클린 코드(2020)

코드 정리 작별 인사

• 동료가 일주일 내내 작성한 코드를 저녁 늦게 체크인함.
• 그래픽 편집기 캔버스에서 모양의 크기를 조절하는 기능 구현.
• 코드는 작동했지만 반복적이었음.

다음 날 아침...

• 상사가 개인적으로 대화를 요청하여 코드 변경을 되돌리라고 요청함.
• 처음에는 충격을 받았지만, 결국 상사의 결정이 옳았음을 깨달음.

단계

• "깨끗한 코드"에 집착하고 중복 제거에 몰두하는 것은 많은 개발자가 겪는 단계임.
• 코드에 자신이 없을 때, 측정 가능한 것에 자신의 자존감과 전문적인 자부심을 연결하는 것이 유혹적임.
• 추상화를 배우고 나면 반복되는 코드를 볼 때마다 추상화를 사용하고 싶어짐.

GN⁺의 의견

• 중요한 것은 코드의 "깨끗함"을 추구하는 것이 목표가 아니라, 복잡한 시스템을 다루는 과정에서 일종의 방어 메커니즘이라는 점임.
• "깨끗한 코드"는 개발자가 미지의 영역에서 길잡이 역할을 할 수 있도록 도와주지만, 그것에만 집착하지 않고 놓아줄 줄 알아야 함.
• 이 글은 개발자들에게 코드를 작성하고 유지보수하는 과정에서 협업과 실용성의 중요성을 일깨워주는 흥미로운 관점을 제공함.

[neo]

Hacker News 의견

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 나쁜 추상화에 대한 설명

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

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

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