Sadie의 개발일기

리팩터링 과정 2 일반적으로 기반 클래스(부모 클래스)는 파생 클래스(자식 클래스)를 몰라야 바람직 => ABSTRACT FACTORY 패턴을 적용해 DayDateFactory를 생성 => DayDate 인스턴스를 생성하는 클래스를 분리. createInstance 메서드를 좀 더 서술적인 makeDate라는 이름으로 변경 변수를 적절한 클래스로 옮김 상수를 enum으로 변경 변수 이름만으로 의미가 확실한 주석 삭제 사용하지 않는 변수, 메서드 등 제거 변수가 사용되는 위치에 가깝게 옮김 이름 변경 기본 생성자 제거 final 키워드 제거 로직을 옮기며 클래스 내의 일부 코드가 독자성을 갖고 커지면 클래스에서 빼내 별도의 소스 파일로 분리 서술적인 코드로 변환하며 가독성 높임 복잡한 알고리즘의 경우 임시..

SerialDate 리팩터링 JCommon 라이브러리의 org.jfree.date 패키지 내에 있는 SerialDate 클래스를 탐험한다. SerialDate : 날짜를 표현하는 자바 클래스. 시간대에 무관하게 날짜를 표현하기 위한 클래스다. 첫째, 돌려보자 테스트 케이스 점검 기존 테스트 케이스가 모든 경우를 점검하지 않음. => 코드 커버리지 분석 도구인 클로버를 이용해 조사한 결과, 실행 가능한 문장 중 약 50%만 단위 테스트가 실행됨 +테스트 케이스의 많은 코드가 주석으로 처리됨(실패한 테스트 케이스) => 독자적으로 단위 테스트 케이스 구현 -> 코드 커버리지 대략 92% 달성 => 주석으로 뺀 코드 점검 => 통과해야 할 테스트들을 살리고, 테스트 케이스를 통과하도록 디버깅. 둘째, 고쳐보자..

JUnit 들여다보기 리팩토링 과정 함수 사용방식이 일관적이지 못한 부분 수정 함수에서 마지막 두 줄은 변수를 반환하지만 첫째 줄과 둘째 줄은 반환값이 없음 => 각각 함수를 변경해 무언가를 반환하도록 수정 부정확한 멤버 변수 이름 변경 prefix/suffix 변수가 실제로는 색인 위치를 나타내고 있으므로 각각 뒤에 -Index를 추가 숨겨진 시간적인 결합 외부에 노출 findCommonSuffix 함수는 findCommonPrefix가 prefixIndex를 계산한다는 사실에 의존 => 만약 findCommonSuffix와 findCommonPrefix를 잘못된 순서로 호출하면 원인을 찾기 어려움 => 시간 결합을 외부에 노출하고자 prefixIndex가 findCommonSuffix의 인수로 넘어가..

JUnit 들여다보기 JUnit : 유명한 자바 프레임워크. 구현이 잘 되어 있음. JUnit 프레임워크 JUnit의 ComparisonCompactor 모듈을 살펴 본다. -> 두 문자열을 받아 차이를 반환하는 코드. ex) ABCDE와 ABXDE를 받으면 를 반환 코드를 살펴보면 잘 분리되었고 표현력이 적절하며 구조가 단순함. ComparisonCompactor 모듈을 살펴 보고 보이스카우트 규칙에 따라 리팩토링해 보는 시간을 가진다. 리팩토링 과정 멤버 변수 앞에 붙인 접두어 f 제거 오늘날 사용하는 개발 환경에서는 변수 이름에 범위를 명시할 필요가 없으며 접두어 f는 중복되는 정보임. 캡슐화되지 않은 조건문 캡슐화 의도를 명확히 표현하기 위해 조건문을 메서드로 뽑아내 적절한 이름을 붙인다. 이름이..

ArgsException 모듈을 분리해 Args의 코드를 크게 줄이고 ArgumentMarshaler 클래스들을 각자 파일로 옮김 -> 코드를 이해하고 보수하기 쉬워졌음. 소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다. 결론 나쁜 코드는 개발 프로젝트에 무엇보다도 악영향을 미치며 점점 무게가 늘어나 팀의 발목을 잡는다. 오래된 나쁜 코드를 개선하려면 상당한 시간과 인내심이 필요함 => 처음부터 코드를 깨끗하게 유지하려는 마음가짐으로 언제나 코드를 깔끔하고 단순하게 정리하자.

리팩토링 후 새로운 인수 유형을 추가하기 쉬워짐 -> 새 테스트 케이스를 추가하고, 새 Marshaler 클래스를 작성하고, 새 에러 코드와 get함수를 추가하면 됨 리팩터링 - 예외 처리 분리 예외 클래스를 모두 모아 ArgsException으로 통일 => 잡다한 오류 지원 코드를 ArgsException이라는 독자적인 모듈 안으로 옮겨올 수 있게 됨 => Args 모듈에서 예외/오류 처리 코드를 분리

setArgument 함수에서 유형을 일일이 확인하는 방식에서 set 함수를 적절한 파생 클래스로 내려 호출을 간단하게 만드는 과정 if-else 연쇄문에서 오류 코드를 꺼냄 setBooleanArg 함수부터 모든 책임을 BooleanArgumentMarshaler로 전가하는 식으로 리팩토링 ArgumentMarshaler에 set 메서드 추가 setBooleanArg 제거 -> set함수는 이제 BooleanArgumentMarshaler가 관리 String과 Integer 인수를 다루는 Arg 함수들도 같은 방식으로 변경 인수 유형을 일일이 확인하던 코드 제거 모든 과정은 테스트 코드와 함께하며, 각 단계마다 테스트 케이스들이 정상적으로 통과되는지 확인하며 진행

첫 번째 리팩터링을 끝냈으나, 여전히 지저분한 코드 첫머리의 변수들이 지저분하게 남아 있음 setArgument의 유형을 일일이 확인하는 코드 모든 set 함수 및 이곳저곳에 중복으로 존재하는 오류 처리 코드 -> setArgument 함수에서 유형을 일일이 확인하는 코드를 없애고 ArgumentMarshaler.set만 호출하면 되도록 리팩토링.

String 인수 먼저 각 인수 유형을 처리하는 코드를 모두 ArgumentMarshaler 클래스에 넣고 나서 파생 클래스를 만들어 코드를 분리함. => 프로그램 구조를 조금씩 변경하는 동안에도 시스템의 정상 동작을 유지하기 쉬워지기 때문 테스트 케이스를 통과하는지 지켜보면서 점진적으로 코드를 옮기고, 바꾼 코드로 테스트를 통과하면 기존 코드를 제거하는 행위를 반복한다.

어떻게 짰느냐고? 한 번에 깨끗하고 우아한 프로그램을 내놓는 것은 불가능하다. -> 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다. 코드가 돌아가는 것에 만족하지 않고 점진적인 개선을 해야 한다. Args: 1차 초안 코드는 돌아가지만 엉망이다. boolean 인수만 지원하던 첫 버전은 괜찮았으나, 지원하는 타입을 추가하면서 코드가 복잡하고 엉망이 되어갔다. -> 초기 코드에서 새 인수 유형을 추가하려면 주요 지점 세 곳에다 코드를 추가해야 했기 때문 따라서 기능을 추가하는 것을 멈추고 리팩토링을 시작했다. -> 인수 유형을 다양하지만 모두가 유사한 메서드를 제공하므로 ArgumentMarshaler 클래스를 탄생시켰다. 점진적으로 개선하다 개선이라는 이름 아래 구조를 크게 뒤집는 행..