3

패러다임은 프로그래머에게서 권한을 박탈한다. 어느 패러다임도 새로운 권한을 부여하지 않는다. 각 패러다임은 부정적인 의도를 가지는 일종의 추가적인 규칙을 부과한다. 즉, 패러다임은 무엇을 해야 할지 보다 무엇을 하면 안 되는지를 말한다.

• 구조적 프로그래밍 : 제어흐름의 직접적인 전환에 대해 규칙을 부과한다.
• 객체 지향 프로그래밍 : 제어 흐름의 간접적인 전환에 대해 규칙을 부과한다.
• 함수형 프로그래밍 : 할당문에 대해 규칙을 부과한다.

세가지 패러다임은 각각 goto, 함수 포인터, 할당문을 뺏어간다.

우리는 더이상 빼앗길 것이 아마 없다. 따라서 프로그래밍 패러다임은 앞으로 세가지 이상 나오기 힘들 것이다.

4 구조적 프로그래밍

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

즉, 거대한 문제를 마주해도 고수준의 기능으로 분해할 수 있었다. 또한 이들은 다시 저수준의 함수로 분해할 수 있고, 이러한 분해는 끝없이 가능했다.

테스트

테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다

구조적 프로그래밍은 결국 프로그램이 맞다고 증명할 순 없다. 단지 증명가능한 세부 기능 집합으로 분해한 뒤 테스트를 통해 세부 기능이 거짓인지 증명한다. 만약 거짓임을 증명하는 테스트가 실패한다면, 이 기능은 충분히 참이라고 여기게 된다.

5. 객체 지향 프로그래밍

OO를 이용하면 아키텍트는 플러그인 아키텍처를 구성할 수 있고, 이를 통해 고수준의 정책을 포함하는 모듈은 저수준의 세부 사항을 포함하는 모듈에 대하 독립성을 보장할 수 있다.

고 수준의 정책을 포함하는 모듈과는 독립적으로 개발, 배포 가능하다. 이는 곧 개발 독립성, 배포독립성을 통한 팀의 효율성을 담당한다.

6. 함수형 프로그래밍

FP에서 우리는 내부의 서비스를 가변 컴포넌트와 불변 컴포넌트로 분리한다. 불변 컴포넌트에서는 순수함수형 방식으로만 작업이 처리되며, 어떤 가변 변수도 사용하지 않는다. 불변 컴포넌트는 변수의 상태를 변경할 수 있는, 즉 순수 함수형 컴포넌트가 아닌 하나 이상의 다른 컴포넌트와 서로 통신한다.

상태 변경은 컴포넌트를 갖가지 동시성 문제에 노출하는 꼴이므로, 흔히 트랜잭션 메모리와 같은 실천법을 사용하여 동시 업데이트와 경합 조건 문제로 부터 가변 변수를 보호한다.

현명한 아키텍트라면 가능한 한 많은 처리를 불변 컴포넌트로 옮겨야 하고, 가변 컴포넌트에서는 가능한 한 많은 코드를 빼내야 한다.

🖋️

참고

이벤트소싱 (opens in a new tab)에 대해 읽어봐라

지난 반 세기 동안 우리가 배운 것은 해서는 안 되는 것이다.

소프트웨어, 즉 컴퓨터 프로그램은 순차, 분기, 반복, 참조로 구성된다. 그 이상 그 이하도 아니다.