창발적 설계로 깔끔한 코드를 구현하자 우리는 켄트 백이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿고 있습니다. 켄트 벡은 다음 규칙을 따르면 설계는 '단순하다'라고 말합니다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 위의 순서는 중요도 순서로 배치되어 있습니다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 테스트할 수 없는 시스템은 검증도 불가능합니다. 논란이 조금 존재하지만, 검증할 수 없는 시스템은 절대 출시해서는 안 됩니다. 테스트 케이스가 많을수록 테스트가 쉽게 코드를 작성할 수 있습니다. 결국 테스트가 가능한 시스템을 만들면 더 나은 설계를 얻을 수 있습니다. 결합도가 높으면 테스트하기 어렵기..
복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다. 복잡한 코드를 보게 된다면 읽을 엄두조차 안 나게 되는데 유지보수와 테스트 진행까지 상상해 보았을 때 벌써 생기를 빼앗긴 기분이 듭니다. 이번 장에서는 클래스보다 더 높은 추상화 수준인 시스템 수준에서도 깨끗함을 유지하는 방법에 대해 살펴봅니다. 시스템 제작과 시스템 사용을 분리하라 소프트웨어 시스템은 객체를 제작하고 의존성은 연결하는 준비 과정과 이후에 이어지는 런타임 로직을 분리해야 합니다. 설정 논리와 일반 실행 논리를 분리해야 모듈성이 높아집니다. Main 분리 간단한 제어 흐름을 가지고 있는 방법입니다. main 함수에서 시스템에 필요한 객체를 생성한 후 이를 애플리케이션에 넘깁니다. 애플리케이..
자바는 결국 클래스로 모든 것이 구성되어 있습니다. 코드, 함수에서 더 높은 차원인 클래스까지 신경 써야만 깨끗한 코드를 얻을 수 있습니다. 이 장에서는 깨끗한 클래스에 관한 내용을 다루고 있습니다. 클래스 체계 표준 자바 관례에 따르면 가장 먼저 변수 목록이 나와야 합니다. 정적 공개 상수, 정적 비공개 상수, 비공개 인스턴스 변수 순으로 나열합니다. 공개 변수가 필요한 경우는 거의 존재하지 않습니다. 테스트는 아주 중요한 구성 중 하나이기에 테스트를 위해 protected로 선언하거나 package-private를 사용하기도 합니다. 하지만 이를 사용하기 전 비공개로 할 수 있는가에 대해 끊임없이 고민이 필요합니다. 클래스도 함수와 마찬가지로 작아야만 합니다. 그렇다면 클래스의 크기는 얼마나 작아야 ..
애플리케이션 실행에는 무수히 많은 변수가 존재합니다. 이러한 변수 상황을 효율적으로 대처하기 위해 테스트의 중요성은 시간이 지날수록 꾸준히 증가하였고 지금은 TDD라는 용어까지 나오며 테스트가 필수적으로 되었습니다. 형식 맞추기로 테스트를 급하게 작성해서는 안 되고 제대로 된 테스트 케이스를 작성할 수 있도록 테스트에 많은 시간을 투자해야 합니다. TDD 법칙 세 가지 첫째. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 셋째. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 깨끗한 테스트 코드 유지하기 지저분한 테스트 코드는 개발 비용을 증가시킵니다. 핵심 로직에 투자해야 할 시간을 ..
프로젝트의 하나로 앱 개발을 진행할 때 앱에 필요한 모든 소프트웨어를 직접 개발하지는 않았습니다. 규격화 되어 있는 오픈 소스를 이용하고 다른 팀의 API를 사용하고 필요에 의해 비용을 지불하고 라이선스를 획득하여 사용하기도 합니다. 외부의 코드를 사용하게 되면 내부의 코드와 적절히 조화를 이루도록 하는 것이 중요한 부분인데 이번 장에서는 이러한 경계를 깔끔하게 처리하는 기법과 기교를 설명하고 있습니다. 외부 코드 사용하기 코드 제공자는 적용성과 범용성을 넓히기 위해 최대한 노력합니다. 하지만 이러한 적용성과 범용성이 단점으로 다가오는 상황도 존재합니다. 너무 많은 기능을 제공해버리면 클라이언트에서 필요하지 않은 기능까지 제공해버리게 됩니다. 이를 적절히 캡슐화하여 기능을 제한하면 클라이언트로서 편할 것..