'자바 웹 프로그래밍 Next Step' 책을 공부중이다.
2장을 실습했으며, 실습 내용 및 느낀점을 기록으로 남긴다.
개요
2장에서는 Junit을 통해 테스트를 자동화하고, 코드를 리팩토링하여 복잡도를 단순화시키는 연습을 한다.
★ 2장의 중요 Point ★
- 메소드가 한 가지 책임만 가지도록 구현한다.
-
인덴트(indent, 들여쓰기) 깊이를 1단계로 유지한다.
인덴트는 while 문과 if 문을 사용할 경우 인덴트 깊이가 1씩 증가한다. -
else를 사용하지 마라.
프로그래밍을 구현할 때 else를 사용하지 않고 프로그래밍 하는 것이 가능하다.
실습 내용
문제
전달하는 문자를 구분자로 분리한 후 각 숫자의 합을 구해 반환한다.
< 조건 >
- 쉼표(,) 또는 콜론(:)을 구분자로 가지는 문자열을 전달하는 경우 구분자를 기준으로 분리한 각 숫자의 합을 반환한다.
(예: " "=>0, "1,2"=>3, "1,2,3"=>6, "1,2:3"=>6) - 앞의 기본 구분자(쉼표, 콜론) 외에 커스텀 구분자를 지정할 수 있다. 커스텀 구분자는 문자열 앞부분의 "//"와 "\n" 사이에 위치하는 문자를 커스텀 구분자로 사용한다.
(예: "//;\n1;2;3"=>6) - 문자열 계산기에 음수를 전달하는 경우 RuntimeException으로 예외 처리해야한다.
실습 - Code by Me
실습 코드는 Git에서 확인 가능하다.
- src/calculator/PracticeCalculator.java
- test/calculator/PracticeCalculatorTest.java
실습 - Code by Book
코드는 Git에서 확인 가능하다.
- src/calculator/StringCalculator.java
- test/calculator/StringCalculatorTest.java
느낀점
Flow Chart를 보면 Code by Book이 훨씬 간결하고, 메소드가 한 가지 역할만 수행하는 것을 확인할 수 있다.
간단한 문제임에도 리팩토링에 따라 로직의 복잡성이 달라진다는 것을 느낄 수 있었다.
반성하자
- Parameter를 믿으면 안된다. Parameter에 대한 Validation 체크는 필수!!
- 숫자 1개만 전달될 경우에는 이후 로직을 타지 않아도 된다.
경우의 수를 생각하며 효율적인 코딩을 하자. - 커스텀 구분자와 콤마(,), 콜론(:)을 함께 사용할 수 있다고 생각했다.
문제를 잘못 이해한 결과이니 코딩 전 요구 사항을 정확히 파악하자. - 커스텀 구분자 뒤에는 "\n" 문자가 오기 때문에 "n" 문자를 기준으로 substring을 하고있다.
커스텀 구분자로 "n"이 올 경우 예상한 결과가 나오지 않을 수 있다.
신기하다
- 테스트 메소드 명에 한글을 입력해도 된다.
메소드에 한글을 사용하는 것에 거부감이 있을 경우, JUnit5에서 제공되는 @DisplayName을 활용하도록 하자. - 보통 프로덕션 코드를 작성한 뒤, 테스트 코드를 작성한다.
이 책에서는 테스트 코드를 먼저 작성하여 예외 상황을 예상한 뒤, 프로덕션 코드를 작성하는 TDD(테스트 주도 개발) 방법론을 사용한다.
함께 보면 좋은 추천 도서
- 테스트 주도 개발: 고품질 쾌속개발을 위한 TDD 실천법과 도구
(1장 공개 자료 : https://goo.gl/2ny56w) - 테스트 주도 개발(Kent Beck 저/김창준, 강규영 역, 인사이트/2004년)
- 리팩토링 : 코드 품질을 개선하는 객체지향 사고법(마틴 파울러 저/김지원 역, 한빛미디어/2012년)
- 손에 잡히는 정규 표현식(벤 포터 저/김경수 역, 인사이트(insight), 2009년)
