Clean Code

좋은 코드와 나쁜 코드는 무엇일까? 프로그래밍을 공부하다보면 늘 마주치는 의문이다. 이에 대한 답을 얻기 위해 클린 코드(Clean Code)를 찾았다.

"사소한 곳에서 발휘하는 정직은 사소하지 않다." - 옛 덴마크 속담 - , 사소한 듯 보이나 실제로는 사소하지 않은 내용.

올바른 변수 이름은 어떻게 설정해야하는 것일까? 클린 코드에 다다르는 첫 걸음은 변수 설정으로 부터 시작된다.

다른 사람의 TIL을 통해 클린 코드에 대한 생각을 들여다본다. 비슷한 내용에는 공감을 새로운 내용에는 영감을 얻을 수 있다.

함수를 만드는 첫째 규칙은 '작게!'다. 놀랍게도 저자가 말하는 둘째 규칙은 '더 작게!'다.

우리는 코드로 의도를 표현하지 못해, 그러니까 '실패'를 만회하기 위해 주석을 사용한다. 주석은 오래될수록 코드에서 멀어진다.

더러운 코드를 깨끗한 코드로 바꾸는 것으로 프로그램의 완성도를 높이고 속도를 높일 수 있다.

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다.

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

오류 처리는 중요하다. 하지만 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.

Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다. Map 인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않는다.

실제 코드만 작성하기도 너무나 바쁘고 힘든데, 테스트 코드는 왜 작성해야하는 것일까? 그리고 테스트 코드는 왜 그렇게 중요한 것일까?

변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 하지만 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.