1. 외부 코드 사용하기 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다 개발하다 보면 패키지나 오픈 소스를 사용하게 되는데 이런 소스를 제공하는 입장에서는 더 많은 환경에서 돌아갈 수 있도록 적용성을 넓히려고 애쓴다 하지만 사용자 입장에서는 자신의 요구에 집중하는 인터페이스를 바라게 된다 이런 차이에서 경계가 발생한다 java.util.Map 을 예로 들어보자 Map은 마음만 먹으면 사용자는 어떤 객체 유형도 추가하거나 삭제할 수 있다 Map을 만들어서 여기저기 넘긴다고 가정한다면 어디서든 삭제나 추가가 가능하다는 문제가 생긴다 또한 Map 인터페이스가 변경될 경우 수정할 코드 양이 상당히 많아진다 Map sensors = new HashMap; Sensor s = sensors.get..

1. 오류 코드보다 예외를 사용하라 public class DeviceController { ... public void sendShutDown() { DeviceHandle handle = getHandle(DEV1); // 디바이스 상태를 점검한다. if (handle != DeviceHandle.INVALID) { // 레코드 필드에 디바이스 상태를 저장한다. retrieveDeviceRecord(handle); // 디바이스가 일시정지 상태가 아니라면 종료한다. if (record.getStatus() != DEVICE_SUSPENDED) { pauseDevice(handle); clearDeviceWorkQueue(handle); closeDevice(handle); } else { logger..

1. 자료 추상화 public class Point { public double x; public doulbe y; } public interface Point { double getX(); double getY(); void setCartesian(double x, double y); double getR(); double getTheta(); void setPolar(double r, double theta); } 두 클래스를 비교해보자 2차원 점을 표현하는 클래스인데 위 클래스의 경우 외부로 모두 노출되지만, 아래 클래스의 경우 구현을 완전히 숨긴 형태이다 또한 접근 시 좌표값을 읽을 때 위 클래스의 경우 각각 개별적으로 읽게 되지만 아래 클래스의 경우 두 값을 동시에 설정해야한다 구현을 감추기 위..

1. 형식을 맞추는 목적 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무! 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다 처음 잡아 놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다 2. 적절한 행 길이를 유지하라 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다 소스도 신문 기사처럼 위에서 아래로 읽으며 첫 문단에 전체 기사의 내용을 요약하고 아래로 읽어 내려가면서 날짜, 이름, 발언, 주장 등 세세한 사실 알게된다 빈 행을 넣어 개념을 분리해야 한다 예를 들어 메서드와 메서드 사이에 빈 행이 없다면 가독성이 굉장히 떨어질 것 이다 반대로 같은 개념의 코드라면 공백 없이 밀접한 상태로 코드를 작성하는 것이 더 이해하기 좋다 private..

나쁜 코드에 주석을 달지 마라. 새로 짜라 - 브라이언 w. 커니핸, P.J.플라우거 1. 주석은 나쁜 코드를 보완하지 못한다 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 코드를 작성하고 보니 짜임새가 엉망이고 알아보기 어렵다면 주석이 아니라 코드를 다시 정리해야 한다 주석으로 설명하기보다는 깔끔하고 정돈된 코드가 훨씬 보기 좋다 2. 코드로 의도를 표현하라! 코드만으로 의도를 설명하기 어려운 경우 메서드를 분리하여 표현할 수 있다 // 직원에게 복지 혜택을 받을 자격이 있는지 검사한다. if ((employee.flags & HOURLY_FLAG) && (employee.age > 65)) { ... } if (employee.isEligibleForFullBenefits())..

1. 작게 만들어라! 함수를 만드는 첫째 규칙은 '작게', 두 번째 규칙은 '더 작게' 최대한 작게 만드는 것이 이 책에서 이야기하는 함수의 포인트이다 특히 if문, while 문 등에 들어가는 블록은 한 줄로 작성하는 것을 권장할 정도로 작게 만드는 것에 집착한다 즉, 중첩 구조가 생길 만큼 함수가 커져서는 안 된다는 뜻 함수에서 들여 쓰기 수준은 1단이나 2단을 넘어서면 안 된다 이렇게 작성하기를 권장하는 이유는 당연히 읽고 이해하기 쉽게 하기 위해서 이다! 2. 한 가지 해라! 하나의 함수는 한 가지만 처리해야 한다 그렇다면 '한 가지'의 범위는 무엇을 의미할까? 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다고 말할 수 있다 단순히 다른 표현이 아..

0. 깨끗한 코드 "나중은 결코 오지 않는다." - 르블랑의 법칙 나중에 돌아와서 다시 정리하겠다는 생각은 하지말자 나쁜 코드가 쌓일수록 생산성은 떨어지고 청소할 방법이 없어진다 그렇다면 깨끗한 코드란 무엇일까? 공통적으로 얘기하는 깨끗한 코드의 특징은 중복을 피하고, 한 기능만 수행, 제대로 표현, 작게 추상화 즉, 읽기 쉽고 유지보수성이 좋은 코드이다 1. 의도를 분명히 밝혀라 책에서는 의도가 분명한 이름은 정말로 중요하다는 사실을 거듭 강조한다 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다 변수, 함수, 클래스 등의 이름만으로 존재 이유, 수행 기능, 사용 방법을 유추할 수 있도록 신경 써서 지어야 한다 따라서 주석이 필요하다면 의도를 분명히 드러내지 못했다는 뜻..