구조적 프로그래밍

에츠허르 비버 데이크스트라

• 소프트웨어를 과학으로 발전시키는데 큰 공헌을 함.
• 데이크스트라가 해결하고자 하는 문제가 있었음.
  • 프로그래밍에 체계가 없기 때문에 프로그래밍을 하더라도 믿을 수 있는 결과를 내놓기 어려움.
  • 수학적 증명을 통해 이 문제를 해결하고자 하였음.
    • 수학적 증명은 실패
    • 소프트웨어가 과학적 방법으로써 대상이 될 수 있는 상황을 마련.

goto문장

• 데이크스트라는 goto 문장이 모듈을 더 작은 단위로 재귀적으로 분해하는 과정에 방해가 되는 경우가 있다는 사실을 발견.
  • 모듈을 분해할 수 없다면, 합리적으로 증명할 때 필수적인 기법인 분할 정복 접근법을 사용할 수 없게 되기 때문.

if/then/else 와 do/while

• 데이크스트라는 goto문장을 사용하더라도 모듈을 분해할 때 문제가 되지 않는 경우도 있음을 발견.
  • if/then/else 와 do/while 는 goto문의 좋은 사용 방식으로써 분기와 반복이라는 단순한 제어 구조에 해당한다는 사실을 발견.
  • 모듈이 이러한 종류의 제어 구조만을 사용한다면 증명 가능한 단위로까지 모듈을 재귀적으로 세분화하는 것이 가능해 보인다고 판단.

구조적 프로그래밍의 탄생

• if/then/else 와 do/while 제어 구조의 발견이 의미하는 것은 모든 프로그램은 순차(sequence), 분기(selection), 반복(iteration) 이라는 세 가지 구조만으로 표현할 수 있다는 것이다.
• 이 발견은 놀라운 것인데, 모듈을 증명 가능하게 하는 바로 그 제어 구조가 모든 프로그램을 만들 수 있는 제어 구조의 최소 집합과 동일하다는 사실이고 이것은 곧 구조적 프로그래밍의 탄생을 의미한다.
• 컴퓨터 언어가 진화하면서 goto문장은 거의 사라졌다. → 현재의 우리 모두는 구조적 프로그래머이며, 여기에는 선택의 여지가 없다.

    제어흐름을 제약 없이 직접 전환할 수 있는 선택권 자체를 언어에서 제공하지 않기 때문이다.

  (물론 지원하는 언어도 있다. 중요한 것은 goto문이 해롭다는 점을 대부분의 언어가 인지하고 있다는 점)
  

모듈화의 시작

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

수학적 증명의 실패

• 데이크스트라의 수학적 증명은 실패하였음.
  • 세세한 기능 하나하나를 엄밀히 증명하는 고된 작업에서 얻을 수 있는 이득이 크지 않음.

과학적 방법

• 올바름을 증명하기 위해 수학적 방식을 사용해야 하는 것은 아니다.
• 과학적 방법은 증명은 불가능하지만, 반증은 가능하다.
• 과학은 서술된 내용이 사실임을 증명하는 방식이 아니라 서술이 틀렸음을 증명하는 방식으로 동작한다.
  • 반례를 들 수 없는 서술이 있다면 목표에 부합할 만큼은 참이라고 믿는다.

TDD

• 소프트웨어는 과학과 같다.
• 테스트를 통해 버그를 발견하여 프로그램이 잘못되었음을 증명할 수는 있지만 프로그램이 맞다고 증명할 수는 없기 때문이다.
  • 테스트에 충분한 노력을 들였다면 테스트가 보장할 수 있는 것은 프로그램이 목표에 부합할 만큼은 충분히 참이라고 여길 수 있게 해주는 것이 전부다.
• 구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요한다.
• 그러고 나서 테스트를 통해 증명 가능한 세부 기능들이 거짓인지를 증명하려고 시도한다.

결론

구조적 프로그래밍이 가치 있는 이유는

• 프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 능력이 있음을 나타낸다.
• 현대적 언어가 아무런 제약 없는 goto문장을 지원하지 않도록 한다.
• 아키텍처 관점에서 기능적 분해를 최고의 실천법 중 하나로 여긴다.

아키텍트 방향

• 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트하기 쉽도록) 만들기 위해 분주히 노력해야 한다.
• 이를 위해 구조적 프로그래밍과 유사한 제한적인 규칙들을 받아들여 활용해야 한다.