모든 프로그램 코드는 입력과 출력을 갖고 특정 입력에 대해 기대하는 출력이 있다. 이런 기대 동작들을 코드의 명세 또는 요구사항이라고 부른다.
오늘은 프로그래머가 코드 명세에 집중을 유지해야 하는 이유에 대한 강의를 들었다.
도메인
소프트웨어는 문제를 푸는 도구
도메인은 소프트웨어가 풀어야 할 문제가 정의되는 공간
문제를 이해하지 못하면 문제를 푸는 도구를 잘 만들 수 없다.
ex) 틱택토 게임을 이해하지 못하면 틱택토 컴퓨터 게임을 만들 수 없다.
비즈니스 시스템의 도메인 지식 흐름
비즈니스 전문가 -> 분석가 -> 프로그래머 -> 컴퓨터
지식 흐름의 상류로 갈수록 목적, 추상적이고, 지식 흐름의 하류로 갈수록 수단, 구체적이다.
비즈니스 전문가
- 문제를 가장 잘 이해한다.
-> 시스템이 투영해야 할 핵심 지식의 원천이다. - 문제 설명력 부족하다.
->문제에 대해 너무 잘 알고 있기 때문에 문제를 모르는 사람을 이해하지 못한다. - 풀이도 가장 잘 이해한다고 착각한다.
-> 문제를 말해야 할 때 풀이를 말하려는 경향을 가진다.
분석가
- 비즈니스 전문가로부터 시스템 요구사항을 발굴한다.
- 발굴된 요구사항의 오류를 탐색한다.
- 발견된 문제점을 구현 작업 전에 협업을 통해 해결한다.
프로그래머
- 정제된 기능 명세를 아키텍처와 코드로 번역한다.
-> 제품 제작 과정 중 비용이 가장 큰 작업이다. - 끊임없는 설계 결정한다.
- 지식 흐름 과정의 마지막인간이다.
컴퓨터
- 코드를 통해 프로그래머로부터 지식을 전달받는다.
- 철저히 수동적이다.
- 융통성이 없다.
프로그래머와 기능 명세
컴퓨터는 스스로 설계를 결정하지 않기 때문에 프로그래머가 도메인 지식을 컴퓨터에 전달할 땐 모든 요소들이 명확히 결정될 수 밖에 없다.
충분히 명확한 도메인 지식을 확보하지 못한 프로그래머는 지식 흐름 상류에 지식 보강을 요청해야 한다.
하지만 어떤 프로그래머는 스스로 결정을 내린다.
- 도메인 지식 투영에 오차 발생할 수 있다.
- 무책임하고 위험한 도박이다
회고
솔직히 지금까지 개발을 하면서 코드 명세를 보고 한 적이 없어서 잘 와닿지는 않았지만, 원하는 비즈니스로 만들기 위해서는 요구사항에 대해 잘 알아야 하기 때문에 코드 명세가 중요한 것 같다.
나중에 기회가 된다면 코드 명세를 보고 코드를 작성해보면 좋을 것 같다고 느꼈다.
백엔드 개발자