실용주의 프로그래머 ( Days 4 )

3021 단어 노개북bookbook

실용주의 편집증

🔖 오늘 읽은 범위 : 4장. 실용주의 편집증

❗ 소감 3줄 요약

- 완벽한 소프트웨어는 없다.
- '그런 일은 일어나지 않을거야.' 라는 생각을 하지말고 증명하자.
- 신중하게 작은 단계부터 계획을 세워 피드백을 받자.


😃 책에서 기억하고 싶은 내용을 써보세요.

[ 계약에 의한 설계 ]

정직한 거래를 보장하는 최선의 해법 중 하나는 "계약" 이다.


DBC

버트런드 마이어는 에펠이라는 언어를 만들면서 계약에 의한 설계 개념을 개발했다.
DBC는 단순하지만 강력한 기법으로 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데에 초점을 맞춘다.

소프트웨어 시스템의 모든 함수와 메서드는 뭔가를 한다.
그 뭔가를 시작하기 전에 해당 함수는 세상의 상태에 대해 어떤 전제 조건을 갖고 있을 테고, 루틴이 끝난 후에는 세상의 상태가 어떠할 것이라고 선언할 수 있을 것이다.
마이어는 이런 전제와 선언을 다음과 같이 설명한다.

- 선행 조건

루틴이 호출되기 위해 참이어야 하는것. 즉 루틴의 요구사항이다.
제대로 된 데이터를 전달하는 것은 호출하는 쪽의 책임이다.

- 후행 조건

루틴이 자기가 할 것이라고 보장하는 것.
루틴에 후행 조건이 있다는 것은 곧 루틴이 종국에는 종료될 것이라는 걸 의미한다.
무한 반복은 허용되지 않는다.

- 클래스 불변식

호출자의 입장에서 볼 때는 이 조건이 언제나 참인 것을 클래스가 보장한다.

- 루틴과 그 루틴을 호출하려는 코드간 계약

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

- 클래스 불변식과 함수형 언어

에펠이 객체 지향 언어였던 탓에 마이어는 개념을 클래스 불변식이라고 이름 붙였다.
이 용어가 진짜로 의미하는 것은 상태다.

- DBC 구현

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

- 클래스 불변식과 함수형 언어

에펠이 객체 지향 언어였던 탓에 마이어는 개념을 클래스 불변식이라고 이름 붙였다.
이 용어가 진짜로 의미하는 것은 상태다.

[ 죽은 프로그램은 거짓말을 하지 않는다. ]

'그런 일은 절대 일어날 리 없어.' 라는 사고에 빠지기 쉽다.
우리가 코드를 작성할 때 파일이 성공적으로 닫혔는지, 혹은
트레이스 문이 우리 예상대로 찍혔는지 확인하지 않았던 적이 있을 것이다.

반면에 실용주의 프로그래머는 만약 오류가 발생했다면
정말로 뭔가 나쁜 일이 생긴 것이라고 자신에게 이야기한다.
일단 그놈의 오류 메시지 좀 읽어라.

망치지 말고 멈춰라

- 가능한 한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 더 낫다.



[ 단정적 프로그래밍 ]

모든 프로그래머가 자기 경력을 쌓는 초기부터 암기해야 하는 계명이 있는 것 같다.
요구 사항, 설계, 코드, 주석 등 우리가 하는 거의 모든 것에 적용하도록 배우는
컴퓨팅의 근본 교리이자 핵심적 믿음이다. 그것은 이렇게 시작한다.

'하지만 물론 그런일은 절대 일어나지 않을 거야.' 라는 생각이 든다면
그런일을 확인하는 코드를 추가하라.

[ 헤드라이트를 앞서가지 말라 ]

캄캄한 늦은 밤, 폭우가 쏟아지고 있다.
스포츠카 한 대가 굽이굽이 이어진 좁은 산길을 거칠게 질주한다.
간신히 코너를 빠져나오나 했는데 그만 다음 급커브를 놓치고 말았다.
부실한 가드레일을 들이받더니 허공을 날아 계곡 아래에 화염을 일으키고 만다.
경찰관들이 현장에 도착한다.
수사관 하나가 고개를 절레절레 흔들며 말한다.
"헤드라이트를 앞서간 것이 틀림없어."

스포츠카가 정말로 빛의 속도보다 빠르게 달렸을까? 그럴리가.
빛의 속도는 고정불변이다.
수사관이 한 말은 운전자가 헤드라이트 불빛이 비춘 것을 보고 반응하여
차를 멈추거나 핸들을 꺾는 능력을 가리킨 것이다.

- 언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라. 너무 큰 단계나 작업은 하지 않게 될 것이다.


좋은 웹페이지 즐겨찾기