240201 TIL ; DAY04

범위

• 4장. 주석

💡 전반적으로 저자와 취향이 약간 안 맞았던 장. 당장 첫 문장부터가 “나쁜 코드에 주석을 달지 마라. 새로 짜라”. 실무에서는 정말이지 허무맹랑한 소리다. 주석이 기껏해야 필요악이라니… 좋은 주석이라고 보여준 예도 몇 개는 이해가 안 갔다… 백엔드 API를 만들면서 어쩔 수 없이 클라이언트 (특히 구버전의 클라이언트) 와 결합도가 심해질 때가 있다. 이럴 땐 분명하게 주석으로 설명이 필요하다. 우리의 인생이 불공평한 것처럼 프로그래밍의 현실도 불합리하니까. 패배주의처럼 보인대도 각자의 개성과 취향과 어쩌면 무지가 난무하는 현실에 유토피아는 없다. 책의 저자는 엄청난 경력과 지식을 자랑하는 프로그래머이다. 그에 비해 한낱 부품과도 같은 나같은 개발자가 그의 비범한 논리를 따라갈 수 없는 것일지도… 클린 아키텍처 볼 때도 이 생각함….

몇 가지 동의하는 바

• 코드로 의도 표현하기

  // 직원에게 복지 혜택을 받을 자격이 있는지 검사한다.
  if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))
  
  ->
  
  if (employee.isEligibleForFullBenefits())
  

  주석을 대신하여 메소드명으로 의도를 표현한다는게 가능한 것이구나 생각했다.

  다만…. 위 코드에서는 아마도 엔티티에 다양한 유틸성 메소드들이 구현될 것 같은데 그것은 다소 취향이 아니고…. 그렇다고 무한대 private 메소드도 내 취향이 아니라서…. 그래도 요새는 후자로 메소드를 쪼개보려고 더 노력하는 중이다.
  

• 오해할 여지가 있는 주석

  • 이거는 예제의 주석을 보고 찔렸던게 나같아도 주석을 달아야한다면 그렇게 달았을 것 같아서….

  • 근데 그렇다면 저자가 생각하는 이상적인 해결방법은 무엇이었을까? 알려주지 않음….

나의 최애 북틸

• https://nomadcoders.co/community/thread/9206 ; manhduck 님

• https://nomadcoders.co/community/thread/9190 ; h1335님