[클린 코드] 클린 코드 내용 정리
미루고 미루던 클린 코드를 1회 완독 하였습니다. 한번 읽은 거로는 제대로 이해가 안됐지만 읽으면서 따로 메모해놓은 내용을 블로그에 공유 해보려고 합니다. 빠진 내용도 많고 더 궁금한 내용은 책을 읽어 보시는걸 추천드립니다.
책에서는 다양한 관점에서 클린 코드를 설명하고 있습니다. 함수, 클래스, 이름, 동시성 등등 예시를 사용하여 작성 되어있습니다.
클린 코드?
클린 코드란 무엇일까요, 책에서 여러 인물들이 말하는 클린코드에 대한 의견 중 몇가지면 적어보면 다음과 같습니다.
Grady Booch
클린 코드는 간단하고 명료하다. 클린코드는 잘 쓴 문장처럼 읽힌다. 클린 코드는 기획자의 의도를 어지럽히지 않으며, 명쾌한 추상화와 단순한 제어문으로 가득하다.
Ward Cunningham
깨끗한 코드로 일을 할 때면, 각 루틴은 짐작한대로 수행한다. 해당 코드가 문제를 해결하기 위해 작성된 언어처럼 보인다면, 아름다운 코드라고 불러도 되겠다.
Michael Feathers
깨끗한 코드의 특징은 여러가지 있지만, 그 중 모든 것을 아우르는 특징이 하나 있다. 깨끗한 코드는 언제나 누군가 주의깊게 짰다는 느낌을 준다. 이미 작성자가 코드에서 모든 사항을 고려하여 작성했으며, 더 발전시키려 해도 딱히 발전시킬 거리가 보이지 않는다. 해당 코드라는 작품에 감사함을 느끼게 한다.
이외에도 다양한 의견이 있으니 책에서 참고하시면 좋을것 같습니다.
책에서는 저자의 오랜 경험을 통해 알게 된 변수명 작성, 함수 작성, 클래스 등을 작성하는 방식을 설명하고 있습니다.
보이스카우트 원칙
시간이 지남에 따라 코드가 점점 꼬이거나 더러워집니다. 코드를 클린하게 작성하는 것 뿐만아니라 유지하는 것도 중요합니다.
캠프장을 처음왔을 때 보다 더 깨끗하게 해놓고 떠나라
한꺼번에 많은 시간과 노력을 투입하여 코드를 클린하게 할 필요가 없다고 저자는 말합니다. 조금 긴 함수를 기능 별로 분할하고, 약간의 중복을 제거하고 복잡한 if문을 정리하면 충분합니다.
의미있는 이름
의도가 분명히 밝혀라.
코드가 하는 일이 짐작하기 쉽게 의도가 분명하게 지어야 합니다. 의도가 분명한 좋은 이름을 지으려면 시간이 걸리지만 이로인해 절약하는 시간이 훨씬 많아 질 것입니다.
그릇된 정보를 피하라.
코드의 의미를 흐리는 정보를 담아서는 안됩니다. 여러 계정을 그룹으로 묶을 때 실제 List가 아니라면 accountList라 며염ㅇ하지 않는 것이 좋습니다. List는 개발자들에게는 특수한 의미이기 때문에 accountGroup, Accounts 등과 같이 의미가 흐리지 않게 명명하면 좋습니다.
검색하기 쉬운 이름을 사용하라.
문자 하나를 사용하는 이름과 상수는 텍스트에서 쉽게 눈에 띄지 않는다는 문제점이 있습니다. e라는 문자를 변수로 한다면 얼마나 많은 e라는 문자가 검색될지 상상이 가실겁니다. 이런 관점에서 긴 이름이 짧은 이름보다 좋습니다.
클래스 이름, 메서드 이름
클래스 이름과 객체 이름은 명사나 명사구가 적합합니다. Customer, Account, AddressParser 등이 좋은 예 입니다. Manager, Processor, Data, Info 등과 같은 단어는 피하고 동사는 사용하지 않습니다.
메서드 이름이 동사나 동사구로 사용하는것이 적합합니다. postPayment, deletePage, save등이 좋은 예 입니다.
한 개념에 한 단어를 사용하라. 말장난 X
개발을 하다보면 같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 명명하여 혼란스럽습니다. 일관성 있는 어휘를 사용하여 명명 하는 것이 좋습니다. 또한 한 단어를 두 가지 목적으로 사용하면 안좋습니다. 다른 개념에 같은 단어를 사용한다면 말장난에 불과합니다.
add 라는 이름의 메서드를 값 두 개를 더하거나 이어서 새로운 값을 만드는 용도로 사용할 때, 집합에 값 하나를 추가하는 메서드에 add명명하는 건 일관성 유지가 되지 않습니다. insert나 append라는 이름이 적절합니다.
이외에 해법 영역과 문제 영역에서 가져온 이름을 사용하거나, 의미 있는 맥락을 부여하여 명명하는 등 내용이 있습니다.
함수
작게 만들고 한 가지만 해라!
함수는 짧으면 짧을 수록 작으면 작을수록 좋다고 할 수 있습니다. 그래야 가독성이 올라가고, 읽고 이해하기가 쉽습니다.
또한 함수는 한 가지 일만해야하고 그걸 잘해야 합니다. 그럼 한 가지라는건 어떻게 판단하냐면 지정 된 함수 이름 아래서, 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 하는 것입니다. 하지만 의미 있는 이름으로 다른 함수를 뽑아낼 수 있다면 그 함수는 여러 작업을 하는 것입니다.
내려가기 규칙
함수는 위에서 아래로 코드가 내려가야 합니다. 위에서 아래로 이야기처럼 읽혀야 합니다.
서술적인 이름을 사용하라.
함수가 작고 단순 할 수록 서술적인 이름을 짓기 쉬워집니다. 이름이 길어져도 무서워 할 필요 없습니다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋고, 길고 서술적인 이름이 길고 서술적인 주석보다 좋습니다.
함수 이름을 정할때는 여러 단어가 쉽게 읽히는 명명법을 사용하며 여러 단어를 사용해 함수 기능을 잘 표현하는 이름을 선택합니다.
오류 코드보다 예외를 사용하라!
오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해집니다. 함수 내에서 Try/Catch를 뽑아내 별도의 함수로 뽑아내는 편이 좋습니다.
위에서 얘기 했듯이 함수는 한 가지 작업만 해야 합니다. 오류 처리도 한 가지 작업에 속합니다. 그러므로 오류를 처리하는 작업은 따로 빼서 처리해야 마땅합니다. 함수에 try 키워드가 있다면 그 함수는 try문으로 시작해 catch/finally문으로 끝나야 합니다.
3장에서는 함수를 잘 만드는 기법을 소개하고있습니다. 이러한 규칙을 따라 함수를 작상한다면 좋은 이름에 길이가 짧고 체계가 잘 잡힌 함수를 만드는데 도움이 많이 될 것입니다.
다음글에서는 나쁜주석,좋은주석, 형식, 오류처리 등 3장 이외에 내용을 정리해보도록하겠습니다.