Software Engineering Note

이 장에서는 명령행 인수(argument) 구문분석기를 구현하고, 점진적으로 개선하는 것을 보여준다. 코드가 대부분이라 여기에 적을수는 없지만 모두 타이핑 해봤다. (진짜다..) 따라하면서 느낀점은, 테스트를 꼼꼼하게 작성하고 개선을 정말 조금씩 한다는거다. 나는 보통 한번에 막 고치는 스타일인데 급한 성격을 가라앉히고 천천히 개선하는 습관을 들여야겠다. 읽다가 옳다구나! 하는 문구정도만 정리해본다. 지난 경험에서 얻은 교훈=> 프로그래밍은 과학보다 공예에 가깝다는 사실. 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다. 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. => 돌아올 수 없는 강을 건너지 말고 조금씩 개선. TDD를 ..

착실하게 따르기만 해도 우수한 설계가 나오는 간단한 규칙! 켄트 벡은 다음 규칙을 따르면 설계는 "단순하다"고 말한다. (중요도 순) 1. 모든 테스트를 실행한다.2. 중복을 없앤다.3. 프로그래머의 의도를 표현한다.4. 클래스와 메소드 수를 최소로 줄인다. 모든 테스트를 실행하라 테스트가 불가능한 시스템은 검증도 불가능 => 검증이 불가능한 시스템은 절대 출시하면 안된다. 테스트가 가능한 시스템을 만들려고 애쓰면 설꼐 품질이 더불어 높아진다. 크기가 작고 목적 하나만 수행하는 클래스가 나온다. SRP를 준수하는 클래스는 테스트가 훨씬 쉽다. 테스트 케이스가 많을수록 개발자는 테스트가 쉽게 코드를 작성한다. 따라서 철저한 테스트가 가능한 시스템을 만들면 더 나은 설계가 얻어진다. (선순환) 리팩터링 코드..

시스템 제작과 시스템 사용을 분리하라 제작(construction) 과 사용(use)는 다르다. 소프트웨어 시스템은 준비과정과 런타임 로직을 분리해야 한다.=> 관심사의 분리 객체를 생성하는 것과 객체를 사용하는 것을 분리해야 한다는 것이 주된 이야기 - Main 분리 생성관련 코드는 모두 main 또는 main이 호출하는 모듈로 옮기고 나머지 시스템은 이미 객체가 존재한다고 가정한다. main -> application (application은 main이나 객체가 생성되는 과정을 전혀 모른다.) - 팩토리 application에서 객체를 생성하는 시점을 정하고 싶을때가 있다. 이런때는 팩토리를 구현에서 application 쪽으로 넘겨준다. - 의존성 주입 (스프링 프레임워크의 DI를 생각하면 된다) ..