- 프로그래머는 프로그래밍을 잘하지 못하는 경우가 많다.
- 프로그램은 너무 많은 세부사항을 담고 있으며 이를 인간의 두뇌로 감당하기는 쉽지 않다.
- 데이크스트라는 "증명"이라는 수학적인 원리를 통해 이 문제를 해결하려 했다.
- 공리, 정리, 따름정리, 보조정리로 구성되는 유클리드 계층구조를 만들어 해결하는 것을 프로그래머들이 사용할 수 있다고 믿었다,.
- 즉, 프로그램은 입증된 구조를 이용하고, 이들 구조를 코드와 결합시키며, 코드가 올바르다는 사실을 스스로 증명
- 데이크스트라는 연구를 진행하며 goto문이 모듈을 재귀적으로 분해하는 과정에 방해가 되는 경우가 있다는 경우가 있는데 이 때문에 분할 정복을 사용할 수 없다는 사실을 발견.
- 하지만, goto문이어도 모듈을 분해할 때 문제가 되지 않는 경우가 있는데 이러한 경우는 if/then/else와 do/while과 같은 분기와 반복에만 해당된다.
- 이러한 제어구조들과 순차 실행과 결합했을때 특별하며 모든 프로그래밍을 순차, 분기, 반복이라는 세가지 구조만으로 표현할 수 있다.
- 반복은 증명하기 위해 귀납법을 사용했다.
- 처음에 goto를 제한하자는 증명이 나왔을 때에는 굉장히 많은 사람들의 저항에 부딛혔다.
- 하지만 컴퓨터가 발전하며 goto의 사용은 점점 줄게 되었고 지원하지 않는 언어들도 늘어났다.
- goto를 지원하는 언어의 경우에도 함수 내에서만 사용하도록 제한하는 편
- 구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해가능할 수 있게 되었다.
- 이는 결국 모듈을 기능적으로 분해할 수 있다는 것을 의미하며, 큰 문제의 기술서를 받아도 작은 단위로 분해할 있다는 의미이기도 하다.
- 이렇게 분해한 기능들은 프로그래밍에 제한된 제어 구조를 이용하여 표현할 수 있다.
하지만 증명은 되지 않았으며, 프로그램 관점의 유클리드 계층구조는 끝내 만들어 지지 못했다.
유클리드 방식 같은 엄밀한 수학적인 증명만이 있지 않고 상당히 다른 성공적인 전략으로 과학적 방법이 있다.
과학은 수학과는 다르게 서술된 내용이 사실임을 증명하는 방식이 아니라 서술이 틀렸음을 증명하는 방식으로 동작한다.
즉 수학은 서술이 참임을 밝히는 방식으로 돌아간다면 과학은 틀렸음을 증명하는 방식으로 동작한다.
테스트는 버그가 있음을 보여줄 수는 있어도 버그가 없음을 보일수는 없다.
테스트를 통해 프로그램이 목표에 부합하도록 작동하는 것을 증명하는 것에서 그치는 것이지 프로그램이 충분히 참이라고는 여길 수 없다.
그러므로 소프트웨어는 수학적인 시도가 아닌 과학적인 시도로 봐야한다.
구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요한다.
테스트를 통해 증명 가능한 세부 기능들이 거짓인지를 증명하려고 시도한다.
이처럼 거짓임을 증명하려는 테스트가 실패한다면, 이 기능들은 목표에 부합할 만큼은 충분히 참이라고 여기게 된다.
- 구조적 프로그래밍이 오늘날까지 가치 있는 이유는 프로그래밍에서 반증 가능한 단위로 만들어 낼 수 있는 바로 이 능력 때문이다.
- 현대적인 언어가 이를 위해 제약 없는 goto문을 지원하지 않는 이유이기도 하다.
- 그러므로 소프트웨어는 모듈, 컴포넌ㅌ, 서비스가 쉽게 반증이 가능하도록 만들기 위해 노력해야 한다.
- 개발자들은 구조적 프로그래밍과 유사한 제한적인 규칙들을 받아들여 활용해야 한다.