😀 책에서 기억하고 싶은 내용을 써보세요.

  • 함수나 변수로 표현할 수 있다면 주석을 달지 마라
    => 함수나 변수에 정보를 담자는 것에 한 단계 더 세밀한 내용이라고 생각합니다.
    => 함수나 변수에 뚜렷한 정보를 담았다면 주석을 추가할 필요가 없다.
  • 공로를 돌리거나 저자를 표시하는 주석(Bad case)
    => 코드를 작성한 사람의 이름을 작성하는 것
    => 예전에 한번 사용해볼까도 했던 부분인데 생각해보면 시간이 지나면 거짓된 정보가 될 수 있다.
    => 리팩터링을 꾸준히 거치고 다양한 사람의 손에 의해 수정된다면 저자는 필요 없을 것 같다.
    => 차라리 이런 정보는 주석이 아니라 블로그에 처음 작성했던 코드를 같이 작성하면 어떨까 싶다.
  • 전역 정보와 너무 많은 정보
    => 주석을 달아야 한다면 근처에 있는 코드만 기술하라.
    => 시스템의 전반적인 정보를 기술하지 마라
    => 주석에다 흥미로운 역사나 관련 없는 정보를 장황하게 늘어놓지 마라

 

 

 

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

  1. 주석이 소중한 정보가 될 수도 있지만, 쓸모없는 잡음 혹은 거짓된 정보가 될 가능성이 높다.
    => 위치를 표시하는 주석, 닫는 괄호에 다는 주석, 의미없이 다는 주석 등등
  2. 코드에 자신이 없어서 주석으로 설명을 보충하기 위해 작성 했던 경우가 많았습니다.
    => 어떤 주석을 추가해야 할까 라는 고민보다는 코드에 어떻게 정보를 담을까를 고민해야겠습니다.
    => 예제 코드를 보면서 제가 작성했던 코드와 비슷한게 꽤 많았습니다.
    클린 코드를 보면서 해당 코드를 리팩터링 하면 재미있을 것 같습니다.

 

 

 

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

  • 주석을 다는 것도 팀원들과 맞춰야 된다는 걸 알게 되었습니다.
    그런데 어떻게 정해야 할까 고민이 됩니다.
    => 아무래도 주석까지 팀원들과 맞춘다고는 생각을 안 할 것 같기도 합니다.
    => 현업에서는 주석까지 맞추는지 궁금합니다.
    => 저자가 작성한 마지막 예시를 보면 주석도 각 프로그래머마다 생각하는 것들이 다르다는 것을 느꼈습니다.

 

 

 

👀 소감 3줄 요약

  • 함수와 변수에 정보를 담고 주석은 줄이자.
  • 주석은 내가 작성한 코드에 자신이 없을 때 추가하는 경우가 많다.
  • 우선 지울 주석부터 생각하자.

 

 

반응형

+ Recent posts