Clean Code (2/n)

계속해서 clean code 책을 읽어가면서 코드 철학을 정리해 보았다.

 

4. 주석

저자는 주석을 '필요악'으로 규정하고, 좋은 코드라면 주석을 최소화하고 코드를 통해 내용을 설명해야 한다고 주장한다.

나도 이전에는 주석이 아닌, 코드를 통해서 내용을 설명하려고 했었다.

코드의 변화는 직접적인 영향을 끼쳐 동작을 변화시키므로 실제 프로그램의 동작과 잘 맞아떨어지지만, 주석의 변화는 프로그램에 직접적인 영향을 끼치지 않기 때문에 outdate되기 쉽다. 

하지만 더 많은 코드를 작성하고 다른 사람의 코드를 읽어보면서 주석이 필요한 경우가 있다고 생각한다.

다른 사람이 코드를 보았을 때 명쾌하게 이해되지 않는 부분(도메인의 부족 등)은 주석을 통해 부연설명을 하면 코드 리뷰나 그 기능을 수정할 때 큰 도움이 된다.

주석을 달아야 할 경우와 달지 말아야 할 경우를 정리해 보았다. 

 

Good

• 코드에 대한 정보를 제공하는 주석
• 코드에 대한 주의점을 경고하는 주석
  • 예를 들어, 코드를 실행할 때 반드시 어떤 코드와 같이 실행해야 한다는 것이 있을 수 있다.
  • 다만, 이 경우는 주석 대신 코드로 해결할 수 있는 방법이 없는지 고민해 보아야 한다.
• TODO 주석

Bad

• 코드에 대한 모호한 정보를 제공하는 주석
• 주석으로 처리한 코드 
  • git 등의 버전 관리 시스템에서 확인할 수 있기 때문에 지워도 된다고 저자는 주장한다.
  • 저자의 주장에 크게 공감하면서도 이전 버전의 코드가 필요할 때 버전 관리 시스템을 뒤지는 것도 시간을 많이 소모하는 작업인 것 같아서 어느 정도의 유연함은 필요하지 않을까 생각이 든다. 특히, 자주 변할 가능성이 많은 부분은 말이다.

5. 형식 맞추기

코드 형식 맞추기는 코드의 가독성 면에서 너무도 중요한 개념이다.

이전에는 팀 내에 프로그래머들 사이에서 한 줄에 최대 몇 자의 글자가 들어가고, 들여쓰기는 어떻게 할지 같은 코드 규칙을 직접 맞추어야 했다. 

하지만, 다행히 현대에 프로그래밍을 할 때에는 lint 시스템이 존재해서 미리 정해놓은 규칙에 맞지 않으면 editor에서 빨간 줄을 보여주면서 규칙을 어겼음을 쉽게 알 수 있다.

lint의 도움을 받아 이슈들을 해결하되, lint가 짚어내지 못하는 부분만 정리해 보았다.

 

유사한 부분끼리 묶어라

코드를 읽을 때 전혀 다른 내용이 갑자기 나온다면 이해하는데 시간이 걸릴 수 있다.

유사한 기능이나 유사한 개념끼리 묶어서 코드를 구성한다면 코드의 이해를 도울 수 있다.

뿐만 아니라, 인스턴스 변수는 클래스 맨 처음에 선언하고, 로컬 변수는 사용하는 부분에 가장 가까이 놓는다.

 

한줄 코드는 쓰지 말자

사실 이 부분은 아직도 사람들끼리 의견이 분분한 부분이라고 생각한다.

어떤 사람들은 한줄 코드를 쓰면 가로로 길어지기 때문에 코드 가독성이 좋지 않다고 비판하고, 반대로 오히려 불필요하게 두 줄로 나누는 것이 세로로 길어져서 읽기 불편하다는 주장을 하기도 한다.

나는 이전까지 한줄 코드를 애용하던 입장이었지만, 지금부터는 코드를 작성할 때 간단한 if 문이더라도 엔터로 라인 구분을 하려고 한다.

 

6. 객체와 자료 구조

이 책을 읽어가면서 명확하게 이해가 되지 않았던 파트중 하나다. 

내가 이해한 내용을 바탕으로 서술해 보자면, '객체'와 '자료구조'를 구분하자는 것이 요지인 것 같다.

객체는 메소드만 노출하고 데이터를 숨기는 특성을 가지고 있다.

이 객체에 무분별한 getter/setter를 만들어 객체 외부에서 객체 내부의 데이터를 조작하기보다는 해당 액션을 처리하는 메소드를 만들고 외부에는 해당 메소드만 노출하는 것이 바람직한 practice이다.

반면, 자료구조는 액션 없이 데이터만 가지고 있는 구조로, 외부에 직접적으로 데이터를 노출한다.

새로운 자료 타입을 추가하는 일이 더 잦으면 객체를, 새로운 액션을 추가하는 일이 잦으면 자료구조를 사용하자.