실용주의 프로그래머 4장 < 실용주의 편집증 >

Today reading range

- 오늘 읽은 범위

실용주의 프로그래머 4장 < 실용주의 편집증 >

Impressive content

- 인상 깊었던 내용

실용주의 프로그래머는 자기 자신 역시 믿지않는다. 어느 누구도, 심지어는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 실용주의 프로그래머는 자신의 실수에 대비한 방어책을 설명한다. -146p.

Topic23. 계약의 의한 설계

DBCDesign By Cotract는 단순하지만 강력한 기법으로, 프로그램의 정확성을 보장하기위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는데 초점을 맞춘다. -148p.

정확한 프로그램이란 무엇인가? 자신이 하는 일이라고 주장하는 것보다 많지도 적지도 않게 딱 그만큼만 하는 프로그램이다. -148p.

마이어는 이런 전제와 선언을 다음과 같이 설명한다. -148p.

1. 선행 조건 : 루틴이 호출되기 위해 참이여야하는 것. 즉, 루틴의 요구사항이다. 루틴의 선행 조건이 위반되는 경우에는 루틴이 호출되서는 안된다. 제대로 된 데이터를 전달하는 것은 호출는 쪽에 책임이다.
2. 후행 조건 : 루틴이 자기가 할 것이라고 보장하는 것. 즉, 루틴이 완료되었을때 세상에 상태이다. 루틴에 후행 조건이 있다는 것은 곧 루틴이 종국에는 종료될 것이라는 걸 의한다, 무한 반복은 허용되지 않는다.
3. 클래스 불변식 : 호출자의 입장에서 볼 때에는 이 조건이 언제나 참인 것을 클래스가 보장한다. 루틴의 내부 처리 도중에는 불변식이 참이 아닐 수도 있지만, 루틴이 끝나고 호출자로 제어권이 반환되는 시점에는 불변식이 참이 되어야한다.

루틴과 그 루틴을 호출하려는 코드간의 계약은 다음과 같다.




만약 호출자가 루틴의 모든 선행 조건을 충족한다면 해당 루틴은 종료 시 모든 후행 조건과 불변식이 참이 되는 것을 보장한다. -149p.

....'클래스 불변식'이라고 이름 붙였다. 하지만 사실 그보다 더 일반적인 개념이다. 이 용어가 진짜 의미하는 것은 상태state이다.

코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지 등을 나열하는 것만으로도 더 나은 소프트웨어를 작성하는데 엄청난 도움이된다. -153p.

문제를 찾고 원인을 밝히기 위해서는 사고가 난 지점에서 일찍 멈추는 것이 유리하다. -155p.

요구사항에서 직접 도출된 이런 간단한 법칙이 복잡한 오류 복구 시나리오를 정리하는 데에 큰 도움이 되는 것으로 나타났다.-156p.

불변식의 자격이 있는 요구 사항을 찾았다면 여러분이 작성하는 모든 문서에 잘 들어나도록 만들어라. -156p.

Topic24. 죽은 프로그램은 거짓말하지 않는다.

어떤 개발자들은 모든 예외를 catch 나 rescue로 잡은 후 로그 메세지를 좀 찍은 다음 다시 예외를 발생시키는 것이 좋은 방식이라고 여기는듯하다. -159p.

얼랭을 만들고 < 프로그래밍 얼랭 > 을 쓴 조 암스트롱은 이런 말을 자주 했다고 한다. "방어적 프로그래밍은 시간 낭비다. 그냥 멈추는게 낫다!"....-161p.

그렇지만 기본 원칙은 똑같다. 방금 있을 수 없는 일이 발생했다는 것을 코드가 발견했다면 프로그램은 더는 유효하지 않다고 할 수 있다. 이 시점 이후로 하는 일은 모두 수상쩍은 게 된다. 되도록 빨리 종료할 일이다. -161p.

Topic25. 단정적 프로그래밍

자기 비난에는 사치성이 있다. 우리가 자신을 비난할 때, 다른 사람은 우리를 비난할 권리가 없다고 우리는 느낀다.

- 오스가와일드(Oscar wilde) << 도리안 그레이의 초상 >>

