오늘 TIL 3줄 요약

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

• 망치지 말고 멈춰라.

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

TIL (Today I Learned)날짜

2022.05.18

오늘 읽은 범위

4장. 실용주의 편집증

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

1 계약에 의한 설계(DCB-Design By Contract) p.147

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

• ‘게으름뱅이lazy’ 코드를 강조하고 싶다. 시작하기 전에 자신이 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것이다.

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

• 단정문이나 DBC 방식을 사용하여 선행 조건과 후행 조건, 불변식을 검증하면 더 일찍 멈추고, 문제에 대한 보다 정확한 정보를 알려줄 수 있을 것이다

• ‘의미론적 불변식semantic invariant’을 사용하면 일종의 ‘철학적 계약’인 절대 어겨서는 안 되는 요구 사항을 표현할 수 있다.

2. 죽은 프로그램은 거짓말을 하지 않는다. p.162

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

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

3. 단정적 프로그래밍 p.56

• 단정문으로 불가능한 상황을 예방하라.----‘하지만 물론 그런 일은 절대 일어나지 않을 거야.’라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라. 가장 간단하게 추가하는 방법은 단정문assertion을 사용하는 것이다.

• 프로그램을 출시할 때 단정 기능을 꺼 버리는 것은 줄타기 곡예를 하면서 연습으로 한 번 건너 봤다고 그물 없이 건너는 것과 비슷하다. 극적인 가치야 있겠지만 생명 보험을 들기는 어렵다. 성능 문제가 있다 하더라도 정말 문제가 되는 단정문만 끄도록 하자.

4. 리소스 사용의 균형 p.167

• 자신이 시작한 것은 자신이 끝내라.-----리소스를 할당하는 함수나 객체가 리소스를 해제하는 책임 역시 져야 한다는 뜻일 뿐이다.

• 지역적으로 행동하라.------잘 모르겠을 땐 언제나 스코프를 줄이는 편이 낫다.

• 리소스를 할당한 순서의 역순으로 해제하라. 이렇게 해야 한 리소스가 다른 리소스를 참조하는 경우에도 참조를 망가트리지 않는다.

• 코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나

• 같은 순서로 할당해야 교착deadlock 가능성을 줄일 수 있다.

• 리소스 사용의 균형을 잡을 수 없는 경우---메모리 할당에 대한 의미론적 불변식을 정하는 것이다. 한군데 모은 자료 구조 안의 자료를 누가 책임지는지 정해 놓아야 한다.

5. 헤드라이트를 앞서가지 말라 p.177

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

• 불확실한 미래에 대비한 설계를 하느라 진을 빼는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다. 여러분의 코드를 더 적절한 무언가로 대체하기 쉽게 설계하라. 코드를 교체할 수 있도록 하면 응집도나 결합도, DRY에도 도움이 되고, 전반적으로 더 나은 설계가 탄생할 것이다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 책을 읽을 수록 아직 접해본 적없는 용어와 언어가 조금은 읽기 힘들게 하지만, 이번장에서도 역시 유연한 코드를 강조하는 것 같았다. 나 자신을 믿지 말고, 단정 기능을 켜놓는 것과 코드간 길민한 결합이 없도록 스코프를 줄여 지역적으로 행동하게 만들고, 내가 시작은 일은 내가 책임을 지는것이 맞다고 많은 부분 언급이 된 것 같다. 나중에 내가 맡은 프로젝트를 진행할 때 마감에 쫒기며 위에서 언급한 부분들은 다 놓히지 않도록 기억해 둬야 겠다.

• 예측은 힘들다. 특히 미래에 대해서는, 하는 덴마크 속담을 프로그래머로서는 더 잘 기억해야 할 것 같다. 책에서 얘기하길 몇 시간이나 며칠정도를 예측이 가능 할 수 있으나 그 이상은 경험에 기반한 추측을 벗어난 무모한 억측이라 한다. 책에서 강조하는 ETC를 항상 명심하며 다른 팁들을 추가 하며 더 나은 설계를 만들어 봐야 겠다.(언젠가는..)

오늘 읽은 다른사람의 TIL

yyy 님의 TILhttps://nomadcoders.co/community/thread/5295