[클린 아키텍처] 4. 구조적 프로그래밍

햄도·2021년 6월 26일
0

Clean Architecture

목록 보기
4/11

출처

클린 아키텍처를 읽으며 정리한 내용입니다.

4. 구조적 프로그래밍

증명

  • 다익스트라가 처음 인식한 문제 → 프로그래밍은 어렵고, 프로그래머는 프로그래밍을 잘 하지 못한다.

  • 단순한 프로그램도 복잡한 세부사항을 담고 있고, 하나라도 간과하면 예상 외 방식으로 실패

  • 증명이라는 수학적 원리를 이용해 해결해보자!

    → 프로그래머가 입증된 구조를 이용하고, 이 구조를 코드와 결합시키며 코드가 올바르다는 사실을 스스로 증명하게 되는 방식

  • 단순한 알고리즘에 대해 기본적인 증명을 작성할 수 있어야 함. (힘들다..)

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

  • 모듈을 분해할 수 없게 되면 분할 정복 접근법으로 증명할 수도 없다

  • 반면 goto문의 좋은 사용 방식은 모듈을 분해할 때 문제가 되지 않음

    → if/then/else, do/while 같은 분기와 반복

  • 위와 같은 제어 구조는 순차 실행과 결합했을 때 특별해진다

  • 모듈을 증명 가능하게 하는 바로 그 제어 구조가 모든 프로그램을 만들 수 있는 제어구조의 최소 집합과 동일!

    → 구조적 프로그래밍의 탄생

  • 그럼 프로그램을 어떻게 증명할 수 있을까?

    • 순차 구문: 단순한 열거법을 이용해 입력부터 출력까지 수학적으로 추적

    • 분기: 분기를 통한 각 경로를 열거한 후 순차 구문과 같이 추적

    • 반복: 1의 경우가 올바름을 증명하고, N의 경우가 올바르다고 가정한 후 N+1의 경우도 증명하는 귀납법 사용

      → 이렇게 프로그램도 증명할 수 있게 되는 것 같았지만. . .

해로운 성명서

  • 다익스트라가 쓴 goto문의 해로움이라는 글로 인해 프로그래밍 세계는 불이 붙었다
  • 지금처럼 온라인으로 비난할수는 없었지만 반대하는 사람들은 많은 학술지 출판사의 편집자에게 편지를 보냄
  • 결국은 다익스트라가 이겼다. goto문은 컴퓨터 언어의 진화에 따라 밀려났다.
  • 현재의 우리 모두는 모두 구조적 프로그래머이고, 언어에서 제어흐름을 제약 없이 직접 전환할 수 있는 선택권을 주지 않기 때문에 여기에는 선택의 여지가 없다.
  • 비슷한 것(break 등)이 있긴 하지만 제약이 존재한다.

기능적 분해

  • 구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해할 수 있게 되었고, 이는 모듈을 기능적으로 분해할 수 있음을 의미
  • 이러한 기법을 사용하면 대규모 시스템도 모듈과 컴포넌트, 더 나아가 입증할 수 있는 작은 기능들로 세분화할 수 있다.

엄밀한 증명은 없었다

  • 하지만 끝내 증명은 이루어지지 않았다.
  • 오늘날 엄밀한 증명이 고품질의 소프트웨어를 생산하기 위한 적절한 방법이라고 믿는 프로그래머는 이제 거의 없다.
  • 수학적 증명은 이루어지지 않았지만, 다행히도 과학적 방법은 상당히 성공했다.

과학이 구출하다

  • 과학 이론과 법칙은 반증은 가능하지만, 그 올바름을 절대 증명할 수 없다.
  • 과학은 서술된 내용이 사실임을 증명하는 방식이 아니라 서술이 틀렸음을 증명하는 방식으로 동작한다. 노력해도 반례를 들 수 없는 서술이 있다면, 목표에 부합할 만큼은 참이라고 본다.
  • 어찌보면 믿음직하지 않지만, 우리는 자동차를 타고, 한 걸음을 내딛을 때마다 이 법칙들에 모든 것을 건다.

테스트

  • 다익스트라: "테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다"
  • 충격적이게도, 소프트웨어 개발이 수학적인 구조를 다루는 것처럼 보이지만 소프트웨어 개발은 수학적인 시도가 아니라, 오히려 과학과 같다.
  • 최선을 다하더라도 올바르지 않음을 증명하는 데 실패함으로써 올바름을 보여주기 때문
  • 이러한 부정확함에 대한 증명은 입증 가능한 프로그램에만 적용할 수 있다. 제약 없는 goto문을 사용하여 입증이 불가능한 프로그램은 테스트를 아무리 많이 수행하더라도 올바르다고 볼 수 없다.
  • 구조적 프로그래밍은 프로그래밍을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요한다.
  • 그러고 나서 테스트를 통해 증명 가능한 세부 기능이 거짓인지를 증명하려고 시도한다.
  • 이 테스트들이 실패함으로써 이 기능들은 목표에 부합할 만큼은 충분히 참이라고 여기게 된다.

결론

  • 구조적 프로그래밍이 지금까지 가치있는 이유는 프로그래밍에서 반증 가능한 단위를 만들어낼 수 있기 때문이다.
  • 따라서 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스를 쉽게 테스트할 수 있도록 만들어야 한다.
profile
developer hamdoe

0개의 댓글