본문 바로가기

Book review

(10)
17장. 냄새와 휴리스틱(clean code) -1 부적절한 상황들 주석 부적절한 정보 - 일반적으로 작성자, 최종 수정일 , software problem report 번호 등과 같은 메타 정보만 주석으로 넣는다. 쓸모 없는 주석 - 쓸모 없어질 주석은 아예 달지 않는 편이 좋다. 중복된 주석 - 코드로 충분하면 삭제해라 성의없는 주석 - 간결하고 명료하게 작성해라. 주석 처리된 코드 - 지워라! 환경 여러 단계로 빌드한다. - 빌드는 한단계로 끝내라. 여러 단계로 테스트한다. - 모든 단위 테스트는 하나의 명령으로 돌려라. 함수 너무 많은 인수 - 인수는 작을수록 좋다. 출력 인수 - 함수에서 출력 인수는 피하고, 함수가 속한 객체 상태를 변경하는 방식을 사용해라. 플래그 인수 - 플래그 인수는 피해라. 일반 한 소스 파일에 여러 언어를 사용한다. -..
10장. 클래스(clean code) 클래스 체계 순위 1) static or public 상수 2) private 변수 3) 비공개 인스턴스 변수 4) 공개함수 5) 비공개 함수 변수와 함수는 최선을 다해 비공개 상태를 유지하는 것이 좋으나, 테스트 코드에 접근을 허용하기도 한다. 클래스는 작아야 한다. 클래스가 맡은 책임은 작아야한다. - 클래스 이름은 해당클래스 책임을 기술해야한다. 단일 책임 원칙 - 클래스는 책임 즉 변경할 이유가 하나여야한다. 응집도 - 클래스는 인스턴스 변수 수가 작아야 한다. 응집도가 높아지도록 변수와 메서드를 적절히 분리하자. 클래스가 응집력을 잃는다면, 쪼개자. review 사실 모든 내용을 이해하지 못했다. 아직 경험이 부족한 것 같다! 한바퀴 돌고 난 후 다시 정독하기로 다짐해본다. 🏃 출처) clean..
8장. 경계(clean code) 외부코드 사용하기 ex) 자바에서 Map - 경계 인터페이스를 사용할 때는 여기저기 넘기지 말라 경계 살피고 익히기 외부 API를 사용할 때면 간단한 테스트 케이스를 작성하여 외부 코드를 익히는 편이 낫다. -> 외부 코드를 익히고 통합하는 것은 복잡한 과정이기 때문. 아직 존재하지 않는 코드 사용하기 특수하게는 우리가 알지 못하는 코드 영역도 있다. -> 필요한 경계 인터페이스를 알고, 우리가 바라는 인터페이스를 구현하라. 깨끗한 경계 외부 패키지에 의존하는 대신 우리 코드에 의존하는 편이 좋다. review 외부 패키지는 변할 가능성도 있고, 오히려 우리 코드보다 외부 코드에 휘둘리는 경우가 생긴다. 나도 외부 패키지는 되도록이면 지양하는 편이다. 오히려 더 복잡해지는 경우를 많이 경험했기 때문이다!..
7장. 오류처리(clean code) 오류 코드보다 예외를 사용하라 예외에 의미를 제공하라 오류 메시지에 정보를 담아 예외와 함께 던져라. - 로깅 기능에서 유용하다. 호출자를 고려해 예외 클래스를 정의하라 오류를 잡아내는 방법으로 분류해라. 감싸는 클래스를 이용하라. -> 감싸는 클래스? 클래스가 던지는 예외를 잡아 변환하는 역할만을 하는 클래스 정상 흐름을 정의하라 특수 사례 패턴을 이용해라 -> 클래스를 만들거나 객체를 조작하여 특수 사례 처리 null을 반환하지 마라 null을 반환할 경우 다른 코드에서 null 여부를 확인해야 하는데 나쁜 코드이다! null 대신 특수 사례 객체를 이용하여 의미가 있는 다른 갑을 반환해주면 된다. null을 전달하지 마라 null을 전달하게 되면 예외 처리를 해줘야 하니 되도록 전달하기를 피하라. ..
6장. 객체와 자료구조(clean code) 자료 추상화 클래스란 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 의미를 가진다. 자료를 세세하게 공개하기 보다는 추상적 개념을 표현하는 것이 좋다. 자료/객체 비대칭 객체와 자료구조는 상호보안적인 성격을 가진다. 디미터 법칙 모듈은 자신이 조작하는 객체의 속사정을 몰라야한다는 법칙 기차 충돌 final String outputDir= ctxt.getOptions().getScratchDir().getAbsolutePath(); 이런 방식의 코드는 피하는 편이 좋다. - 객체라면 내부구조를 숨겨야 하니 디미터 법칙을 위반한다. 자료구조라면 내부 구조를 노출하므로 디미터 법칙 위반이 아니다. 잡종 구조 절반은 객체, 절반은 자료구조인 설계는 단점만 모아둔 구조다. 자료..
5장. 형식 맞추기(clean code) 형식을 맞추는 목적 코드 형식은 의사소통이다. (협업할 때 주의) 적절한 행 길이를 유지하라 신문 기사처럼 작성하라. 이름은 간단하면서도 설명이 가능하게 해라. 소스파일이 첫 부분은 고차원 개념이나 알고리즘을 설명한다. 내려갈수록 의도를 묘사한다. 개념은 빈 행을 분리하라. ex) 패키지 선언부, import 문, 각 함수 사이에 빈 행이 들어가면 가독성이 높아진다. 세로 밀집도 서로 밀접한 코드 행은 세로로 가까이 놓여야 한다. 수직 거리 변수 선언 - 사용하는 위치에 최대한 가까이에 선언한다. 인스턴수 변수 - 클래스 맨 처음에 선언한다. 종속 함수 - 한 함수가 다른 함수를 호출한다면, 두 함수는 세로로 가까이 배치한다.(가능하다면 호출하는 함수가 먼저) 개념적 유사성 - 친화도가 높을 수록 코드는..
4장. 주석(clean code) 주석은 나쁜 코드를 보완하지 못한다 주석은 가능한 줄이자. 코드로 의도를 표현하라! if((employee.flags & HOURLY_FLAG) && (employee.age > 65)) if(employee.isEligibleForFullBenefits()) 전자보다는 후자가 낫다 좋은 주석 법적인 주석 정보를 제공하는 주석 ex) 추상 메서드가 반환할 값 설명 의도를 설명하는 주석 의미를 명료하게 밝히는 주석 ex) assertTrue(a.compareTo(a) == 0); // a == a 결과를 경고하는 주석 다른 프로그래머에게 결과를 경고할 목적 ex) // 여유 시간이 충분하지 않다면 실행하지 마십시오. TODO 주석 앞으로 할 일 ex) 더 이상 필요 없는 기능을 삭제하라는 알림, 누군가에게..
3장. 함수(clean code) 1. 작게 만들어라 함수는 짧을수록 좋고, 들여쓰기는 1단이나 2단을 넘어서지 않는게 좋다. if문 / else 문 / while문 등에 들어가는 블록은 한 줄로, 거기서 함수를 호출해라. 2. 한가지만 해라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 분리하라. 함수 내의 문장의 추상화 수준은 동일한 것이 좋다. (함수로만 구성된 코드는 추상화 수준이 높고, 구체적은 세부 구현을 담은 코드는 추상화 수준이 낮다.) 코드가 위애서 아래로 이야기처럼 읽히면 추상화 수준을 일관되게 유지하는 것이 쉬워진다. (내려가기 규칙: 한 함수 다음에 추상화 수준이 한 단계 낮은 함수가 오도록 함) 3. switch문 switch문은 다형성 객체를 생성하는 경우에 유용하다. 4. 서술적인 이름을 사용하라..