좋은 코드는 좋은 책과 같다

코드는 한권의 책이다.
그러므로 코드는 일기 쉬워야 한다.

책의 내용과 책의 Readability, 책의 가독성 둘다 읽기 쉬운 것에 영향을 줄 것이다.

좋은 책은 딱 집어들고 책장을 폈을 때 읽고 싶은 책이다.
좋은 책은 딱 집어들어 펴봤을 때 술술 읽히는 책이다.

좋은 코드 또한 좋은 책과 다름 없다.

코드를 열었을 때 읽고 싶은 코드
코드를 열었을 때 잘 읽히는 코드

이런 코드가 좋은 코드이고, 좋은 코드는 가속성에 있어서 탁월해야 한다.

Dustin Boswell과 Trevor Foucher 가 쓴 The Art of Readable Code 는 그런 의미에서 그런 나의 생각과 의견을 같이하는 책이다.

1장의 제목도 그러한 생각과 연결되어 “Code should be easy to understand” 이다.

좋은 코드의 근본적인 핵심도 아래와 같이 정의한다.

“Code should be written to minimize the time it would take for someone else to understand it.”
“코드는 그것을 읽는 다른 사람으로 하여금 코드를 이해하는데 가장 적은 시간을 들이도록 쓰여져야 한다.”

나 같은 경우에도 코드를 읽을 때, 흐름을 방해하는 모든 것들은 싫어한다.

코드를 읽을 때는 머리 속에 로직이 돌아가고 있다. 마치 컴퓨터처럼 한줄 한줄을 읽으며 그것이 무엇을 하는 라인인지 인지하고, stack 에 차곡차곡 쌓고 넘어간다. 그런데 그 코드에 잠시 내용과 관계없는 우스꽝스러운 코멘트가 쓰여져 있거나, 미친듯이 긴 변수를 만나거나 혹 알수없는 축약으로 naming된 Method를 맞딱드리게 되거나, 혹은 코드를 짠 사람의 이름의 코멘트나 변수들이 덕지덕지 발라져 있으면 순간 브레이크가 걸리는 것을 경험한다.

협업을 하다보면 이러한 경우를 얼마나 많이 발견하겠는가? 그때마다 나의 브레인 브레이킹을 건 코드를 만든 사람에게 내 뇌가 뜨거워진 책임을 묻고 추궁한다면 정말 스트레스 받는 일이다.

그래서, 같은 팀일 수록 좋은 코드가 무엇인가 에 대한 가치의 공유가 필요하다. 그 팀에서 나오는 코드는 그 팀 만의 색깔이 있어야 한다. 당연히 Code Convention에 대한 명확한 정의 또한 필요하고 그 협의된 룰 안에서 코드를 작성하도록 해야한다.

좋은 구조 설계를 하는 것, Programming 팀의 좋은 Team Work을 유지하는 것, 성공하는 Product을 만드는 것, 유지 보수가 좋은 코드를 만드는 것, 잘 작동하는 코드를 만드는 것.

따지고 보면 성공하는 팀의 프로그래밍 팀에서 챙겨야할 것들이 참 많다.

그러나 각각의 Programmer들이 코드를 자주 열어보고 싶고,
코드를 자주 자주 분석하고 싶고,
코드를 바라보기를 좋아하도록 만드는 것은 매우 중요한 이슈이다. 당연히 그러기 위해서는 읽기 좋은 코드를 작성해야 한다.

왜냐하면, 그것은 좋은 코드 Quality를 이루는 기본이 되고,
우리 중 누구도 폈다가 바로 덮어 버리고 싶은 책을 만들고 싶어하지 않기 때문이다.