개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
계약에 의한 설계로 실수에 대한 대비책을 마련하라
문제가 발견한다면 바로 시스템을 멈추자
너무 먼 미래를 보기 보단 앞을 바라보라
TIL (Today I Learned) 날짜
2022. 03. 24
오늘 읽은 범위
4장. 실용주의 편집증
책에서 기억하고 싶은 내용을 써보세요.
Topic 23 자신의 실수에 대한 대비책을 마련한다.
DBC(Designed by Contract) 계약에 의한 설계
선행 조건 - 루틴이 호출되기 위해 참인 것 (제대로 된 데이터를 전달한는 것)
후행 조건 - 루틴이 자기가 할 것이라고 보장 하는 것
클래스 불변식 - 이 조건이 언제나 참인 것을 클래스가 보장
호출자가 루틴의 모든 선행 조건을 충족한다면 해단 루틴은 종료시 모든 후행 조건과 불변식이 참이 되는 것을 보장한다.
코드를 작성하기 전 해야하는 것
유효한 입력 범위는 ?
경계 조건은?
루틴이 결과값은 어떤걸 전달(약속)하는지?
무엇을 약속하지 않는지?
어겨서는 안되는 고정된 규칙인 요구 사항과 경영진이 바뀌면 얼마든지 없어질 수 있는 단순한 정책을 혼동하지 말아야한다.
Topic 24 죽은 프로그램은 거짓말을 하지 않는다.
가능한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출수 있으니 더 낫다
Topic 25 단정적 프로그래밍
Topic 26 리소스 사용의 균형
자신이 시작한 것은 자신이 끝내라
잘 모르겠으면 스코프를 줄이는 편이 낫다.
Topic 28 헤드라이트를 앞서가지 말라
우리는 너무 먼 미래는 내다볼수 없고, 정면에서 벗어난 곳일수록 더 어둡다.
불확실한 미래에 대비한 설계를 하느라 진을 뺴는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
오늘도 그랬다. 큰 서비스 배포가 있었다. 나는 무조건 잘될꺼라고 확신했고, 담당 기획자에게도 이거 이래이래해서 무조건 되요. 어라라? 배포하고 보니 아니다. 내가 놓친게 있었다. 물론 이런 상황을 대비해서 주석과 프로세스를 정리해 놓았다. 하지만 항상 2%가 부족함을 느꼈다. 급박한 상황에 주석이랑 프로세스가 보이는가? 아니 솔직히 안본다. 이런 나에게 DBC는 다른 방향성을 제안해 주는것 같았다. 코드를 작성하기 전에 해야할 것들 부터 정리해보고 문서로 남겨 봐야겠다.
큰 개발이 있을 때마다 개발 일정을 짜는데 곯머리를 앓는다. 중간에 어떤 일이 벌이질지 모르기 때문이다. 개인적으로 설계에 목숨을 많이 건다. 왜냐하면 완벽한 코드를 짜고 싶기 때문인데.
완변한 코드는 좋은 설계에서 나온다고 생각하기 때문이다. 하지만 그것보다도 지금 주어진 코드에 언제나 교체가능한 코드가 되도록 대비하는 것이 더 급선무임을 느꼈다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
편집증 : 인격의 붕괴를 보이지는 않으나 피해망상·추적 망상과 같은 논리적·체계적인 망상을 나타내는 병적인 상태
https://ko.wikipedia.org/wiki/%ED%8E%B8%EC%A7%91%EC%A6%9D단정문 : assertTrue 기대값은 반드시 참이여야 함.
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=k_builder&logNo=40192031458
오늘 읽은 다른사람의 TIL