클린 아키텍처를 보는데 구조적 프로그래밍 편에서 대충 이러이러하다 뭐 그런건 알겠는데..
사실 그래서 구조적 프로그래밍이란게 어떤 것을 의미하는 건지 딱 와닿지 않는달까..
일단 이것저것 먼저 참고하려고 찾아본 내용들!
뭔가 더 좋은 자료들이 있다면 알려주세요..ㅎ
구조적 프로그래밍은 구조화 프로그래밍으로도 불리고
프로그래밍 패러다임의 일종인 절차적 프로그래밍(Procedural Programming)의 하위 개념으로 볼 수 있다.
이 패러다임은 GOTO문을 없애거나 GOTO문에 대한 의존성을 줄여주었음
이 때 절차적 프로그래밍은 단순히 순차적인 명령 수행을 하는 것이 아니라 루틴, 서브루틴, 메소드, 함수 등(이것들을 프로시저라고 한다고 함)을 이용한 프로그래밍 패러다임을 의미함.
따라서 절차적 프로그래밍의 중요한 점은 반복될 가능성이 있는 모듈을 재사용 가능한 프로시저(함수) 단위로 나누는데 있다
함수(function) : 특정 계산을 수행하며 리턴값이 있음. 수식 내에서만 사용할 수 있으며 함수 단독으로 문장을 구성할 수 없음. 함수는 기능을 수행해서 어떠한 목적(결과)을 도출해 내는 것
프로시저(procedure) : 특정 작업을 수행하며 리턴값이 없음. 리턴값이 없으므로 수식 내에서는 사용할 수 없으며 단독으로 문장을 구성할 수 있음. 프로시저는 수행하는 절차 그 자체를 목적으로 하는 것
→ 함수는 프로시저를 포함하는 개념임. 이러한 프로시저를 포함한 함수들이 여러 개 모여 하나의 프로그램을 구성하는 것을 절차적 프로그래밍이라고 함
절차적 프로그래밍이 발전한 형식이 구조적 프로그래밍인데 절차적 프로그래밍이 함수를 기준으로 나뉜다면 구조적 프로그래밍은 모듈을 기준으로 나뉜다고 한다.
(이 때, 모듈이라는 개념이 애매하지만 일반적인 개념으로는 물리적인 소스파일을 의미)
그래서 클린 아키텍처의 내용을 나름대로 정리해보자면
데이크스트라가 증명하고 싶었던 것?
→ 프로그램 관점에서 정리에 대한 유클리드 계층 구조를 만드는 것?
(결과적으로 fail)
데이크스트라는 goto 문이 모듈을 더 작은 단위로 재귀적으로 분해하는 과정에 방해가 되는 경우가 있다는 사실을 발견
하지만 반대로 goto 문이 모듈 분해에 문제가 되지 않는 경우도 있었음
→ if/then/else 와 do/while 같은 분기와 반복이라는 1)단순한 제어 구조인 경우 였음
→ goto 문의 좋은 사용 방식
이 1)제어 구조 가 순차 실행 sequential execution 과 결합했을 때 특별함을 알게되었음
근데 그 전에 뵘Böhm 과 야코파니Jacopini가 모든 프로그램은 순차 sequence, 분기 selection, 반복 iteration 세 가지 2)구조만으로 표현할 수 있다는 것을 증명함
→ 모듈을 증명 가능하게 하는 1)제어 구조가
모든 프로그램을 만들 수 있는 2)제어 구조의 최소 집합과 동일하다는 것을 깨달음
구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해할 수 있게 되었고,
이는 결국 모듈을 기능적으로 분해할 수 있음을 뜻함
거대한 문제 기술서 → 고수준 기능으로 분해 → 저수준 함수로 분해
: 기능을 계속해서 분해할 수 있음
→ 이렇게 분해된 기능들을 구조적 프로그래밍의 제한된 제어 구조를 이용하여 표현할 수 있음
하지만 결과적으로 수학적인 증명은 실패했음
(모든 것들이 옳다는 것을 증명하는게 어렵기 때문인가?)
그렇지만 증명을 하는 방법에는 과학적 방법도 있음
잠시 과학적 방법에 대해 설명해보자면
- 반증은 가능하나 증명은 불가
- 서술된 내용이 사실임을 증명하는 것이 아니라, 서술이 틀렸음을 증명하는 방식
- 수학적 방법 : 증명 가능한 서술이 참임을 입증하는 원리
- 과학적 방법 : 증명 가능한 서술이 거짓임을 입증하는 원리
데이크스트라
“테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다”
→ 프로그램이 잘못되었음을 테스트를 통해 증명할 수 있지만, 프로그램이 맞다고 증명할 수는 없다
→ 거짓임을 증명하려는 테스트가 실패한다면, 이 기능들은 목표에 부함할 만큼은 충분히 참이라고 여기게 된다
따라서 결과적으로
구조적 프로그래밍이 오늘날까지 가치있는 이유는
프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 능력 때문
(모듈화를 할 수 있다는 것을 의미하는 것 같음)
→ 아키텍처 관점에서 기능적 분해를 최고의 실천법 중 하나로 여기는 이유
→ 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트하기 쉽도록) 만들기 위해 노력해야 함
결과적으로 내가 이해한 바는
기존 프로그래밍 방식은 goto문이 많은 비구조적 프로그래밍 이었던 것임
근데 일부 형태에서 분기 되거나 반복되는 부분이 있다는 것을 알게되었고 이러한 부분에 대해 모듈화를 할 수 있겠다는 생각이 든거지
이러한 프로그래밍 방식을 수학적으로 증명하고 싶었으나 쉽지 않았고 (모든 것이 옳다는 것을 증명해야하니까)
이러한 모듈화를 통한 구조적 프로그래밍 방식이 각각의 기능(모듈)에 대해 반증이 가능한 형태를 제공하는 거임
'# Reading > --- 개발서적' 카테고리의 다른 글
| [Clean Code] 6장. 객체와 자료 구조 (0) | 2022.03.01 |
|---|---|
| [Clean Code] 5장. 형식 맞추기 (0) | 2022.02.28 |
| [Clean Code] 4장. 주석 (0) | 2022.02.25 |
| [Clean Code] 3장. 함수 (0) | 2022.02.23 |
| [클린 아키텍처] 객체 지향 프로그래밍 (0) | 2021.04.19 |