코드 냄새가 나는 부분들 주석 부적절한 정보 성의없는 주석 쓸모없는 주석 주석처리된 코드 중복된 주석 환경 여러 단계 빌드 여러 단계 테스트 함수 너무 많은 인수 플래그 인수 출력 인수 죽은 함수 일반 한 소스 파일에 여러 언어 사용 당연한 동작을 구현하지 않음 경계를 올바로 처리하지 않음 안전절차 무시 중복 (코드 중복 줄이기!!) 코드 중복: 함수로 분리 switch, if-case: 다형성 대체 알고리즘이 유사하지만 코드는 다름: Template Method 패턴, strategy 패턴 추상화 수준이 올바르지 못함 기초 클래스가 파생 클래스에 의존 과도한 정보 더이상 사용되지 않는 코드 (죽은 코드), 쓸모 없는 코드 수직 분리 x 일관성 부족 인위적 결합 … 함수, 상수, 변수들이 당장 편한 위치..
동시성이 필요한 이유? 결합(coupling)을 없애는 전략 (= 무엇과 언제를 분리) 응답 시간과 작업 처리량 개선 동시성에 관한 미신과 오해 동시성은 항상 성능을 높여준다? x. 대기 시간이 길어 여러 스레드가 프로세서를 공유할 수 있거나 여러 프로세서가 동시에 처리할 독립적 계산이 충분히 많은 경우에만 가능 동시성을 구현해도 설계는 변하지 않는다? x. 무엇과 언제를 분리하면 시스템 구조는 크게 달라진다. 동시성에 관한 타당한 생각 동시성은 다소 부하를 유발함 동시성은 복잡함 일반적으로 동시성 버그는 재현하기 어려움 (일회성 문제로 여기기 쉬움) 동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 함. 난관 여러 스레드가 동시에 같은 코드에 접근할 가능성이 있다 —> 문제 발생!! 동시성 방어 ..
창발적 설계로 깔끔한 코드를 구현하자 모든 테스트를 실행한다 중복을 없앤다 프로그래머 의도를 표현한다 클래스와 메서드 수를 최소로 줄인다 단순한 설계 규칙 모든 테스트를 실행하라 TC를 짜려면 낮은 결합도, 높은 응집력 필요 —> 설계 품질 향상 리팩터링 TC가 모두 작성된 이후 코드와 클래스 정리 —> 코드를 고치더라도 TC가 있으니 시스템이 깨질 걱정 줄어든다 중복을 없애라 똑같은 코드를 줄이기 위해 메서드로 분리할 수 있다. (SRP에 위배되는 경우 클래스로도 분리가 가능함) 소규모 추상화 표현하라 개발자가 코드를 명백하게 짜야 다른 사람이 이해하기 쉬워진다. 결함과 유지보수 비용을 낮출 수 있음 좋은 이름 선택 함수, 클래스 크기 줄이기 —> 이해도 향상 표준 명칭 사용 단위 테스트 케이스 꼼꼼히..
시스템 수준에서도 깨끗함을 유지하는 방법 시스템 제작과 사용을 분리 소프트웨어 시스템은 애플리케이션 객체를 제작하고 의존성을 서로 ‘연결’하는 준비 과정과 준비과정 이후에 이어지는 런타임 로직을 분리해야 한다. func getService() -> Service { // Lazy Initialization / Lazy Evaluation if service == nil { service = MyService(...) } return service } /* good: 불필요한 부하 x, nil 반환 x bad: getService 메서드가 MyService에 의존적이다. 만약 MyService가 무거운 객체라면 단위테스트에서 getService 호출 전에 적절한 Mock 객체를 service에 할당해야 한..
