[clean Architecture책] 4장
4장. 구조적 프로그래밍
</br>
테스트
‘테스트는 버그가 있음을 보여줄 뿐, 버그가 없을을 보여줄 수는 없다’고 말한 적이 있다. 즉, 프로그램이 잘못되었음을 테스트를 통해 증명할 수는 있지만, 프로그램이 맞다고 증명할 수는 없다. 테스트에 충분한 노력을 들였다면 테스트가 보장할 수 있는 것은 프로그램이 목표에 부합할 만큼은 충분히 참이라고 여길 수 있게 해주는 것이 전부다. 이는 소프트웨어 개발이 수학적인 구조를 다루듯 보이더라도 그렇지 않다는 것이다. 오히려 소프트웨어는 과학과 같다.
이러한 부정확함에 대한 증명은 입증 가능한 프로그램에만 적용할 수 있다. 예를 들어, 제약 없는 goto문을 사용하는 등의 이유로 입증이 불가능한 프로그램은 테스트를 아무리 많이 수행하더라도 절대로 올바르다고 볼 수 없다.
구조적 프로그래밍은 프로그램을 증명가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요한다. 그러고 나서 테스트를 통해 증명 가능한 세부 기능들이 거짓인지를 증명하려고 시도한다. 이처럼 거짓임을 증명하려는 테스트가 실패한다면, 이 기능들은 목표에 부합할 만큼은 충분히 참이라고 여기게 된다.
</br>
결론
구조적 프로그래밍이 오늘날까지 가치 있는 이유는 프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 바로 이 능력 때문이다. 또한 goto문장은 지원하지 않는 이유이기도 하다. 뿐만 아니라, 아키텍처 관점에서 기능적 분해를 최고의 실천법 중 하나로 여기는 이유이기도 하다.
가장 작은 기능에서부터 가장 큰 컴포넌트에 이르기까지 모든 수준에서 소프트웨어는 과학과 같고, 따라서 반증 가능성에 의해 주도된다. 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트하기 쉽도록) 만들기 위해 분주히 노력해야 한다.