잊을 때쯤 한번 다시 읽어봐야할 Clean code에 관하여 (점진적인 개선)

• 이 장의 내용을 한줄로 요약하자면 멋진 코드는 절대 한번에 나오지 않는다. 오히려 한번에 내보내려고 하면 안 된다.
  • 1차 초안 쓰고 2차 초안을 만들고 그리고 최종안을 만드는 것처럼 공예하듯 만들어야 한다. 
  • 일단 프로그램이 돌아간다고 다음 업무로 넘어가선 안 된다. 
• 점진적인 개선 이 파트 자체가 책에선 양이 엄청난데 이건 코드가 대부분이라 긴거 

 

 

• 인자 값을 받아서 Parse하는 함수를 따로 만들어져있고 일단 변수로 할당하고 parse로 따로 다시한번 돌린다. 
  • parse도 변수들을 전부 parse해버리는 함수임 
• 변수도 타입별로 맵이 전부 나뉘어 져있었음 
• 딱 저번에 말했던 지나치게 짜잘하게 function으로 나누면서 갯수가 너무 많아져버림 
• 그렇다고 제대로 나눈것도 아녀 한 함수에 여러 기능을 부여한 경우도 있음 
• argument을 parse하는 함수들이 여러개 있으며 type만 서로 다름 
  • 이러한 상황에서 argument가 type별로 계속 추가될 때마다 점점 요단강 건너기 시작하는 코드를 보여줌 
  • 1개의 argument를 넣어줄 때마다 3곳을 바꿔줘야 했다. 
• 그래서 이러한 상황에 리팩토링을 시작하였고 저자는 아래와 같이 진행함

1. TDD를 사용하였음
   • 리팩토링은 절대 시스템을 망가뜨리는 변경을 허용하면 안 되기 때문에 TDD를 통해 지속적으로 문제가 없는지 파악하기 위해선 언제든 실행이 가능한 테스트 코드가 필요하였다. 
   • 저자는 그래서 테스트 코드를 먼저 구현하고 변경을 적용할 때마다 테스트 코드를 통과하면 올바로 동작한다 판단하고 넘어갔다. 
2. Interface를  Class를 만들어 type별로 동일하게 돌아가는 function과 변수를 통합
   
   • 이 때 동일하게 반드시 들어가는 함수는 interface에 넣어준다
     setBoolean, setString으로 나누어져있던걸 set으로 통합 
   • 그리고 이렇게 하면 예외처리 역시 Inerface를 상속받는 class들 안에 넣어 코드 관리가 가능해진다. 
3. 이 과정 속에서 변수 타입을 바꿔주거나 할 때 마다 Test들을 계속 돌리며 파악하였음
4. 예외 처리는 아예 밖으로 빼버림  

 

• 코드를 수정하고 나서는 새로운 인수 유형을 추가하는 방법은 ArgumentMarshaler에서 새 클래스를 파생해 생성하고 get000을 추가한 후 parseSchemaElement함수에 새 case문 만 추가하면 끝이 나게 된다. 
• 이 장은 엄청 긴데 긴 이유가 코드를 계속 반복하며 어떻게 바꿨는지 말해줘서이다. 결국 크게는 어떻게 바꿨는지 감을 보고 배우면 되는디 내가 느낀건 아래와 같다

 

• 저자가 말한 아 여기서 기능 추가하거나 새로운 업데이트 내용을 넣으면 코드가 일명 요단강을 건넌다는 시점이 있을 때 과감히 스탑하고 리팩토링하고 개발하는 부지런함 
• 철저한 TDD가 받춰줘야 리팩토링이 가능하다. 그냥 해선 안 된다.
• 확실한 역할의 분리를 생각하자 그냥 쪼개지 말고 예컨데 책에 나오는 1차 초안 코드에서 errorMessage function처럼 오류 메시지 형식까지 책임지는 그런 기능을 맡아선 안 되는 것 
  
  • 그래서 밖으로 뺀거긴한데 어떻게 뺄지에 대해서는 자유롭게.. 근데 빼는건 무튼 맞음