DAY 4
오늘 읽은 범위 : 4장 실용주의 편집증
책에서 기억하고 싶은 내용을 써보세요.
여러분은 완벽한 소프트웨어를 만들 수 없다
삶의 공리로 인정하고 받아들여라. 그리고 축하하라. 완벽한 소프트웨어는 존재하지 않기 때문이다.
모든 사람은 지구 상에서 오직 자신만이 훌륭한 운전자라고 생각한다. 이 세상의 나머지 사람들은 빨간불에도 휙 지나가고, 차선을 이리저리 바꾸고, 깜박이도 제대로 넣지 않고, 운전 중에 문자를 하는 등 기준에 못 미치는 행동을 한다. 그래서 우리는 방어적으로 운전한다.
- 프로그래머는 자기 자신 역시 믿지 않는다. 어느 누구도, 심지어는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 실용주의 프로그래머는 자신의 실수 에 대비한 방어책을 마련한다. 코드의 공급자와 사용자는 권리와 책임에 대해 동의해야한다.
계약에 의한 설계, DBC (Design By Contract)
정직한 거래를 보장하는 최선의 해법 중 하나는 ‘계약' 이다.
- 코드를 작성하기 전에
-
유효한 입력 범위가 무엇인지
-
경계 조건이 무엇인지
-
루틴이 뭘 전달한다고 약속하는지
-
더 중요하게는 무엇을 약속하지 않는지
등을 나열하는 것만으로도 더 나은 소프트웨어를 작성하는 데에 엄청난 도움이 된다.
-
- 단정문 컴파일러가 여러분 대신 계약을 검사하도록 한다면 훨씬 더 큰 도움이 될 것이다. 몇몇 언어에서는 조건문을 실행 시점에 확인하는 ‘단정문'을 사용해서 부분적으로나마 흉내 낼 수 있다.
- DBC와 일찍 멈추기 → DBC는 우리의 “일찍 작동을 멈춰라.”라는 개념과 잘 어울린다. 문제를 찾고 원인을 밝히기 위해서는 사고가 난 지점에서 일찍 멈추는 것이 유리하다.
죽은 프로그램은 거짓말을 하지 않는다
- 망치지 말고 멈춰라
방어적 프로그래밍은 시간 낭비다. 그냥 멈추는 게 낫다
- 가능한 한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 더 낫다. 게다가 프로그램을 멈추는 것이 할 수 있는 최선인 경우가 흔하다.
단정적 프로그래밍
- 그런 일은 절대 일어날 리 없어 모든 프로그래머가 자기 경력을 쌓는 초기부터 암기해야 하는 계명 이 있는 것 같다. 요구사항, 설계, 코드, 주석 등 우리가 하는 거의 모든 것에 적용하도록 배우는 컴퓨팅의 근본 교리이자 핵심적 믿음이다. → 자신을 기만하지 말자, 특히 코딩할 때는.
리소스 사용의 균형
촛불 하나를 켜는 건 곧 그림자도 하나 던지는 거란 말이다.
- 자신이 시작한 것은 자신이 끝내라.
리소스를 할당하는 함수나 객체가 리소스를 해제하는 책임 역시 져야 한다는 뜻일 뿐이다.
헤드라이트를 앞서가지 말라
예측은 힘들다. 특히 미래에 대해서는.
- 작은 단계들을 밟아라. 언제나.
더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라. ‘너무 큰' 단계나 작업은 하지 않게 될 것이다.
- 여기서 피드백이란 무엇을 말하는 걸까?
- REPL의 결과는 API나 알고리즘을 여러분이 제대로 이해하고 있는지 피드백을 준다.
- 단위 테스트는 직전에 고친 코드에 대한 피드백을 준다.
- 사용자 데모 및 사용자와의 대화는 기능이나 사용성에 대한 피드백을 준다.
예언하지 말라.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
어떤 상황에서든 나 자신을 믿지 말자. 문서화하고 검증하자. DBC
DBC 를 잘 지켜나간다면, 향후 유지보수 측면에도 도움이 많이 될 것 같다.
나뿐만 아니라 모두에게 차선책인 것 같다.
작은 단계들을 밟아라에서 많은 생각을 하였다.
프로그램을 짜는 도중에, 막연하게 이렇게 되는거겠지 했던 것들이 피드백을 받았을 때 아니었던 경우가 많았다.
그 순간 당연히 이렇게 되는 거겠지라는 나의 고정관념으로 인하여 나중의 내가 곤란해졌던 경우가 많다.
항상 프로그램을 세분화하여 쪼개서 피드백을 받는 것이 중요하고, 나 자신을 많이 반성했다.
