230918클린코드7주차: 14장 점진적인개선
이번 주차에는 14장 "점진적인 개선"을 읽었습니다.
처음에 저자는 명령행 인수 분석을 위한 깔끔한 클래스인 "args"를 보여주고,
깔끔한 클래스가 어떤 지저분한 모양새로 시작헀으며, 깔끔해질 때까지 거친 과정을 볼 수 있었습니다.
14장 점진적인 개선
명령행 인수부터 막혔습니다.
명령행 인수가 무엇인지 몰라서 arg 클래스가 어떤 역할을 하는 것인지 이해하기 어려웠습니다.
찾아보니 자바에서는 한 파일의 코드가 "public void main"으로 선언된 클래스로 시작하고,
해당 main 클래스의 초기화 인수를 편집기나 여러 환경 설정도구를 통해 넣을 수 있다고 합니다.
그 인수가 바로 명령행 인수입니다.
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');
executeApplication(logging, port, directory);
} catch (ArgsException e) {
System.out.print("Argument error: %s\n", e.errorMessage());
}
}책에서 소개하는 args클래스는 첫 번째 인자로 텍스트 패턴, 두 번째 인자로 명령행 인수를 넣어 초기화합니다.
만약 명령행 인수가 해당 패턴에 맞지 않다면 예외를 던집니다.
해당 패턴과 일치하면, 인스턴스가 정상적으로 생성됩니다.
인스턴스 내부 메서드의 여러 메서드는 명령행 인수에
어떤 패턴의 문자들이 들어있는지 확인해 주는 책임을 수행합니다.
소개가 상당히 장황하네요.
그냥 특정 문자열에 대해, 여러 가지 패턴매칭을 해볼 수 있는 클래스였습니다.
저자가 루비로 새로 짠 args 클래스:
https://github.com/unclebob/rubyargs/blob/master/args.rb
자바 arg 클래스
https://github.com/ludwiggj/CleanCode/blob/master/src/clean/code/chapter14/refactored/first/Args.java
굉장히 많고 긴 자바 코드를 보면서 살짝 압도당했지만,
여러 번 반복해서 읽고 나니까 그래도 얼추 흐름은 잡을 수 있었습니다.
가장 인상적인 부분은 다음 3가지였습니다.
1. 추상 클래스나 인터페이스를 사용하지 않은 것 같습니다.
중간에 여러 가지 수많은 프로퍼티를 생성했다가 지우는 과정을 보여줍니다.
이는 설계 요소를 정해놓은 추상 클래스가 존재하지 않음을 암시하는 것 같았습니다.
객체지향 코드를 많이 보지 못해서, 구현 코드를 바로 작성하는 것은 일반적이지 않다고 생각했습니다.
하지만 추상 클래스를 반드시 만드는 게 더 특이한 케이스인가 봅니다.
2. 저자는 TDD를 사용하여 클래스를 구현하였습니다.
개선 전의 코드는 엉망으로 보여도 먼저 만들고자 하는 기능은 정확히 이해하고,
테스트 슈트를 작성하여 만든 것임을 알 수 있었습니다.
역시 기능과 생김새는 별개네요.
3. errorMessage도 형식이 정해져 있습니다.
마지막 부분에 나오는 errorMessage를 종류별로 형식별로 엄청 많이 만들어놓아서,
에러와 예외처리를 하는 부분까지 사전에 정해놓았습니다.
에러와 예외처리를 코드의 실행부 맨 바깥 스코프에서 처리하는
외부에서 처리하는 패턴을 사용한다고 해서, 예외처리를 결코 대충 하지 않는다는 것을 느꼈습니다.
------
이번 14장을 마지막으로, 클린코드의 부록을 제외한 본문을 전부 읽었습니다.
저의 코드를 보는 감각이 성장을 했는지는 잘 모르겠지만,
그래도 못생긴 코드를 보면 예전과는 다르게 단순한 느낌이 아닌 논리를 들어
어떤 사유로 못생겼는지 조목조목 댈 수 있게 된 거 같습니다.
앞으로의 제 깃허브 레포지토리의 방향도 "점진적인 개선"으로 잡아야겠습니다.
이 책은 "자바" 코드를 보여주었고, 저는 현재 "자바스크립트"를 주력으로 하고 있기에
클린코드를 읽기 시작하면서 더러운 코드의 예시를 찾아보려고
예전에 묵혀놓았던 프로젝트들의 코드를 조금조금 살펴보기 시작했는데,
그것만으로도 충분히 큰 의미가 있는 것 같습니다.
함께 나눠볼 만한 이야기
1. errorMessage도 컨벤션이 있나요?
저자는 상당히 풍부하고 잘 정의된 방식의 예외, 오류처리 코드를 작성했습니다.
일반적으로 메시지까지 컨벤션을 만드는 것이 옳은가요?
2. 남의 코드를 볼 때, 어떤 곳을 중점으로 리뷰해야 할까요?
이번에 TS과제 코드와 조원들의 코드를 살펴보면서,
이것들을 전부 리뷰하기엔 굉장히 방대하다는 것을 느꼈습니다.
여러분들이 리액트 코드에서 중점적으로 체크하는 부분이 있을까요?
3. 추상클래스 / 인터페이스 구현을 생략하는 경우가 많은가요?
객체지향 책에선 구체적 클래스는 추상 클래스나 인터페이스를 상속받게 하여 구현하라고 합니다.
그런데 구현 대상이 한 개뿐이면 생략하는 경우도 많은지 궁금합니다.
저는 일반적으로, 앉은자리에서 전부 메서드를 만들 수 있는 수준의 작은 클래스가아니라면,
인터페이스나 추상클래스를 먼저 만들어서 해야 할 일을 리마인드 시키는 역할로 사용하고 있었습니다.
생각해 보니 제코드에서도 구현이 아닌 선언 부분만 만들어주는 건 엔티티 코드가 유일한 것 같습니다.
추상적인 틀은 어떤 경우에 도입을 하고, 어떤 경우에는 바로 구현을 하면 좋을까요?
'CS공부(개념) > 독후감' 카테고리의 다른 글
| 클린코드 6주차: SerialDate 리팩터링, 냄새와 휴리스틱 (0) | 2023.09.12 |
|---|---|
| 클린코드 5주차: 동시성, 그리고 JUnit (0) | 2023.09.05 |
| 클린코드 4주차: 단위테스트, 시스템, 그리고 창발성 (0) | 2023.08.28 |
| 클린코드 3주차: 예외처리, 경계 그리고 클래스 (0) | 2023.08.22 |
| 클린코드 2주차: 주석, 형식맞추기, 그리고 객체와 자료구조 (0) | 2023.08.15 |