프로그램을 하나 만들 때 모든 기능을 직접 개발하는 경우는 거의 없다. 라이브러리를 활용하거나 외부 패키지를 불러와 사용하는 경우가 대부분이다. 이러한 상황에서 우리쪽에서 개발하는 코드와 외부의 코드의 경계가 생기기 마련이고 경계를 확실히 하지 않으면 수정할 때 손이 많이 가게 된다. 그래서 애초에 경계를 명확히 나누면서 개발하면 수정을 최소화하면서 유연하게 변화에 대처할 수 있다. 이번 챕터에서는 경계를 만들어야 하는 상황과 해결책을 제시한다. 외부 코드 사용하기 패키지, 프레임워크 제공자는 최대한 많은 사용자들이 범용적으로 사용할 수 있도록 인터페이스를 설계한다. 반면 인터페이스를 사용하는 입장에서는 본인이 필요로 하는 요구사항에 집중하기를 바란다. java에서 제공하는 java.util.Map을 예..
오류 코드보다 예외를 사용하라 오류 코드를 사용했을 때의 문제점 아래의 코드처럼 오류처리가 많아져 코드가 복잡해진다. 또한 휴먼에러 발생가능성이 농후해진다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 public class DeviceController { ... public void sendShutDown() { DeviceHandle handle = getHandle(DEV1); // 디바이스 상태를 점검한댜. if (handle != DeviceHandle.INVALID) { // 레코드 필드에 디바이스 상태를 저장한다. retrieveDeviceRecord(handle); // 디바이스가 일시정지 상태가 아니라면 종료한다. if (reco..
자료 추상화 OOP에서 특수한 경우가 아니면 class안의 인스턴스변수를 private으로 정의하는 한다. 왜냐하면 남들(사용하는 쪽)이 변수에 의존하지 않게 만들기 위해서이다. 참고 + (d-yong.tistory.com/21) [C++] 클래스를 캡슐화(Encapsulation) 하는 이유(왜 멤버변수는 대부분 private인가?) 객체지향 언어에서 클래스를 만들때 항상 나오는 말은 캡슐화(Encapsulation)다. 즉, 멤버변수는 private 접근 한정자로 외부의 직접적인 접근을 제한하고 클래스를 사용하는 외부에 인터페이스를 제 d-yong.tistory.com 위의 내용에 한발더 나아가 클린코드에서는 추상화 인터페이스를 제공해 API를 사용하는 쪽에서 내부 구현을 모른채 기능을 사용할 수 있..
형식을 맞추는 목적 코드 형식의 목적은 의소소통의 일환이다. 오랜 시간이 지난 코드는 (요구사항 변화등으로)수정이 될지라도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 요이성과 확장성에 영향을 미친다. 경험상 형식이 안좋은 코드는 다른 개발자가 코드를 수정해야 할 때 안좋은 형식을 그대로 따라가게 된다. 따라서 눈에 읽기 좋은 코드를 만들기 위해 형식을 맞추도록 노력해야한다. 적절한 행 길이를 유지하라 개발 언어마다 차이는 있겠지만 하나의 파일 안에 몇천,몇만줄의 코드가 들어있으면 굉장히 피곤하다. 따라서 최대한 작은 파일로 코드의 길이를 유지하면 좋다. 책에서는 한 파일당 200줄 내외가 적당하다고 말한다. 물론 하나의 파일에 몇 줄의 코드가 정답이다 라는것은 없지만 최대한 파일을 작게 만든..
내가 주석을 추가할 때 코드로 설명하기 어려움이 있어서 추가하는 경우가 대부분이었다. 그러나 프로그래밍 언어를 통해 의도를 표현할 능력이 있다면, 주석은 전혀 필요하지 않다고 저자는 말한다. 하지만 아주 특별한 경우 좋은 주석도 존재한다고 설명한다. Q. 주석이 있으면 왜 안좋은가? A. 코드는 변화하고 진화한다. 이러한 과정에서 주석은 코드를 정확히 따라가기(업데이트되기) 힘들다. 따라서 부정확한 정보를 제공하는 주석으로 남을 가능성이 있다. 주석은 나쁜 코드를 보완하지 못한다 코드에 주석을 추가하는 일번적인 이유는 코드 품질이 나쁘기 때문이다. 위에서도 말했듯이 코드 작성자가 코드로 설명하기 힘든경우 코드외에 주석을 추가하여 의도를 설명한다. 즉, 클린코드 관점에서 서술적인 코드가 되지 못한것이다. ..
작게 만들어라 함수에 대한 클린코드의 메세지는 2장의 의미있는 이름을 만드는 방법과 연장선에 있는 내용이다. 더 편하고 이해하기 쉽게 코드를 작성하는 것을 목표로한다. 모든 프로그램의 가장 기본적인 단위는 함수이다. 기존의 코드를 읽을 때 함수부터 시작하게 되는데 함수가 조금이라도 긴 경우 읽고싶은 마음은 없어지고 스트레스만 밀려오게 된다. 함수는 짧을 수록 좋다는게 클린코드의 철학이다. 한 가지만 해라 대부분 길이가 긴 함수는 두가지 이상의 일을 하는 경우가 많다. 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다. 함수를 만드는 이유는 큰 개념을 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서이다. 길이가 긴 A함수 안에서 의미 있는 이름의 다른 함수를 추출할 수 있다면 ..
의도를 분명히 밝혀라 변수, 함수, 클래스 이름을 정할 때 아래의 세가지 질문에 대답이 가능 하도록 이름을 짓는다. 1) 존재 이유 2) 수행 기능 3) 사용 방법 예) 1 2 int d; //경과 시간 int elaspedTimeInDays; cs 단순히 변수 명을 d라고 쓰는 경우보다 아래와 같이 구체적으로 사용하는게 좋다. 또한 함수가 어떤 일을 하는지 이해하기 쉽게 기술하도록 노력한다 예) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Member* getThem() { for(vector::size_type i = 0; iisLeader()) return (*iter); } }//앞의 함수보다 이해하기 Colored by Color Scripter cs 로직은 동일하지만 이름을..
코드 존재의 이유 저자는 "요구사항을 표현하는 언어"라고 한문장으로 정의한다. 간혹 목적이 희미한채로 코드를 작성하게 될 때도 있는것 같다. 그럴때면 어떤 요구사항을 위해 코드를 작성하는지 다시한번 생각해보고 요구사항을 함께 검토해봐야 한다. 나쁜 코드 나쁜코드란 유지보수가 안되는 코드라고 말한다. main부터 본인이 직접 작성하는 경우보다 기존에 존재하는 코드(legacy code)에 요구사항을 추가하는 경우가 대부분이다. 남들이 작성한 코드는 언제나 부담스럽다. 그러나 어떤 사람이 짠 코드는 며칠을 봐도 이해가 안가는 반면 어떤 사람이 짠 코드는 몇 시간이면 이해가 간다. 남의 코드를 보는 것은 항상 어려운 일이지만 그 난이도의 차이는 분명이 존재한다. 나쁜 코드가 쌓일 수록 생산성은 아래의 그래프 ..
