실용주의 프로그래머 6일차. 실용주의 편집증

오늘 TIL 3줄 요약

• 계약에 의한 설계
• 단정적 프로그래밍 - 검증하는 테스트 코드 작성 => assert 이용하기.
• 코드를 더 적절한 무언가로 대체하기 쉽게 설계하라. 

 

TIL (Today I Learned)

2022.03.24

 

오늘 읽은 범위

4장 실용주의 편집증

 

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

계약에 의한 설계 

: 함수(매서드) 구현 조건 중

ㄴ루틴 : 무한 반복을 허용하지 않는다

ㄴ함수 인자가 범위를 벗어나면 호출이 안된다.

: 어겨서는 안되는 고정된 규칙인 요구사항과 경영진이 바뀌면 없어질 수 있는 단순한 정책을 혼동하지 말아야 한다.

: 명확하고 모호한 점이 없게 서술하도록 하자.

: "그걸 제공해 드릴 수는 없어요. 하지만 여러분이 이걸 주신다면 저도 뭔가 다른 걸 드릴 수는 있어요."

ㄴ 소프트웨어를 설계하게 되면 계약 역시 설계되도록 하라.

 

단정적 프로그래밍

: 성능 문제가 있다 하더라도 정말 문제가 되는 단정문만 끄도록 하자.

 

 

중첩 할당

: 리소스를 할당한 순서의 역순으로 해제하라.

: 언제나 같은 순서로 할당해야 한다. => 교착(deadlock) 가능성을 줄일 수 있다.

 

리소스 할당 후 해제하기.

ㄴ 잘 모르겠을 땐 스코프를 줄이는 편이 낫다.

 

 

리소스 사용의 균형을 잡을 수 없는 경우

: 자료구조에서 최상위 구조의 메모리 할당을 해제할 방법

    ㄴ 방법1. 최상위 구조가 자기 안의 하위 구조들을 해제할 책임을 진다. 하위 구조들은 또다시 재귀적으로 자기 안에 들어있는 자료들을 해제하고, 반복된다.

    ㄴ 방법2. 최상위 구조가 그냥 할당 해제된다. 

    ㄴ 방법3. 최상위 구조가 하나라도 하위 구조를 갖고 있으면 자신의 할당 해제를 거부한다. 

: 균형 점검하기

ㄴ 보통 리소스의 종류별로 래퍼(wrapper)를 만들고 그 래퍼들이 모든 할당과 해제 기록을 보관하는 것을 뜻한다.

ㄴ 래퍼를 사용해서 상태가 올바른지 점검하라. 

 

 

예측은 힘들다.

: 불확실한 미래에 대비한 설계를 하느라 진을 빼는 것 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다. 여러분의 코드를 더 적절한 무언가로 대체하기 쉽게 설계하라. 

 

 

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

처음 파이썬을 배울때, TDD 코드 작성시 assert를 사용하는 강의를 본 적이 있었다. 그때 aseert를 결과값을 true와 false로 리턴하는 방식으로만 알고 있었는데, 애플리케이션 개발에 이용하여 출시 이후에도 계속 단정문을 켜두어 UI로 보여주어 유저를 만족시킬 수도 있었다니. 

 

 

오늘 읽은 다른사람의 TIL : https://hyuuny.tistory.com/64  김성현님