완벽한 소프트웨어는 만들 수 없다.
길지 않은 컴퓨터 역사를 통틀어 어느 누구도 완벽한 소프트웨어를 만들지 못했다.
여러분이 최초가 될 것 같지도 않다.
📔계약에 의한 설계
정직한 거래를 보장하는 최선의 해법 중 하나는 계약이다.
DBC
버트란드 마이어는 아이펠이라는 언어를 만들면서 계약에 의한 설계 개념을 개발했다.
- 이것은 단순하지만 강력한 기법으로 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈들의 권리와 책임을 문서화하는 데에 초점을 맞춘다.
정확한 프로그램이란 무엇인가? 스스로 자신이 하는 일이라고 주장하는 것보다 많거나 적지도 않게 딱 그만큼만 하는 프로그램을 말한다.
SW에서 모든 함수와 메소드는 뭔가를 하는데 그것을 어떻게 된다고 설명하는데 필요한 것은
루틴 = 모든 함수와 메소드
선행조건
- 루틴이 호출되기 위해 참이어야 하는 것
- 즉, 루틴의 요구사항
- 루틴이 선행조건이 위반된 경우에는 루틴이 호출되면 안된다.
- 제대로 된 Data를 전달하는 것은 호출하는 쪽의 책임이다.
후행조건
- 루틴이 자기가 할 것이라고 보장하는 것
- 루틴이 완료되었을 때 세상의 상태.
클래스 불변식
- 호출자 입장에서 볼 때는 이 조건이 언제나 참이라고 클래스가 보장한다.
- 불변식에 관여하는 어떤 데이터 멤버에게도 클래스가 무제한적인 쓰기 접근권을 줄 수 없다는 것을 기억하라.
루틴과 그 루틴의 잠재적 호출자 간의 계약
만약 호출자가 루틴의 모든 선행조건을 충족한다면, 해당 루틴은 종료시 모든 후행조건과 불변식이 참이 될 것을 보장해야 한다.
계약 당사자 중 어느 한쪽이라도 이 계약을 지키지 못하면 배상이 이뤄진다.
여기서 배상은 예외가 발생하거나 프로그램이 종료하거나 하는 것이다.
무슨일이 벌어지든지 간에 계약에 부응하지 못하는 게 버그가 되어버리는 실수는 저지르지 마라.
계약에 따른 설계를 하라.
DBC구현
DBC를 사용하는 최고의 장점은 요구사항과 보증의 문제를 전면으로 내세운다는 것이다.
- 입력 도메인의 범위가 무엇인지
- 경계 조건이 무엇인지
- 루틴이 뭘 전달한다고 약속하는지 혹은 더 중요한 것으로, 무엇을 전달한다고 약속하지 않는지
📔죽은 프로그램은 거짓말을 하지 않는다.
자신이 짠 코드는 오류가 없을 거라는 생각을 하지마라!
- 당연히 정상적인 조건에서는 실패하지 않았을 것이다.
모든 에러는 정보를 준다.
일찍 작동을 멈추게 하라.
프로그램을 멈추는 것이 할 수 있는 최선일 때가 많다.
일반적으로 죽은 프로그램이 입히는 피해는 절름발이 프로그램이 끼치는 것보다 훨씬 덜한 법이다.
📔단정적 프로그래밍
단정문을 사용해서 불가능한 상황을 예방하라.
count는 음수가 될수없어, 이 printf문은 실패할 수가 없어 이런식으로 자기기만 훈련을 하지말고 코드로 나타내라.
📔언제 예외를 사용할까?
죽은 프로그램은 거짓말을 하지 않는다.에서 가능한 모든 에러를 체크하는 것이 좋다고 했는데 실제로 이렇게 하다보면 코드가 지저분해 질 수 있다.
예외는 예외적인 문제에 사용하라.
예외를 생성해서 해결하는 경우가 있다
예외를 정상적인 처리 과정의 일부로 사용하는 프로그램은 고전적인 스파게티 코드의 가독성 문제와 관리성 문재를 전부 떠안게 된다.
이런 프로그램은 캡슐화 역시 깨트린다.
내가 사용하는 JS에서는 try-catch문으로 if문으로 예외를 다 작성하지 않아도 쉽게 처리할 수 있어서 좋은 것 같다.
📔리소스 사용의 균형
코딩할 때 개발자들은 모두 리소스를 관리한다 하지만 많은 개발자들은 리소스의 할당과 해제를 다루는 일관적인 계획을 갖고 있지 않다.
시작한 것은 끝내라.
단순히 이 팁은 리소스를 할당하는 루틴이나 객체가 리소스를 해제하는 책임도 가져야한다는 것을 의미한다.
중첩할당
리소스 할당의 기본 패턴을 확장해서 한 번에 하나 이상의 리소스를 필요로 하는 루틴에 적용할 수 있다.
-
리소스를 할당한 순서의 반대로 해제하라.
이렇게 해야 한 리소스가 다른 리소스를 참조하는 경우에도 리소스를 고아로 만들지 않는다.
-
코드의 여러 곳에서 동일한 리소스 집합을 할당하는 경우 할당 순서를 언제나 갖게 하라.
교착 가능성이 줄어들 것이다.
