Software Engineering Note

클라이언트/서버 예제에서는 단일 스레드로 동작하던 서버를 다중 스레드로 변경하는 것과 코드를 깨끗하게 변경하는 내용을 다룬다. 다중 스레드를 적용하기전에 어플리케이션이 어디서 시간을 보내는지 알아야 한다. I/O - 소켓 사용, 데이터베이스 연결, 가상 메모리 스와핑 기다리기 등에 시간을 보낸다. 프로세서 - 수치계산, 정규표현식 처리, 가비지 컬렉션 등에 시간을 보낸다. 프로세서 연산에 시간을 보내는 프로그램은 스레드를 늘인다고 빨라지지않는다. CPU 사이클은 한계가 있기 때문이다. 다중 스레드 프로그램을 깨끗하게 유지하려면 잘 통제된 몇 곳으로 스레드 관리를 모아야 한다. 아니, 스레드를 관리하는 코드는 스레드만 관리해야 한다. 비동시성 문제까지 뒤섞지 않더라도 동시성 문제는 그 자체만으로도 추적하기..

다양한 코드 냄새에 대한 내용. 수정해야할 부분이 있을때 보통 냄새가 난다는 표현을 한다. 주석 부적절한 정보. 소스코드 관리 시스템, 버그 추적 시스템 등 시스템에 저장할 정보는 주석으로 적절하지 못하다.중복된 주석. 코드만으로 충분한데 굳이 설명을 붙이는것주석으로 처리된 코드를 발견하면 즉각 지워버려라! 소스코드관리 시스템에 어차피 남으니까 환경 빌드는 간단히 한단계로 끝나야 한다. 모든 단위 테스트는 한 명령으로 돌려야 한다. 모든 테스트를 한 번에 실행하는 능력은 아주 근본적이고 아주 중요하다. 함수 너무 많은 인수. 넷 이상은 그 가치가 아주 의심스러우므로 최대한 피한다.플래그 인수. boolean 인수는 함수가 여러 기능을 수행한다는 명백한 증거다. 피할것죽은함수. 아무도 호출하지 않는 함수는..

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

동시성이 필요한 이유 동시성은 결합을 없애는 전략이다. => "무엇"과 "언제"를 분리한다. 구조적 관점: 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 처리량 개선: 응답을 기다리는 웹 정보 수집기, 많은 사용자를 처리해야 하는 시스템 등에서 동시성이 요구됨 동시성에 대한 미신과 오해 동시성은 항상 성능을 높여준다 => 동시성은 "때로" 성능을 높여준다.동시성을 구현해도 설계는 변하지 않는다 => 일반적으로 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다.웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. => 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지 알아야 한다. 동시성에 대한 타당한 생각동시성은 다소 부하를 ..

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

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

클래스는 작아야 한다. 클래스의 크기는 책임의 갯수로 센다. 그리고 클래스당 책임은 "1" 이다. 클래스 이름은 해당 클래스 책임을 기술해야 한다. Processor, Manager .. 이런 이름을 나도 많이 사용하는데 아무래도 영어 실력이 부족해서 더 그런듯책임을 명확하게 하고 클래스 이름을 어떻게 지어야할까 고민이 필요하겠다. 클래스 설명은 if, and, or, but을 사용하지 않고 25 단어 내외로 가능해야 한단다. 단일 책임 원칙 (Single Responsibility Principle) 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다. 많은 책임을 떠안은 클래스들을 우리가 자주 보는 이유? "돌아가는 소프트웨어 -> 깨끗하고 체계적인 소프트 웨어" 이 과정으로 들어가야 하는데 ..

TDD가 보편화 되고있지만, 그 본질에 대하여 하지만 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는좀 더 미묘한 (그리고 더욱 중요한) 사실을 놓쳐버렸다. 그런면도 없지않아 있는듯.. TDD법칙 세가지 첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.둘째 법칙: 컴파일은 실패하지않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 필요한 코드만 작성하는 것이 핵심! 깨끗한 테스트 코드 유지하기 테스트 코드를 깨끗하게 유지해야 한다.깨끗하지 않으면 테스트 코드는 점점 부담이 될 것이므로, 실제 코드를 만드는 시간보다 테스트 코드..

(이 장에서는 주로 외부 라이브러리나 패키지를 사용하는 방법을 다룬다.) 외부코드 사용하기 wrapping 클래스를 만들어 제한된 메소드만을 제공하여 악용할 소지를 없앤다. Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출이 되지 않도록 주의한다. (clear() 같은 메소드로 날릴 수도 있다.) Map 인스턴스를 공개 API의 인수로 넘기거나 반환 값으로 사용하지 않는다. 학습 테스트 외부코드를 이용할 때는 곧바로 우리쪽 코드에 반영해서 구현부터 하지말고 테스트부터 하자. (= 학습테스트) 학습 테스트에 드는 비용은 없다. 어쨌든 API를 배워야 한다. 오히려 필요한 지식만 확보하는 손쉬운 방법이다. (이해도를 높여주는 정확한 실험) 아직 존재하지 않는 코드사..

오류 코드보다 예외를 사용하라 오류 코드를 확인하는 방법은 호출자 코드를 복잡하게 만든다. (if result == YES.. 따위) 함수를 호출한 즉시 오류를 확인해야 하기 때문이다. 오류가 발생하면 예외를 던지는 편이 낫다. => 호출자 코드가 더 깔끔해진다. 논리가 오류 처리코드와 뒤섞이지 않는다. 미확인 예외를 사용하라 (RuntimeException 같은) 확인된 예외는 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다. 최하위 함수를 변경해 새로운 오류를 던진다 -> 선언부에 throws 절 추가 -> 연쇄 수정 발생 결과적으로 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다! 예외에 의미를 제공하라 호출자를 고려해 예외 클래스를 정의하라 외부 API를 사..