4장. 구조적 프로그래밍

소개

클린아키텍처: 소프트웨어 구조와 설계의 원칙 책을 읽고 정리하며 소감을 적는 포스트입니다.

구조적 프로그래밍

증명

데이크스트라는 초기에 인식한 문제는 프로그래밍은 어렵고, 프로그래머는 프로그래밍을 잘하지 못한다는 사실이었다.

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

만약 모듈을 분해할 수 없다면, 합리적으로 증명할 때 필수적인 기법인 분할 정복 접근법을 사용할 수 없게 된다.

반면 goto 문장을 사용하더라도 모듈을 분해할 때 문제가 되지 않는 경우도 있었다. 데이크스트라는 이런 goto문의 '좋은' 사용 방식은 if/then/else와 do/while과 같은 분기와 반복이라는 단순한 제어 구조에 해당한다는 사실을 발견했다.

모듈이 이러한 종류의 제어 구조만 사용한다면 증명가능한 단위로까지 모듈을 재귀적으로 세분화하는 것이 가능해 보였다.

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

해로운 성명서

1968년 데이크스트라는 CACM(Communications of the ACM)에 goto문에 해로움이라는 편지를 썼고, 프로그래밍 세계는 불이 붙었다.

이 논쟁에서 데이크스트라가 승리했고 goto문은 사라졌다.

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

기능적 분해

구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해할 수 있게 되었고, 이는 결국 모듈을 기능적으로 분해할 수 있음을 뜻했다.

드워드 요던(Ed Yourdon), 래리 콘스탄틴(Larry Constantine), 톰 드마르코(Tom DeMarco), 밀러 페이지 존스(Meilir Page-Jones) 같은 이들은 이 구조적 분석, 설계와 같은 기법을 개선했고 더 널리 알렷다.

프로그래머는 대규모 시스템을 모듈과 컴포넌트로 나눌 수 있고, 더 나아가 모듈과 컴포넌트는 입증할 수 있는 아주 작은 기능들로 세분화 할 수 있다.

엄밀한 증명은 없었다.

대개의 프로그래머들은 세세한 기능 하나하나를 엄밀히 증명하는 고된 작업에서 이득을 얻으리라고는 보지 않았다.

결국 데이크스트라의 꿈은 빛을 바랬고, 사라졌다.

오늘날 이처럼 엄밀한 증명이 고품질의 소프트웨어를 생산하기 위한 적절한 방법이라고 믿는 프로그래머는 이제 거의 없다.

과학이 구출하다.

과학은 근본적으로 수학과 다른데, 과학 이론과 법칙은 그 올바름을 절대 증명할 수 없기 때문이다.

과학은 서술된 내용이 사실임을 증명하는 방식이 아니라 서술이 틀렸음을 증명하는 방식으로 동작한다.

수학은 증명 가능한 서술이 참임을 입증하는 원리라고 볼 수 있다. 반면, 과학은 증명 가능한 서술이 거짓임을 입증하는 원리라고 볼 수 있다.

테스트

데이크스트라는 테스트는 버그가 있음을 보여줄 뿐, 버그가 없을을 보여줄 수는 없다고 말한 적이 있다.

테스트에 충분한 노력을 들였다면 테스트가 보장할 수 있는 것은 프로그램이 목표에 부합할 만큼은 충분히 참이라고 여길 수 있게 해주는 것이 전부다.

예를 들어 제약 없는 goto문을 사용하는 등의 이류로 입증이 불가능한 프로그램은 테스트를 아무리 많이 수행하더라도 절대로 올바르다고 볼 수 없다.

구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요한다.

결론

가장 작은 기능에서부터 가장 큰 컴포넌트에 이르기까지 모든 수준에서 소프트웨어는 과학과 같고, 따라서 반증 가능성에 의해 주도된다.

소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트하기 쉽도록) 만들기 위해 분주히 노력해야 한다.