모든 프로그래머가 자기 경력을 쌓는 초기부터 암기해야하는 계명이 있는 것 같다.
... 그것은 이렇게 시작한다.

그런 일은 절대 일어날 리 없어

여러분의 첫 번째 방어선은 가능한 오류를 모두 검사하는 것이고, 그 다음은 그러고도 놓친것을 잡아내기 위해 단정을 사용하는 것이다. -165p.

Topic26. 리소스 사용의 균형

많은 개발자가 리소스 할당과 해제를 다루는 일관된 방침을 갖고 있지 않다. 그래서 우리는 간단한 팁 하나를 제안하고자 한다.

Tip40 자신이 시작한 것은 자신이 끝내라. => 170p의 소스코드를 꼭! 참고할것!

리소스 할당의 기본 패턴을 확장해서 한 번에 여러 리소스를 사용하는 루틴에 적용할 수 있다. 두 가지만 더 제안하겠다. -171p.

• 리소스를 할당한 순서의 역순으로 해제하라. ....
• 코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나 같은 순서로 할당해야 교착 가능성을 줄일 수 있다. ...

Topic27. 헤드라이트를 앞서가지 말라.

수사관이 한 말은 운전자가 헤드라이트 불빛이 비춘 것을 보고 반응하여 차를 멈추거나 핸들을 꺾는 능력을 가리킨 것이다. - 177p.

그래서 실용주의 프로그래머에게는 확고한 규칙이 있다.

Tip 42. 작은 단계들을 밟아라. 언제나.

여기서 피드백이란 무엇을 말하는 걸까? 여러분들의 행동을 독립적으로 확증하거나 반증하는 것이라면 모두 피드백이다 - 177p.

너무 큰 작업은 무엇일까? '예언'을 해야 하는 모든 작업이다.

미래가 어떤 모습일지 더 많이 예측하려고 할수록 여러분이 틀릴 가능성은 계속 높아질 것이다. - 179p.

대부분의 경우 내일은 오늘과 거의 같을 것이다. 하지만 확신하지는 말라.

Thoughts I had while reading the book

- 오늘 책을 읽으면서...

DBC 내용에서 자바스크립트의 메서드를 생각하면서 이해하려고 했다. 예) Javascript의 map 함수 map 함수는 배열이 아닌 데이터에서는 실행되지 않으며 실행된 후 새로운 배열을 만들기때문에 이 내용에 딱 맞는 함수라고 생각했다. 평소 모듈화를 중요하게 생각하고 있기때문에 DBC 내용은 더 집중해서 이해하려고 노력했다. (그래서 인상깊었던 내용도 가장 많다.)

DBC를 읽으면서 생각났던게 있었다. 수업을 들으면서 강사님은 항상 모듈위에 모듈에 대한 설명과 전달되는 파라미터의 데이터 타입과 역활을 정의했는데 그것만 해도 DBC 법칙의 반은 지키는게 아닐까?

DBC를 자바스크립트의 함수로 구현하면 이런 느낌아닐까? 잘 이해한건지는 모르겠다.

 /*
 * thing이 무엇일때 무엇을 해서 무엇으로 반환하는 함수
 * thing [type] ~~
 * return state(불변식)
 */
  const thing = 'something';
  
  // 선행조건
  if(!thing 조건){
    return new Error;
  } else {
    const thing_copy = thing;

    return doSomething(thing_copy);
  }
 
 // 후행조건
 function doSomething(thing_copy){
 
   // thing_copy를 가지고 후행조건 실행...

   return state? // 불변식???
 }

연습문제 14번 꼭 나중에 해봐야갰다. (지금까지 나온 연습문제 중에서 가장 해보고싶은 내용이였다.)

오늘 내용도 정말 중요한것같다. 특히 < 헤드라이트를 앞서가지 말라. > 는 항상 걱정이 많은 나한테 큰 메세지를 던져줬다. 개발뿐만 아니라 일상에서 생각해야될 개념인거 같다. 앞서가지말자!

Things you're curious about, things you don't understand.

- 궁금한 내용, 이해되지 않았던 내용

DBC하고 리소스의 균형은 이해하는라 좀 힘들었다. 특히 리소스의 균형 뒷부분은 그냥 감만 잡았다..