What is Clean Code?
어떻게 하면 코드를 더 잘 짤 수 있을까? 요즘은 단순 알고리즘 구현에 대한 고민보다 어떻게 하면 코드를 더 잘 짤 수 있을지에 대한 고민을 더 많이 하는 것 같다. 프로그래밍을 공부하고 경험하면서 나의 코딩 패러다임을 바꿔준 일련의 사건들이 많이 있었다. 이 책을 읽은 것은 그 사건 중에 하나인 것 같다.
코드를 잘 짜는 것은 중요하다. 여기서 코드를 잘 짠다는 의미는 단순히 엄청나게 천재적인 알고리즘을 코드로 구현하는 것도 아니고, 단순히 원하는 요구사항이 작동하는 코드를 의미하는 것은 더더욱 아니다. 코드라는 것은 프로그래머에 의해 프로그래밍 언어로 작성된 문서이다. 프로그래밍 언어라는 것은 말 그대로 언어이다. 요즘 들어서는 이 언어가 프로그래머와 컴퓨터 사이의 의사소통 뿐 아니라, 다른 프로그래머와의 의사소통이라는 점에서 더 큰 의미를 가지는 것 같다. 즉, 내가 작성한 프로그래밍 언어를 다른 사람이 손쉽게 읽을 수 있는가? 이 점이 요즘 프로그래밍에서 가장 중요시 되어야 하는 것이 아닌가 생각한다.
현대에는 하나의 프로그램을 혼자서 만드는 일이 드물다. 작게는 학교에서 했던 팀 프로젝트 과제부터 회사에서 하는 팀 단위 프로젝트, 더 크게는 전 세계 사람이 참여하는 오픈 소스 프로젝트까지 해서 여러 사람이 하나의 프로그램을 만드는 데 참여하고 있다. 프로젝트에 참여하는 사람들이 가장 효율적으로 의사소통 할 수 있는 방법은 프로그래밍 언어를 통한 방법이다. “프로그래머는 코드로 대화한다.”라는 말도 있듯이 내가 만든 프로그램에 대한 장황한 설명 보다도 코드를 직접 보여 주는 것이 프로그래머 사이에서는 더 좋은 의사소통 방법일 것이다.
좋은 코드가 구체적으로 무엇인가?
개인적인 생각으로 프로그래밍 코드 자체는 하나의 읽기 쉬운 문서가 되어야 한다. 개발 문서를 전면 부정하는 것은 아니다. 하지만 코드의 가독성은 상당히 중요하다. 코드는 위에서 아래로 쭉 읽어 내려가면서 전체적인 프로그램의 로직이 한 눈에 들어와야 하며, 이를 위해서는 적절한 네이밍과 모듈화가 잘 이루어져야 한다. 프로그래밍을 처음 시작하고 몇 가지 규모 있는 예제나 프로젝트를 수행해본 프로그래머에게 조언하고 싶은 두 가지가 바로 네이밍과 모듈화이다.
네이밍이란 말 그대로 “이름 짓기”이다. 우스갯 소리로 프로그래머들에게 가장 어려운 작업은 이름을 짓는 것이라는 농담도 있다. 단순한 농담이 아니라 실제로 그렇다. 이제 더 이상 변수의 이름을 C언어 책 첫 예제에 나오는 a, b, c로 지어서는 안된다. 이름은 변수, 함수, 클래스에 대한 모든 것을 한 눈에 표현해 줄 수 있어야 한다. 이름을 길게 지어도 상관 없다 (물론 이 부분에서 정말 무식하게 100자 이상의 이름을 짓지는 않을거라고 생각한다.). 좀 더 구체적으로 말하자면 2~3 단어 정도의 조합, 동사와 목적어 조합과 같은 수준의 이름이 들어가는 것이 좋다고 생각한다. 이름은 꼭 한 단어일 필요는 없다. 네이밍에 대해 조금 더 나아가자면 자신 만의 네이밍 규칙을 만드는 것이 좋다. 예를 들어, 전역 변수는 모두 대문자로 쓴다 라든지, 함수 이름은 소문자로 시작하여 단어와 단어의 구분은 대문자로 한다와 같은 규칙이다. 이러한 규칙이 있다면 코드를 읽을 때 전역 변수와 지역 변수, 함수가 한 눈에 구분된다.
모듈화는 작업을 나누는 것이다. 이 책을 읽으면서 가장 공감한 단어가 단일 책임 원칙 (SRP, Single Responsiblity Principle) 이다. 하나의 클래스나 함수는 하나의 책임만을 가져야 한다. 즉, 하나의 목적을 위해 사용되어야 한다. 하나의 클래스나 함수 안에서 여러가지의 목적을 동시에 수행해서는 안된다는 것이다. 모듈화를 수행하면 코드를 작성하는 것이 한결 쉬워진다. 하나의 함수나 클래스를 작성할 때 오로지 하나의 목적에만 집중하면서 작성하기 때문에 다른 여러 잡 생각을 없앨 수 있다. 또한 모듈화를 잘 하면 네이밍을 하기도 수월해진다. 하나의 모듈을 설명하는 말이 간단해지고 명확해지기 때문이다. 모든 기능을 하나의 함수에 다 넣어버린 코드보다 여러 기능을 여러 개의 모듈이 나눠 가지고 하나의 메인 함수 안에서 각 모듈을 호출하는 형태로 코드를 작성하는 것이 코드 작성과 리펙터링 측면에서 더 좋다.
이 책을 통해 알게된 것
주석에 대한 고찰
프로그래밍을 처음 배울 때 주석에 대한 중요성을 강조하는 사람이 많았다. 학교에서 과제를 낼 때면 주석에 대한 점수를 따로 주는 경우도 많았다. 그러나 주석을 잘 작성하는 방법은 아무도 알려주지 않았고, 그래서 그냥 무작정 코드 길이 만큼의 주석을 달아서 낸 적도 있었다. 도저히 이 문서가 코드인지 주석 문서인지 분간할 수가 없었다.
이 책을 통해 주석에 대한 나의 생각이 많이 정리되었다. 주석은 거의 없어야 하는 것이 맞다. 다소 극단적으로 보일 수 있다. 물론 코드만으로 나의 로직이 다 설명되지 않는다면 주석을 써야한다. 하지만 무책임하게 작성된 코드에 대한 책임 회피로 주석을 작성할 것이라면 그 시간에 좀 더 책임감 있는 코드를 짜야 한다. 많은 사람들이 책임 회피성으로 주석을 작성하는 경우가 많다. 그렇기에 주석을 최소화 한다고 처음부터 마음먹고 시작하는 것이 좋다. 그러고 나서야 비로소 코드를 더 책임감 있게 짤려고 노력하게 되었다.
테스트 주도 개발 (TDD, Test Driven Development)
처음 테스트 케이스라는 말을 접한 것이 학부 3학년 소프트웨어 공학 수업에서 였던 것 같다. 난생 처음으로 테스트 케이스를 만들었고, 사실 그 때는 그냥 뻔히 Pass 되는 테스트 케이스를 만드는 것이 무슨 의미가 있나 생각했던 것 같다. 그러나 테스트 케이스를 작성하는 것은 프로그램의 무결성을 위해 중요하다. 프로그램은 첫 번째 버전으로 완성 되는 것이 아니라 끊임 없이 수정된다. 새로운 기능이 추가 되기도 하고 버그를 수정하기도 한다. 그러나 프로그램에 수정이 가해져도 원래 프로그램의 수행 흐름이 변화해서는 안된다. 테스트 주도 개발은 프로그램을 수정하고 나서 프로그램 수행 흐름 변화에 대한 두려움을 완화시켜 준다. 프로그램을 수정하고 기존에 작성한 테스트 케이스를 수행하라. 만약 모든 테스트 케이스가 잘 돌아간다면 당신의 수정 사항은 프로그램 수행을 방해하지 않는 것이다. 테스트 케이스를 더 공들여 만들어라. 지금 작성한 테스트 케이스는 나중에 당신의 프로그램이 올바른 방향으로 나아가고 있는가에 대한 나침반이 될 것이다.
마치며
이 책은 나중에 꼭 다시 읽어야 겠다는 생각을 많이 했다. 아직 프로젝트 경험이 부족한 내가 단번에 이해하기 어려운 부분이 많았고, 다수의 프로젝트 경험을 통해 그 어려운 점을 스스로 느끼고 나서 더 큰 도움이 될 것 같았다. 이 책은 지금 현재에도 나의 프로그래밍 패러다임을 많이 변화 시켜 주었고, 미래 어느 순간에 다시 읽더라도 나의 패러다임을 크게 변화시켜줄 책이다. 더 좋은 코드를 짜고 싶은 사람이라면 이 책을 꼭 추천한다.
이 글의 내용이 다소 두서없고 책의 내용을 많이 담지 못하고 있다고 느낀다면 아래의 블로그에 들어가 보는 것도 추천한다. 개인적인 생각으로 책의 내용이 보기 쉽게 정리되어 있다.