Juwon

17장 냄새와 휴리스틱 Refactoring의 저자 마틴 파울러는 다양한 코드 냄새를 거론한다. 이번 챕터에서는 마틴 파울러가 맡은 냄새에 저자가 맡은 냄새를 추가헀다. 이번에 나올 목차들을 다양하게 검토하고 리팩터링 하는 챕터. 프로그램을 수정할 때마다 나는 왜?라는 자문한 다음 그 답을 기록했다. 목차 주석 환경 함수 일반 자바 이름 테스트 17-1. 주석 부적절한 정보 변경 이력, 이슈 추적 등 다른 시스템에 저장할 정보는 주석으로 적절하지 못하다. 작성자, 최종 수정일, SRP 번호와 같은 정보만 주석으로 남긴다. 주석은 코드와 설계에 기술적인 설명을 부연하는 수단이기 때문에 필수적인 정보만 넣어준다. 쓸모없는 주석 쓸모 없는 주석은 넣지 않는게 가장 좋다. 무의미한 주석은 삭제하는 것이 좋다. ..

16장 SerialDate 리펙터링 JCommon 라이브러리와 SerialDate 클래스를 알아보며 전문가의 입장에서 깨끗한 코드 작성 방법을 알아볼 수 있는 챕터. 이 챕터( 책 )에서 수행하는 분석은 악의나 자만과는 거리가 멀다는 것을 명심하자. 비판이 있어야 발전이 가능하다. 다른 직업들도 하고있는 것들이다. 프로그래머들도 알아야한다. 코드 리뷰는 우리 모두가 편안하게 여겨야할 행동이고 다른 사람이 내게 해준다면 감사히 반겨야 할 행동이다. 목차 첫째, 돌려보자 둘째, 돌려보자 16-1. 첫째, 돌려보자 SerialDateTests는 단위 테스트 케이스 몇개를 포함하지만 모든 경우를 점검하지 않고 있다. 테스트 코드에서 전혀 실행하지 않는 코드도 존재한다. 테스트 커버리지는 대략 50% 정도이다. ..

15장 JUnit 들여다보기 Junit을 작성하고 테스트 코드를 통해 리펙토링하는 과정을 보여주는 챕터 Junit 프레임워크에서 코드를 가져와 리뷰하며 바람직한 코드 작성방법을 보여준다. 목차 JUnit 프레임워크 15-1. JUnit 프레임워크 JUnit은 저자가 많지만 켄트 백, 에릭 감마가 기초를 구현하였다. 공통된 접두어를 제거하자 캡슐화 되지 않은 조건문이 존재한다면 조건문을 캡슐화해서 메서드로 뽑아내 적절한 이름을 붙이자. 이름은 명확하게 붙이자 부정문이 긍정문보다 이해하기 약간 어렵다. 부정문을 긍정문으로 표현하자. 함수의 이름으로 효과를 명확하게 설명하자 함수는 한 가지 일만 해야 한다 함수는 일관적으로 사용하자 정확한 이름을 사용하라 숨겨진 시각적인 결합 일관성을 유지하자 경계 조건을 캡..

