9장 단위 테스트 지난 1997년만 해도 TDD라는 개념을 아무도 몰랐고 단위 테스트란 자기 프로그램이 돌아간다는 사실만 확인하는 일회성 코드에 불과했다. 클래스와 메서드를 공들여 구현한 후 임시 코드를 급조해 테스트를 수행했는데 대개는 간단한 드라이버 프로그램을 구현해 자신이 짠 프로그램을 수동으로 실행했다. 하지만 지금은 눈부신 성장을 이뤘다. 꼬치꼬치 따지며 코드가 제대로 도는지 확인하는 테스트 코드를 작성하고 테스트 케이스를 모두 구현하고 통과한 후에는 내 코드를 사용할 사람들에게도 공개하고 테스트 코드와 내 코드를 같은 소스 패키지로 묶어 체크인한다. 애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 더 늘어나는 추세이다. 하지만 우리 분야에 테스트를 추가하려고..

8장 경계 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 때로는 패키지를 사고 오픈 소스를 이용한다. 어떤 식으로든 이 외부 코드와 우리 코드의 경계를 깔끔하게 처리하고 통합해야 한다. 1. 외부 코드 사용하기 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓혀 더 많은 환경에서 돌아가길 원한다. 하지만 사용자는 자신의 요구에 집중하는 인터페이스를 더 원한다. 예로 java.util.Map을 살펴보자. Map이 제공하는 기능성과 유연성은 확실히 유용하지만 그만큼 위험도 크다. 넘기는 쪽에서는 Map 내용을 삭제하지 않으리라 믿을 수 있지만, Map이 제공하는 메서드 중 Clear()가 존재한다. 즉, Map 사용자라면 누구나 Map 내용을 지울 수 있다. 어떤 클래스를 저장하는 ..

7장 오류 처리 뭔가 잘못될 가능성은 늘 존재한다. 뭔가 잘못되면 바로 잡을 책임은 바로 프로그래머에게 있다. 그렇다면 깨끗한 코드와 오류 처리가 관련이 있을까? 확실히 연관성이 있다. 상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다. 여기서 좌우된다는 표현은 코드 기반이 오류만 처리한다는 의미가 아닌 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기가 거의 불가능하다는 의미이다. 오류 처리는 중요하지만 이 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. 1. 오류 코드보다 예외를 사용하라 예외 처리를 지원하지 않는 프로그래밍 언어가 오류 처리를 할 땐, 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법이 전부였다. public v..

6장 객체와 자료 구조 변수를 private로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서, 변수 타입이나 구현을 맘대로 바꾸고 싶어서 그렇다면 왜 많은 프로그래머가 조회(get) 함수와 설정(set) 함수를 당연히 public으로 정의해 private 변수를 외부에 공개할까? 1. 자료 추상화 아래 두 클래스 모두 2차원 점을 표현한다. // 구체적인 Point 클래스 // 구현을 외부로 노출한다. // 명확하게 직교 좌표계를 쓴다는 것을 알 수 있다. public class Point { public double x; // 개별적으로 좌표값을 읽고 설정한다. public double y; } // 추상적인 Point 클래스 // 구현을 숨겨 클래스 메서드가 접근 정책을 강제한다...

5장 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 코드 형식은 의사소통의 일환이기 때문에 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. 1. 적절한 행 길이를 유지하라 행 길이는 파일의 크기(길이)를 말한다. 500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. 2. 신문 기사처럼 작성하라 소스 파일의 이름은 간단하면서도 설명이 가능하게 짓는다. 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경 써서 짓는다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명하고 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가..

4장 주석 잘 달린 주석은 어떤 정보보다 유용하지만 나쁜 주석은 코드를 이해하기 어렵게 만든다. 주석은 나쁜 코드를 보완하지 못한다. 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가 훨씬 좋다. 코드로 의도를 표현하라 많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다. 1. 좋은 주석 법적인 주석: 회사가 정립한 구현 표준에 맞춰 법적인 이유로 넣는다. Ex) 저작권, 소유권 등 정보를 제공하는 주석: 기본적인 정보를 주석으로 제공하면 편리하다. Ex) 반환값 등 의도를 설명하는 주석: 구현을 이해하게 도와주는 선을 넘어 결정에 깔린 의도까지 설명한다. 의미를 명료하게 밝히는 주석: 모호한 인수나 반환값은 그 의미를..