[실용주의 프로그래머] 4장. 실용주의 편집증

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

📚 책에서 기억하고 싶은 내용?

---

완벽한 소프트웨어는 만들 수 없다. 

• 실용주의 프로그래머들은 자신의 실수에 대비해 방어적으로 코드를 짠다.

계약에 따른 설계를 하라. Design By Contract, DBC

• 정확한 프로그램이란 무엇인가? 스스로 자신이 하는 일이라고 주장하는 것보다 많거나 적지도 않게 딱 그만큼만 하는 프로그램을 말한다. 
• 1) 선행조건: 루틴이 호출되기 위해 참이어야 하는 것.
  2) 후행조건: 루틴이 자기가 할 것이라고 보장하는 것. 무한 반복은 허용되지 않는다.
  3) 클래스 불변식: 호출자의 입자에서 볼 때는 이 조건이 언제나 참이라고 클라스가 보장한다. 루틴이 종료하고 호출자로 제어권이 반환되는 때에는 불변식이 참이어야 한다.
• iContract 문법 가운데 variable@pre를 사용해서 메서드 진입 시점에서 변수의 원래 값을 얻는 수가 있다.
• lazy 코드
  시작하기 전에 자신이 수용할 것에 대해서는 엄격하고 하고, 내어줄 것에 대해서는 최소한도를 약속하는 것이다.
• 리스코프 대체 원칙
  서브 클래스는 사용자가 차이점을 모르고서도 기반 클래스 인터페이스를 통해 사용할 수 있어야 한다.
• 런타임 시스템과 라이브러리가 계약을 지원하도록 설계되지 않았기 때문에, 이런 호출들은 검사되지 않는다.
• C, C++의 경우 Nana, 자바의 경우 iContract ▶ DBC를 지원하는 언어, 전처리기
• 루프 불변식, 의미론적 불변식

일찍 작동을 멈추게 하라.

• 분명히 실행 중인 프로그램을 그냥 종료해 버리는 것은 때로 적절치 못하다. 해체되지 않은 자원이 남아 있을 수도 있고, 로그 메시지를 기록할 필요가 있을 수도 있고, 열려있는 트랜잭션을 청소해야 하거나, 다른 프로세스들과 상호작용해야 할 필요가 있을지도 모른다.

단정문을 사용해서 불가능한 상황을 예방하라.

• 단정은 켤코 일어나면 안되는 것들을 검사한다.
• 리소스를 해체할 필요가 있다면, 단정 실패가 예외를 생성하게 하거나, 출구로 longjump를 하게 하거나, 에러 핸드러를 호출하게 하라.
• 단정이 과부하를 일으킨다는 것은 오해다.

// 잘못된 방식
while(liter.hasMoreElements()){
  Test.ASSERT(iter.nextElement()!=null);
  Object obj = iter.nextElement();
}

// 아래 방식을 따라 작성하자. 
// .next 호출은 이 호출이 돌려주는 원소 다음으로 반복자를 이동시키는 부작용이 있다. 
// 따라서 컬랙션 원소의 절반만 처리하게 되기 때문이다.
while(liter.hasMoreElements()){
  Object obj = iter.nextElement();
  Test.ASSERT(obj!=null);
}

예외는 예외적인 문제에 사용하라.

• if, else 문이 아닌 try, catch를 이용한 예외처리가 훨씬 깔끔한 경우가 있다.
• 예외가 있다는 것은 즉 컨트롤의 이동이 즉각적이고 로컬하지 않다는 것을 말한다. 일종의 연쇄 같은 것이다.
• 자바의 RMI 기능을 사용하는 클라이언트 서버 애플리케이션에서 원격이 아닌 클래스로 원격 객체를 감싸 에러처리기 인터페이스를 구현하는 것도 방법이다.

시작한 것은 끝내라.

• 단순히 리소스를 할당하는 루틴이나 객체가 리소스를 해체하는 책임 역시 져야한다는 것을 의미한다.
• 이상적으로 말해서 리소스를 할당하는 루틴이 해제 역시 책임져야 한다는 것이다. 리팩터링 잘하자.
• 중첩할당
  1) 리소스를 할당한 순서의 반대로 해체하라.
  2) 코드의 여러 곳에서 동일한 리소스 집합을 할당하는 경우, 할당 순서를 언제나 같게 하라.
• 클래스는 하나의 리소스를 대표하며, 생성자는 그 리소스 타입의 특정 객체를 제공하고, 소멸자는 그것을 현 스코프에서 제거한다.
• C++와 달리 자바에서는 게으른 방식의 자동 객체 삭제를 사용한다.
  가비지 콜렉션이 참조가 없는 객체를 지우고, finally절이 반드시 실행되어 리소스 균형을 잡는다.

 

🤩 오늘 읽은 소감?

---

생각보다 오늘 읽은 책의 내용을 길었다. 목차를 봤을 때는 간단한 내용이네 이러다가도 번번히 숙고하게 되는 책이다. 노개북 도서로 선정된 이유가 있겠지...!

 

25. 리소스의 사용의 균형 파트가 이후에도 가장 도움이 될 것 같았다. 직접 개발을 할 때 어떤 방식으로 리팩터링할지 리소스 할당에 대한 부분도 자세히 설명되어 있었다. 아마 나중에 개발을 하면서도 중요시 해야 되고, 익혀서 내 것으로 만들어야 할 부분이라고 생각된다. 리소스의 균형을 잡자!

 

 

❓ 궁금한 점이나 잘 이해되지 않는 내용

---

DBC가 강력한 도구인데 널리 사용되지 않을까?

• 수많은 케이스들 중에서 계약은 특정 형식화할 수 없고, 현재 정적 분석도구로 체크될 수 없기 때문이다. 이런 사람들의 요구에도 불구하고 DBC는 여전히 사람들의 요구를 만족시키지 못하기 때문이다.
  대신 TDD는 현재 상황의 메소드로 잘 문서화되어 있고, TDD를 사용하는 상황에서 DBC는 반드시 필요한 부분이 아니기 때문이다.
• 하지만 TDD와 DBC는 상호보완적 관계라고 볼 수 있기 때문에 DBC 역시 알아두어야 한다는 의견도 있다.

출처: https://stackoverflow.com/questions/481312/why-is-design-by-contract-not-so-popular-compared-to-test-driven-development

 

 

실용주의 프로그래머 - 교보문고