[전호영] 14장: 점진적인 개선

14장/전호영.md

@@ -0,0 +1,44 @@
+# 다시 읽어 볼 내용
+
+- 프로그래밍은 과학보다 공예(craft)에 가깝다.
+
+목록 14-8 코드가 안좋은 이유
+
+```java
+public class Args {
+    private String schema;
+    private String[] args;
+    private boolean valid = true;
+    private Set<Character> unexpectedArguments = new TreeSet<Character>();
+    private Map<Character, Boolean> booleanArgs = new HashMap<Character, Boolean>();
+    private Map<Character, String> stringArgs = new HashMap<Character, String>();
+    private Map<Character, Integer> intArgs = new HashMap<Character, Integer>();
+    private Set<Character> argsFound = new HashSet<Character>();
+    private int currentArgument;
+    private char errorArgumentId = '\0';
+    private String errorParameter = "TILT";
+    private ErrorCode errorCode = ErrorCode.OK;
+
+}
+```
+
+- 'TILT'와 같은 희한한 문자열
+- HashSets, TreeSets, try-catch-catch 블록 등 지저분한 코드가 됨.
+- 여러 Map, Set 관리
+- 인수 추가 시 여러 부분에 수정이 필요함
+
+ArgumentMarshaler 추가
+
+- 모든 타입이 유사한 패턴을 가지기에 이를 하나의 클래스로 만들어 관리하기로 함.
+- 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위이다.
+- 점진적으로 개선을 해나가야 함
+- 하나씩 고치며 테스트를 진행함.
+    - 테스트가 실패하면 다음 변경으로 넘어가기 전에 오류를 수정했다.
+- ArgumentMarshaler 클래스에 전체를 넣고 나서 ArgumentMarshaler 파생 클래스를 만들어 코드를 분리할 작정이다.
+- 리팩터링을 하다보면 코드를 넣었다 뺐다 하는 사례가 아주 흔하다. 단계적으로 조금씩 변경하며 매번 테스트를 돌려야 하므로 코드를 여기저기 옮길 일이 많아진다.
+
+# 느낀점
+
+지저분한 코드를 개선하는 과정을 볼 수 있었다. 일단 코드를 작성하고, 그 안에서 반복이 되는 부분을 발견한 뒤 이를 하나의 클래스로 묶었다. 이건 SRP가 적용된 좋은 사례라고 생각한다.
+ArgumentMarshaler 클래스를 만들자, 새로운 타입이 필요할 때, 기존 코드 수정 없이 새 타입을 넣을 수 있게 되었다. 이는 OCP를 지키는 것 같다. 자바의 특징인지 모르겠지만, 코드가 너무 장황했고,
+그래서 읽기 쉽지 않았다. Test가 있었기에, 수정 시 틀린 부분을 바로바로 알아챌 수 있었다. 이런 부분을 보면 테스트의 중요성을 다시 한번 느낀다. TDD가 좋은 것인가? 에 대해선 잘 모르겠지만, Test는 매우 중요하다고 생각한다.