코드 냄새가 나는 부분들 주석 부적절한 정보 성의없는 주석 쓸모없는 주석 주석처리된 코드 중복된 주석 환경 여러 단계 빌드 여러 단계 테스트 함수 너무 많은 인수 플래그 인수 출력 인수 죽은 함수 일반 한 소스 파일에 여러 언어 사용 당연한 동작을 구현하지 않음 경계를 올바로 처리하지 않음 안전절차 무시 중복 (코드 중복 줄이기!!) 코드 중복: 함수로 분리 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에 할당해야 한..
클래스 체계 변수목록 static public static private 비공개 인스턴스 변수 함수 공개 비공개 (자신을 호출하는 공개 함수 직후에 배치) 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 것이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 종종 변수와 유틸리티 코드를 protected로 선언(비공개로 함수를 만들어 TC를 짤 수 있다면 best)해 테스트 코드에 접근을 허용하기도 한다. 클래스는 작아야 한다 물리적 크기도 중요하지만 클래스가 갖는 ‘책임’의 수가 작아야 한다. 클래스 이름: 클래스의 책임을 기술 (Processor나 Manager가 붙은 이름은 클래스 하나가 여러 책임을 떠안은 것) 단일 책임 원칙 (SRP, Single Responsibility Principle) 클래..
TDD (Test Driven Development) 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. → 개발 - 테스트 30초 주기로 진행하면 TC와 실제 코드가 함께 나온다! → TC의 증가는 관리 문제를 유발하기도 한다. 깨끗한 테스트 코드 유지하기 지저분한 TC는 변경이 어렵다. (실코드를 변경하면 TC도 변경이 필요하게 됨) : TC에 대한 유지보수 비용이 증가한다. 하지만 TC를 포기하게 되면 수정한 코드가 제대로 도는지 확인할 방법이 없기 때문에 코드 변경에 있어 주저하게 되고 코드가 망가질 수 있음. 그러므로 TC는 사고, 설계, 주의..
