프로그래밍 패러다임 - 구조적 프로그래밍

- 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.)

- 문제인식 및 아이디어

데이크스트라는 아무리 간단한 프로그램이라도 컴퓨터에게 명령을 하려면 디테일한 세부사항까지 지시를 해야하기 때문에 프로그램이 의도한대로 동작하는것이 힘들다는 문제 인식을 하였다.

 

데이크스트라는 수학자가 유클리드 계층구조를 사용하는 방식을 프로그래머도 사용할 수 있다고 믿었다. 이 연구를 진행하면서 모듈을 재귀적으로 분해하는 과정에서 goto 문장이 방해가 된다는 사실을 발견하였다. 모듈을 재귀적으로 분해할 수 없다면, 알고리즘 풀이방법중 하나인 분할정복을 사용할 수 없게 된다.

 

반면 문제가 되지 않는 goto문의 사용방식이 있었는데, 이는 분기(if/then/else) 와 반복(do/while) 이라는 단순 제어구조라는 사실에 주목한다.

 

데이크스트라는 goto문의 해로움이라는 글을 기고하였고, 이 글은 콜로세움을 개최하였다. goto 문은 결국 역사한편으로 사라졌고 데이크스트라는 승리하였다.

 

이런 구조적 프로그래밍 입각하에서 프로그래머들은 고수준의 기능들을 분해하고 이를 재귀적으로 반복하여 기능들 단위까지 분해하였다. 그리고 기능들을 제한된 제어구조로 구현하였다.

---

- 한계점

하지만 데이크스트라가 기대했던 유클리드 계층구조를 사용하여 프로그램이 무결하다는 증명을 함으로써 오류가 없는 프로그램을 만들고자했던 바람까지는 이루지 못하였다. 

 

우리의 JUnit 테스트를 과정을 떠올려 보자. 테스트케이스를 만든다. 경계조건 값들, 사용자가 절대 그렇게 입력할리는 없지만 그러한 입력에서도 시스템이 죽지 않거나 적절한 반응을 보여야 하는 값들, 일반적으로 정상동작하는 값들 데이터를 설계하고 수행한다. 초록불이 뜨면 마음의 평화가 찾아오고 안심한다.

 

이제 이 기능은 완벽하고 무결하며 수학적으로 증명이 되었는가? 대다수의 케이스에서는 동작하겠지만, 수학적으로 무결하며 완벽함을 입증했다고 말할 순 없다. 과학적으로 접근하였을 뿐이다. 테스트케이스에 대해 버그가 있느냐를 확인을 한것이지, 아예 버그가 없는 무결한 코드이다라는 것은 알수가 없다.

---

- 결론

이 글을 보면서 이런 이론적인 것에 관심이 없어 흥미가 없을수도 있다. 그래서 코드를 어떻게 짜야 하는건지, UML을 어떻게 그려야 하는건지 결론이 무엇인지만 궁금한것이라면 한 가지만 기억하면 된다고 생각한다. 

 

구조적 프로그래밍은 goto문을 제한하여 기능적인 분해를 할 수 있게 도와준 패러다임이다.