14장 점진적인 개선 점진적인 개선에 대한 사례를 보여주는 챕터. 시작은 좋지만 확장성이 부족한 모듈을 개선하고 정리 했던 과거 일로, Args 클래스를 작성한 저자의 코드를 예를 들어 하고싶은 말이 무엇인지 알아야 한다. 목차 Args 구현 어떻게 짰느냐고? Args: 1차 초안 그래서 멈췄다 점직적으로 개선하다 String 인수 14-1. Args 구현 public static void main(String[] args) { try { Args arg = new Args("l,p#,d*", args); boolean logging = arg.getBoolean('l'); int port = arg.getInt('p'); String directory = arg.getString('d'); execut..

13장 동시성 객체는 처리의 추상화다. 스레드는 일정의 추상화다. 동시성과 깔끔한 코드는 양립하기 어렵다. 여러 스레드를 동시에 돌리는 이유와 여러 스레드를 동시에 돌리는 어려움에 대한 대처 방법과 깨끗한 코드를 작성하는 방법을 알려주는 챕터. 동시성을 테스트하는 방법과 동시성의 문제점을 이야기한다. 깨끗한 동시성은 복잡한 주제로 이 챕터에서는 간략히 소개만 하는 것이다. 목차 동시성이 필요한 이유? 미신과 오해 난관 동시성 방어 원칙 단일 책임 원칙 따름 정리: 자료 범위를 제한하라 따름 정리: 자료 사본을 사용하라 따름 정리: 스레드는 가능한 독립적으로 구현하라 라이브러리를 이해하라 스레드 환경에 안전한 컬렉션 실행 모델을 이해하라 생산자-소비자 읽기-쓰기 식사하는 철학자들 동기화하는 메서드 사이에 ..

11장 시스템 복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다. 소프트웨어 시스템은 준비 과정과 준비 이후 런타임 로직을 분리해야 한다. 시스템 수준에 있어서 여러가지 깨끗함을 유지하는 방법, 기법을 알려주는 챕터. 목차 도시를 세운다면? 시스템 제작과 시스템 사용을 분리하라 Main 분리 팩토리 의존성 주입 확장 횡단(cross-cutting)관심사 자바 프록시 순수 자바 AOP 프레임워크 AspectJ 관점 테스트 주도 시스템 아키텍처 구축 의사 결정을 최적화하라 명백한 가치가 있을 때 표준을 현명하게 사용하라 시스템은 도메인 특화 언어가 필요하다 11-1. 도시를 세운다면? 도시를 건설하고 관리하는 것에 한 사람 만으로는 충분하지 않지만 그래도 도..

10장 클래스 지금까지는 코드 행과 코드 블록 그리고 함수를 올바르게 작성하는 방법과 구현하는 방법에 초점을 맞춘 챕터였다. 이번 챕터에서는 코드의 표현력과 구성하고 있는 함수에서 좀 더 차원 높은 단계까지의 깨끗한 클래스를 작성하는 방법을 다룬다. 목차 클래스 체계 캡슐화 클래스는 작아야 한다! 단일 책임 원칙 응집도 응집도를 유지하면 작은 클래스 여럿이 나온다 변경하기 쉬운 클래스 변경으로부터 격리 10-1. 클래스 체계 클래스를 정의하는 표준 자바 관례를 보았을 때 순서이다. 먼저 변수 목록이 나온다. 정적 공개 상수 ( static public 상수 ) 정적 비공개 변수 ( static private 변수 ) 비공개 인스턴스 변수 ( private instance 변수 ) 공개 변수( public..

9장 단위 테스트 제대로 된 테스트 케이스를 작성하는 방법과 작성 방법을 알려주는 챕터. 대다수의 프로그래머에게 단위 테스트란 자기 프로그램이 ‘작동한다'는 사실만 확인하는 일회성 코드에 불과했다. 애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 많아지며 늘어나는 추세이다. 제대로 되어진 좋은 테스트 케이스를 작성하는 것이 중요하다. 목차 TDD 법칙 세가지 깨끗한 테스트 코드 유지하기 테스트는 유연성, 유지보수성, 재사용성을 제공한다 깨끗한 테스트 코드 도메인에 특화된 테스트 언어 이중 표준 테스트 당 assert 하나 테스트 당 개념 하나 F.I.R.S.T 9-1. TDD 법칙 세가지 TDD의 세가지 법칙을 지키면 개발과 테스트를 30초 주기로 묶을 수 있다. 실패하는 단위 테스트 를 ..

8장 경계 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 오픈소스를 이용하거나 사내에 다른 개발팀이 제공하는 컴포넌트를 이용하거나, 어떤 식으로든 이 외부코드를 우리 코드에 깔끔하게 통합해야 한다. 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴본다. 목차 외부 코드 사용하기 경계 살피고 익히기 log4j 익히기 학습 테스트는 공짜 이상이다 아직 존재하지 않는 코드를 사용하기 깨끗한 경계 8-1. 외부 코드 사용하기 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려 애쓴다. 더 많은 환경에서 돌아가야 더 많은 고객이 구매하기 때문 반면 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. 이러한 차이로 시스템 경계에 문제가 생길 소지가 많다. java.ut..

7장 오류 처리 깨끗하고 튼튼한 코드에 다가가는 오류를 처리하는 기법과 고려 사항을 소개하는 챕터. 오류 처리는 프로그램에 반드시 필요한 요소 중 하나이다. 무언가 잘못될 가능성은 늘 존재한다. 무언가 잘못되면 바로 잡을 책임은 우리 프로그래머에게 있다. 오류 처리 코드로 인해 프로그램의 논리를 이해하기 어렵다면 깨끗한 코드가 아니다. 목차 오류 코드보다 예외를 사용하라 Try-Catch-Finally 문부터 작성하라 미확인( unchecked ) 예외를 사용하라 예외에 의미를 제공하라 호출자를 고려해 예외 클래스를 정의하라 정상 흐름을 정의하라 null을 반환하지 마라 null을 전달하지 마라 결론 7-1. 오류 코드보다 예외를 사용하라 예외 처리를 지원하지 않는 언어의 경우 호출자에게 호류 코드를 반..