Clean Code - 2

주석

주석은 개발자에게 있어서 '피할 수 있으면 피하고 싶은 존재'입니다. 앞서 적은 글에서 코드는 그 의도가 분명하게 드러나 있고, 다른 사람들도  파악하기 쉬워야 한다고 정리했는데, 주석은 이에 실패했을 경우를 위해 달아 놓은 부가 설명이기 때문입니다. 코드 자체만으로 완벽한 문서가 되는 것이 가장 이상적인 형태라는 것을 모두가 알고 있지만 결코 쉬운 일이 아닌 것입니다. 밥 아저씨도 주석을 '필요악'이라고 칭하고 있습니다.

물론 주석을 잘 쓰면 코드를 파악하는데 큰 도움이 되지만 정말 중요한 것은 코드이지, 주석이 아니기에 짧게 정리하고 넘어가겠습니다.

 

주석은 나쁜 코드를 보완하지 못한다.

주석을 어떻게 남겨야 하는지 앞서 필요한 전재입니다.

 

좋은 주석

• 법적인 고지를 위한 주석 (ex: Copyright)
• 정의 만으론 들어내기 어려운 정보나 의도를 설명하는 주석
• 결과를 경고하는 주석
• TODO 주석
• 중요성을 강조하는 주석

Docs

• 함수나 클래스의 스펙을 Docs 형태로 제공하기 위해 주석을 적는 경우가 있습니다. 이는 공개 API가 아닌 경우(불필요한 경우)는 지양하는 게 좋아 보입니다.

 나쁜 주석

• 그 외

 

Convention(형식 맞추기)

여러 개발자들이 함께 일하다 보면 일관된 convention의 필요성을 느끼게 되는 경우가 많은 것 같습니다. 프로젝트의 전체적인 구조뿐만 아니라 클래스 하나를 만들더라도 변수나 함수의 위치 같은 아주 사소한 것들이 코드를 읽는데 불편하게 만드는 경우를 보면 말이지요. 사실 convention은 조직마다 다르기 때문에 이런 convention이 무조건 좋다고 말하기 어려운 부분인 것 같습니다. 마음에 들지 않은 convention이 있다고 하더라도 이를 수정하기 전까진 거기에 따라줘야겠지요.

 

 

객체와 자료 구조

이 챕터에선 객체와 자료 구조의 차이에 대해 이야기하고, 각각을 어떻게 사용해야 하는지에 대해 설명합니다.

 

객체

객체는 동작을 공개하고 자료를 숨겨야 합니다. 따라서 기존 동작을 수정하지 않으면서 새 타입을 추가하는 것은 쉽지만, 기존 객체에 동작을 추가하는 것은 어려워집니다.

객체 안에 몇 가지 state나 property가 있을 수 있지만 이를 private으로 애써 감추면서 getter setter를 public 하게 들어내 놓는 것은 바보 같은 행동일 것입니다. 밥 아저씨는 객체 안의 자료는 완전하게 숨기고 동작들만을 들어냄으로써 자료가 어떻게 바뀌고 사용되는지에 대한 구체 사항은 철저히 숨기라고 이야기합니다.

 

자료구조

자료구조는 객체와 반대로 자료를 그대로 노출합니다. 따라서 새로운 동작을 추가하는 것은 쉽지만 기존의 동작에 새로운 자료 구조를 추가하는 것은 어렵습니다.

 

 

오류 처리

오류코드 보다 예외를 사용하라

특정 로직 안에서 예외의 상황이 발생하였을 때 우리는 보통 if else 등의 분기를 통해 예외상황들을 처리하곤 합니다. 하지만 이렇게 되면 여러 분기들이 꼬리에 꼬리를 물고, 수많은 코드 블록들이 생기면서 코드는 점점 복잡해져 갑니다. 하지만 예외를 던지는 식으로 코드를 짠다면 코드가 보기 편해질 뿐 아니라 로직과 예외처리를 분리할 수 있게 됩니다.

 

미확인 예외를 사용하라

확인된 예외를 사용하는 경우 하위 함수의 확인된 예외 하나로 인해 모든 상위 함수의 수정이 필요하게 됩니다. 따라서 확인된 예외는 OCP를 위반합니다.

 

예외에 의미를 제공하라

콜 스택 만으로는 부족한 경우가 많으므로 단순히 예외만이 아닌 실패의 유형이나 연산 이름 같은 정보를 함께 던지는 것이 좋습니다.