실용주의 프로그래머 -1탄

5장 구부러지거나 부러지거나

27. 메타프로그래밍

아무리 뛰어난 천재라도 세부사항에 집착하면 그 재능이 발휘되지 않는 법이다.
- 레비의 8번째 법칙(머피의 법칙)

Key point: 세부사항은 코드에서 몰아내라. 되도록 설정가능하도록 만들어라.

How? :
1.설정시 메타데이터를 이용하라.
2.설정정보 읽는 타이밍은? : 많은 프로그램이 프로그램 시작시 설정정보를 읽는데, 이러면 업데이트 때마다 재시작해야한다. 프로그램이 실행 중에도 설정정보를 리로딩 할 수있도록 만들어라.

메타데이터란? :
데이터에 관한 데이터로,
애플리케이션이 어떻게 실행되어야 하고 어떤 자원을 이용해야 하는지 등을 기술한 것.

28. 시간적 결합

우리는 동시성을 허용할 필요가 있고, 시간이나 순서에 따른 의존성의 결합을 끊는 방법을 생각할 필요가 있다.

Key point: 작업흐름 분석을 통해 동시성을 개선하라.

How? :
UML 활동다이어그램을 사용해 사용자들이 기술해준 작업 흐름을 기록하는 방법이 있다.
우리가 원하는 것은 동시에 일어나도 되는 것은 어떤것이고, 엄격한 순서에 따라 일어나야 하는 것은 어떤 것인지 찾아내는 것이다.

6장 코딩하는 동안 해야할 일들

31. 우연에 맡기는 프로그래밍

개발자인 우리들 역시 지뢰밭에서 일한다.

Key point: 우리는 우연에 맡기는 프로그래밍, 곧 행운과 어쩌다 오는 성공에 의존하는 프로그래밍을 하지 말아야 한다.
대신 의도적으로 프로그래밍 해야 한다.

우연적으로 구현된 코드는 결국에 문서화 되지않은 에러나 특정 조건에서만 돌아가는 경우와 마주치게 된다.
우리는 이 코드를 보고 "지금 잘 작동하는데 괜히 건드렸다 일을 만들필요가 있나?" 생각에 빠지기 쉽다.
그래야할 마땅한 이유를 알려주마.

1) 정말로 제대로 돌아가는 것이 아닐지도 모른다. 우리에게만 그런 것처럼 보일 수도있다.
2) 여러분이 의존하는 조건이 단지 우연인 경우도 있다. 다른 상황(다른 해상도) 에서는 이상하게 작동할지도 모른다.
3) 문서화되지않는 동작은 라이브러리의 다음 릴리스에서 변경될 가능성이 있다.
4) 불필요한 추가 호출은 코드를 더 느리게 만든다.

암묵적인 가정
테스팅이 특히 거짓 원인과 우연적인 결과로 가득 찬 영역이다.
Y의 원인은 X라고 가정하기는 쉽다.
하지만, 가정하지 말라. 증명하라.

How?
1) 언제나 자기가 지금 무엇을 하고 있는지 알아야 한다.
2) 완전히 이해하지못한 애플리케이션을 빌드하거나 익숙하지않은 기술 사용 금지
3) 계획을 세우고 그것을 바탕으로 진행해라.
4) 여러분의 가정을 문서로 남겨라. 다른사람과 가정에 대해 소통하는데 도움이 되며, 마음속 가정을 명확히 하는데 도움이 된다.
5) 코드만 테스트 할게 아니라 가정도 테스트 해봐야한다.
6) 과거의 노예가 되지말라. 기존코드가 앞으로 짤코드를 지배하도록 놓아두지 말라. 더이상 적절한 코드가 아니라고 생각되면, 어떤 코드라도 교체할 수있다. 여기선 중요한 건 일정이 늦어져 발생하는 비용이 필요한 변화를 만들지'않을' 경우의 비용보다 적어야 한다는 것이다.

33. 리펙터링

소프트웨어란.
소프트웨어는 건축보다 정원 일에 가깝다.
딱딱하기보다 유기적인 존재다.
정원의 건강상태를 지속적으로 관찰하며 필요하면 토양,식물,정원 배치를 조정하기도 한다.
어떤루틴이 너무 크게 자라거나 많은것을 하려할때 둘로 나눠야 한다.
계획대로 잘되지않는것은 잡초제거나 가지치기를 해줘야 한다.

When?
리펙터링은
1) 중복 : DRY (Don't Repeat Yourself : 반복하지마라.)원칙 위반을 발견했다.
2) 직교성이 좋지않은 설계 : 직교성을 더 좋게만들 코드나 설계를 발견했다.
3) 유효기간이 끝난 지식: 사물은 변하고, 요구사항은 변경되며, 지금해결중인 문제 에대한 여러분의 지식은 증가한다. 코드는 지금 상황에 뒤떨어지지 않게 유지되어야한다.
4) 성능 : 성능을 개선하려면 시스템의 한 영역에서 다른 영역으로 기능을 옮겨야 한다.


How?
1) 리팩터링과 새로운기능 추가를 동시에 하지 말라.
2) 리팩터링을 시작하기전 든든한 테스트 집합이 있는지 먼저 확인한다. 할수있는 한 자주 테스트들을 돌려본다. 이렇게하면 변경때문에 무엇이 망가졌을 경우 재빨리 그 사실을 알 수있다.
3) 단계를 작게 나누어서 신중하게 작업한다.
단계를 작게 나누고, 한단계가 끝날때마다 테스트를 돌린다면 기나긴 시간의 디버깅작업을 피할 수 있다.

34. 테스트하기 쉬운 코드

모듈을 설계할때는 심지어 루틴 하나를 설계할 때도, 그것이 지켜야 할 계약과 계약을 지키는 지 테스트 하는 코드도 함께 설계해야 한다.

( 테스트 코드를 보면 개발자의 의도가 보인다. )

ex) 샘플코드