구조적 프로그래밍

​

프로그래밍은 어렵고, 프로그래머는 프로그래밍을 잘하지 못했다. 모든 프로그램은 설령 단순할지라도 인간의 두뇌로 감당하기에는 너무 많은 세부사항을 담고 있었다.

​

데이크스트라는 증명(proof)이라는 수학적인 원리를 적용하여 이 문제를 해결하고자 했다. 그의 비전은 공리, 정리, 따름정리, 보조정리로 구성되는 유클리드 계층구조를 만드는 것이었다.

​

이 계층 구조를 사용하는 방식을 프로그래머도 사용할 수 있다고 믿었다.

​

이러한 이유로 데이크스트라는 이렇게 하려면 단순한 알고리즘에 대해 기본적인 증명을 작성할 수 있는 기법을 보여줘야 한다는 사실을 깨달았다.

​

연구를 진행하던 중 goto 문장이 모듈을 더 작은 단위로 재귀적으로 분해하는 과정에 방해가 되는 경우가 있다는 사실을 발견했다.

​

제어 구조는 순차 실행 (sequential execution)과 결합했을 때 특별하다는 사실을 깨달았고, 모든 프로그램을 순차(sequence), 분기(selection), 반복(iteration)이라는 세 가지 구조만으로 표현할 수 있다는 사실을 증명했다.

​

모듈의 증명 가능하게 하는 바로 그 제어 구조가 모든 프로그램을 만들 수 있는 제어 구조의 최소 집합과 동일하다는 사실이었다. 구조적 프로그래밍은 이렇게 탄생하였다.

​

​

현재의 우리 모두는 구조적 프로그래머이며, 여기에는 선택의 여지가 없다. 제어흐름을 제약 없이 직접 전환할 수 있는 선택권 자체를 언어에서 제공하지 않기 때문이다.

​

결국 프로그램 관점에서 정리에 대한 유클리드 계층구조는 끝내 만들어지지 않았다.

​

기능적 분해

​

구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해할 수 있게 되었고, 이는 결국 모듈을 기능적으로 분해할 수 있음을 뜻했다. 즉, 거대한 문제 기술서를 받더라도 문제를 고수준의 기능들로 분해할 수 있다. 그리고 이들 각 기능은 다시 저수준의 함수들로 분해할 수 있고, 이러한 분해 과정을 끝없이 반복할 수 있다.

​

​

​

테스트

​

데이크스트라는 “테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다”고 말한 적이 있다. 다시 말해 프로그램이 잘못되었음을 테스트르 통해 증명할 수는 있지만, 프로그램이 맞다고 증명할 수는 없다.

​

​

구조적 프로그래밍이 오늘날까지 가치 있는 이유는 프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 바로 이 능력 때문이다. 아키텍처 관점에서는 기능적 분해를 최고의 실천법 중 하나로 여기는 이유이기도 하다.