Clean Code
1.Clean Code - 1. 깨끗한 코드
나중은 결코 오지 않는다
2.Clean Code - 2. 의미 있는 이름
의도를 분명히 밝혀라 단순 알파벳을 이름으로 사용하지 않기 숫자 상수도 변수로 선언해서 사용하기 그릇된 정보를 피하라 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하지 않기 서로 흡사한 이름 사용하지 않기 유사한 개념은 유사한 표기법 사용하기 의미 있게 구분하라 불용어 사용하지 않기(variable, info, data, a, an, the...) ...
3.Clean Code - 3. 함수
작게 만들어라 조건, 반복문에 들어가는 블록은 한 줄이어야 한다. 한 가지만 해라 >함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 단일 함수 내부의 모든 문장은 추상화 수준이 동일 해야 한다. Switch문 별도 서술 서술적인 이름을 사용하라 모듈 내에서 함수 이름은 같은 문구, 명사, 동사를 사용해야 한다. ...
4.Clean Code - 4. 주석, 5. 형식 맞추기
코드로 의도를 표현하라!
5.Clean Code - 6. 객체와 자료구조
객체 동작을 공개하고 자료를 숨김 새로운 자료 타입을 추가하는 유연성이 필요할 때 적절 자료구조 자료를 공개함 새로운 동작을 추가하는 유연성이 필요할 때 적절 디미터의 법칙 모듈은 자신이 조작하는 객체의 내부를 몰라야 함. 기차 충돌 메소드를 기차처럼 나열하는 것을 지양하고 나눠서 선언하는 방식을 추천. >이 책의 '복간에 부쳐'에 나오듯이 최근에는 오히려...
6.Clean Code - 7. 오류 처리
정리 오류 코드보다 예외를 사용하라 Try-catch-finally문부터 작성하라 미확인 예외를 사용하라 예외에 의미를 제공하라 호출자를 고려해 예외 클래스를 정의하라 null을 반환, 전달하지 말라 >if(variable != null)이라는 코드를 좋아하는 개발자가 있을까? NullPointerException을 피하기 위해 울며 겨자 먹기로 작성했던 ...
7.Clean Code - 8. 경계
외부 코드와 내부 코드의 경계(feat. 학습테스트) 테스트 케이스를 작성하면서 외부 코드를 익히자.(=학습테스트) 배운 지식을 통해 외부 코드를 별도 클래스로 캡슐화 하자. 아는 코드와 모르는 코드의 경계 아는 코드와 모르는 코드의 경계에 다음과 같은 구조를 차용해 모르는 코드와 별개로 개발을 가능하게 하자. > 구현 - interface - adapte...
8.Clean Code - 9. 단위 테스트
TDD 법칙 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 깨끗한 테스트 코드 = 가독성 DSL(Domain Specific Language): 도메인에 특화된 언어. 테스트 코드 작성 시 잡다하...
9.Clean Code - 10. 클래스
클래스 체계 정적 공개 변수 정적 비공개 변수 비공개 인스턴스 변수 공개 함수 비공개 함수(자신을 호출하는 공개 함수 바로 아래) 클래스 작성법 캡슐화 작은 클래스 = 단일 책임(SRP) 응집도: 큰 함수를 작은 함수 여러개로 쪼개기 일부 변수만 사용
10.Clean Code - 11. 시스템
시스템 제작과 사용의 분리 Main 분리: main 혹은 main에서 호출하는 모듈에 생성 코드를 분리 팩토리(abstract factory pattern): 추상화를 통한 분리 의존성 주입: DI 컨테이너에서 모든 생성을 관리하며 다른 모듈에 주입하는 방식으로 분리 횡단 관심사(cross-cutting) 객체 경계를 넘나드는 관심사. 영속성, 보안, 트...
11.Clean Code - 12. 창발성
모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다.
12.Clean Code - 13. 동시성
동시성의 필요성 구조적 개선 = 무엇과 언제를 분리 응답시간, 처리량 개선 동시성에 대한 오해 동시성은 항상 성능을 높여준다(X) 동시성을 구현해도 설계는 변하지 않는다(X) 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다(X) 동시성은 다소 부하를 유발한다(O) 동시성은 복잡하다(O) 일반적으로 동시성 버그는 재현하기 어렵다(O) 동시성...
13.Clean Code - 14. 점진적인 개선
점진적인 개선 TDD를 통해 점진적으로 개선하자. 충분한 테스트 케이스가 작성되어 있다면 리팩토링이 두렵지 않다. 여러 차례의 반복된 개선을 통해서 테스트 케이스가 실패하지 않는 방향으로 점진적으로 개선하자. 한 번에 구조를 크게 바꾸면 개선 전과 똑같이 프로그램을 실행하기 어렵다. > 저자는 Args 유틸리티를 수정하면서 약 30회에 걸친 수정을 진행한다...
14.Clean Code - 17. 냄새와 휴리스틱
함수나 클래스는 다른 프로그래머가 당연하게 여길 만한 독작과 기능을 제공해야 한다. 너무나 당연한 이야기이지만 '당연하게'의 기준이 남들과 다를 수 있기 때문에 역시 코드리뷰는 필수다. 모든 경계 조건을 테스트하는 테스트 코드를 작성해야 한다. 테스트 코드를 작성할 때 에러가 발생할 수 있는 케이스들에 대해 깊이 생각하는 습관을 들이자. 고차원과 저차원...