Clean Code

소프트웨어에서 이름은 어디나 쓰입니다. 그러므로 이름을 잘 지으면 여러 모로 편합니다. 이 장에서는 이름을 잘 짓는 간단한 규칙을 몇 가지 소개합니다.

어떤 프로그램이든 가장 기본적인 단위가 함수입니다. 이 장은 함수를 잘 만드는 법을 소개합니다.

잘 달린 주석은 그 어떤 정보보다 유용합니다. 경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만듭니다. 오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼뜨려 해악을 미칩니다.

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 합니다. 코드 형식을 마주기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 합니다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 합니다.

시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하다면 객체가 더 적합합니다. 다른 경우로 새로운 동작을 추가하는 유연성이 필요하다면 자료 구조와 절차적인 코드가 더 적합합니다. 우수한 소프트웨어 개발자는 편견 없이 이 사실을 이해해야 합니다.

상당수 코드 기반은 전적으로 오류 처리 코드에 좌우됩니다. 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨긋한 코드라 부르기 어렵습니다.

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드뭅니다. 외부 코드를 우리 코드에 깔끔하게 통합해야 합니다. 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴봅니다.

애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 더 늘어나는 추세입니다. 하지만 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 사실을 놓칩니다.

코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않는다면 깨끗한 코드를 얻기는 어렵습니다.

모든 추상화 단계에서 의도는 명확히 표현해야 합니다. 그러려면 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 합니다. 실제 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심합니다.

우리들 대다수는 켄트 백이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 품질을 크게 높여준다고 믿습니다.

처음부터 코드를 깨끗하게 유지하기란 상대적으로 쉽습니다. 그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리합니다.

마틴 파울러는 "Refactoring"에서 다야항 코드 냄새론을 거론합니다.