[클린코드] 28일차~34일차 - 돌아가는 프로그램에 그치기 보단 점진적 개선 필요 / TDD 유지

[클린코드] 28일차~31일차 - 돌아가는 프로그램에 그치기 보단 점진적 개선 필요

클린코드 28일차 (p. 246 ~ 254 (14장) ) : 돌아가는 프로그램에 그치기 보단 점진적 개선 필요

클린코드 29일차 (p. 255 ~ 272 (14장) ) : TDD 기법 사용

클린코드 30일차 (p. 273 ~ 288 (14장) ) : 계속 통과하는 Test... 가 옳음을 ..!

클린코드 31일차 (p. 288 ~ 295 (14장) ) : 점진적으로 개선하기 == TDD 유지하기

클린코드 32일차 (p. 296 ~ 304 (14장) ) : 리팩토링은 루빅 큐브 맞추기와 비슷하다.

클린코드 33일차 (p. 305 ~ 310 (14장) ) : same old same old

클린코드 34일차 (p. 311 ~ 322 (14장) ) : 길고 긴 14장의 끝 ... "나쁜코드는 썩어문드러진다."

14장 점진적인 개선 

이 장은 출발은 좋았으나 확장성이 부족했던 모듈을 얘기한다. 그리고 모듈을 개선하고 정리를 해보자.

---

 

프로그램을 짜다 보면 종종 명령행 인수의 구문을 분석할 필요가 있다.

 

편리한 유틸리티가 없다면 main 함수로 넘어오는 문자열 배열을 직접 분석하면 된다.

 

'명령행 인수'가 무엇인가 하면 익숙한듯한 String[] args 이다. (String[] arg = main 함수로 넘어오는 문자열 배열)

 

편리한 유틸리티가 없으니 직접 만든다고 치고 새로 짤 유틸리티를 Args로 부르자.

 

public class ExampleArgs {
    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.printf("Argument error: %s\n", e.errorMessage());
        }
    }
}

 

0. 정말 점진적인 개선이 보이는 코드 .. 

 

1. 매개변수 두 개("l,p#,d*", args)로 Args 클래스의 인스턴스를 만들었다.

- 첫 번째 매개변수 : 형식 또는 스키마를 지정하는 "l,p#,d*"

- 두 번째 매개변수 : main으로 넘어온 명령행 인수 배열 자체

 

2. 생성자에서 ArgsException이 발생하지 않는다면 명령행 인수 구문이 성공적으로 분석되었다는 것.

 

3. 명령행 인수 구문이 성공적으로 분석되었으면 Args 인스턴스에 질의를 던져도 ok. (executeApplication( ... ))

 

4. 인수 값을 가져오기 위한 getBoolean, getInt, getString 메서드 사용.

 

1. Args 구현

 

단순한 개념을 구현하는데 코드가 너무 많이 필요하다 .....

 

Because 장황한 언어인 자바를 사용하는 탓 ...

 

자바는 정적 타입 언어라 타입 시스템을 만족하려면 많은 단어가 필요로 한다.

코드를 한 번 더 읽어보길 바란다. -> 이름을 붙인 방법, 함수 크기, 코드 형식에 각별히 주목 ..!

 

2. 어떻게 짰는가 ?  ---- 계속 고침.

"수십여년 동안 쌓아온 경험에서 얻은 교훈이라면, 프로그램은 과학보다 공예에 가깝다 .."

 

깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다.

 

글쓰기와도 같아서 먼저 1차 초안을 쓰고, 2차 초안을 만들고, 계속 고쳐 최종안을 만들자.

 

신참 프로그래머들은 무조건 돌아가는 프로그램을 목표로 잡는다. '돌아가면' 다음 업무로 넘어간다. (그러면 안 된다는 말을 하고 싶은거겠지 ..?) 경험이 풍부한 전문 프로그래머는 이런 행동이 전문가로서 자살 행위라는 사실을 잘 안다..

 

즉, 돌아가는 프로그램만 만들면 자살행위나 다름없다. 깨끗한 코드를 위해 계속 고쳐야 한다. 

 

3. 계속 고침 보단 .. 점진적으로 개선하다.

프로그래밍을 망치는 가장 좋은 방법 중 하나는 '개선'이라는 이름의 탈을 쓴 '구조 뒤집기'이다.

 

'개선' 전과 똑같이 프로그램을 돌리기 힘들다..

 

TDD(Test-Driven Development) 기법을 사용한다.

 

즉, 변경을 가해도 개선 전과 똑같이 프로그램을 돌릴 수 있다는 전제가 깔려있어 변경에 용이하다.

 

4. 테스트는 계속해서 성공시켜야 한다.

결국 점진적으로 개선하기는 TDD를 유지하기와 동일하다.

 

계속적인 자잘한 변경에 대해서도 테스트를 실행하고 성공시켜야한다.

 

결론

나쁜 일정, 요구사항, 팀 역학까지 모두 다시 짤 수 있지만 코드는 썩어 문드러진다.

 

나쁜 코드만큼 개발 프로젝트의 악영향을 줄 수가 없다. 나쁜 코드도 깨끗한 코드로 개선할 수 있다.

 

물론 오래된 의존성을 찾아내 수정하기까진의 시간과 인내심은 필수 불가결하다.

 

반면 좋은 코드의 기조를 가지고 처음부터 짠다면 유지하기란 상대적으로 쉽다.

 

"단순히 돌아가는 코드에 그치지 않고, 좋은 코드를 만들자."

 

만약 나쁜 코드를 만났다면 설계와 구조를 개선할 시간을 내자. 그에 대한 비용 측정이 그리 크지 않을 수도 ? 개선하자.

 

---

 

- 클린코드 28일차 일기 -

요즘 약간 변태같이(효율적으로.. 주석없이 .. 말끔하게 ..) 코드짜는걸 좋아하는데 프로그램은 과학보다 공예에 가깝다는 말이 너무 웃기고 이해가 간다.

 

- 클린코드 30일차 일기 - 

가독성이 정말 안 좋다..

 

- 클린코드 32일차 일기 - 

꺼진 코드도 다시 보자.. (?)