오늘 기다리던 이규원님의 TDD 인강이 1차 오픈되었다
현재 다른 플랫폼 넥스트스탭에서 실습위주의 TDD 진행중이지만
이규원님의 TDD 도 궁금해서 이전에 사전예약 구매하고 기다렸었다.
인강 달리고 흡수해야겠다.
코드 기능 명세
컴퓨터는 입력 요소를 출력 요소에 대입하는 도구다.
입력 요소는 시간, 난수 등 다양하다
출력 요소는 모니터 화면, 스피커로 듣는 소리, 데이터 전송 등 다양하다
이런 입력과 출력은 복합적인 조합으로 존재한다
게임만 봐도 복합적인 입력과 출력이 다양하게 존재한다
과연 이러한 입력과 출력에 대한 기대를 기능 명세라 한다.
이런 기능 명세는 어디서 등장할까?
도메인에서 시작된다.
도메인이란 소프트웨어가 풀어야 할 문제가 정의되는 공간을 말한다.
비즈니스 관련된 곳이라면 비즈니스 도메인을 이해해야 비즈니스 프로그램을 만들 수 있다.
도메인에서 시작된 지식은 비즈니스 전문가 -> 분석가 -> 개발자 -> 컴퓨터 순서로 가공되어 구현된다.
첫 시작은 추상적이며 단계를 지날 수록 구체적으로 변해 개발자가 도메인을 이해할 수 있게 가공된다.
다음은 이규원님이 개발자의 입장에서 보는 관점과
내 개인 생각을 더했다.
비즈니스 전문가 : 문제를 가장 잘 이해하지만 해당 문제에 대한 설명력이 부족하다. 문제에 대한 풀이도 이해한다고 착각한다.
-> 개발자 입장에서 흔히 말하는 '갑'이다. 설명을 잘하는 비즈니스 전문가를 만나면 해당 프로그램 구현은 편하게 진행이 된다. 설명을 대충하고 너무 뜬구름처럼 이야기하는 비즈니스 전문가도 있는데, 추후에 문제가 생기면 개발자보고 이런것도 말 안해도 해야되지 않냐고 따지는 몰상식한 사람도 존재한다. 복불복 성향이 깊다.
분석자 : 비즈니스 전문가로부터 요구사항을 분석하고, 잘못된 점을 탐색한다. 찾은 문제를 개발자에게 넘어가기전에 협업으로 해결한다.
-> '기획자'라 보면된다. 비즈니스 전문가의 부족한 설명을 제대로 파악하고 서로 소통하면서 정확한 요구사항을 파악하는게 핵심이다. 잘하는 분석자일 수록 개발자는 편해진다. 비즈니스 전문가의 요구사항을 잘못이해하거나 분석자 본인이 맞다면서 비즈니스 전문가한테 도메인으로 싸우는 사람이 간혹 본적도 있다. 도메인을 분석된 산출물로 기획서를 작성한다.
개발자 : 정제된 기능 명세를 아키텍처와 코드로 구현한다. 제품 제작 중 가장 비싼 작업이다. 문제를 효과적으로 해결하기 위해 끊임없이 설계한다. 이 흐름에서 가장 마지막에 접하는 인간이다.
-> 보통 분석자가 분석한 산출물을 기반으로 작업한다. 도메인에 대해서 화면 구성과 요구사항이 꼼꼼하게 설명되고, 입력된 값에 대한 예외처리 등 잘 분석하면 편하게 작업이 가능하다. 잘못된 비즈니스 전문가, 분석자를 만나면 힘든 개발이 된다.
컴퓨터 : 개발자가 입력한 코드를 전달받아 그대로 실행만 한다. 철저히 수동적이며 융통성이 없다.
개발자와 기능 명세
컴퓨터에 입력이 될 때에는 개발자가 도메인 지식을 이해한 상태여야 한다. 충분히 도메인 지식을 확보를 못했다면 지식 흐름 상류(분석자, 비즈니스 전문가)에게 보강을 요청해야한다. 만약 부족한 상태에서 개발자 스스로 판단하고 진행하면?
- 도메인 지식 투영에 오차가 발생한다
- 무책임하고 위험한 도박이 된다
막 시작한 스타트업 경우엔 개발자가 비즈니스 전문가, 분석가 역할을 해서 스스로 판단을 내리기도 한다.
-> 이런 경우 복불복 성향이 짚다. 개발자가 혼자 다 하는 것은 회사가 적은 돈으로 많은 이익을 내기위해 노예로 부리는 거면 미래가 없고 몸과 정신만 상하고, 반대로 제대로 가이드를 해주는 시니어가 있어서 이끌어주는 경우엔 많은걸 배울 수 있는 기회이다.
다음과 같은 요구사항으로 개발자가 프로그램을 만들었다고 생각해보자
요구사항
- 사용자가 분석될 통계 값을 입력한다
- 입력된 값들을 다 더하고 입력된 수 만큼 나눈다
public static void main(String[] args) {
double[] s = new double[args.length];
for (int i = 0; i < s.length; i++) {
s[i] = Double.parseDouble(args[i]);
}
double sum = 0;
for (double value : s) {
sum += value;
}
double variance = sum / (s.length);
System.out.println("variance = " + variance);
}
1,2,3,4,5 를 입력하고 다 더한 값은 15 가 나온다. 그리고 입력된 수 5 를 나누면
결과로 3이 나온다.
사용자가 요구사항대로 결과가 나오고 판매를 했다.
하지만 이후 사용자에게 클레임이 들어온다.
"값을 입력안하고 실행할 경우 이상한 결과가 발생한다"
개발자에게 값이 입력안되면 통계 값을 계산할 수 없다는 도메인 지식이 누락되어 이제서야 전달이 된거다.
누락된 도메인 지식을 반영한다.
public static void main(String[] args) {
if (args.length == 0) {
System.out.println("데이터가 입력되지 않았습니다.");
return;
}
double[] s = new double[args.length];
for (int i = 0; i < s.length; i++) {
s[i] = Double.parseDouble(args[i]);
}
double sum = 0;
for (double value : s) {
sum += value;
}
double variance = sum / (s.length);
System.out.println("variance = " + variance);
}
다시 값을 입력 안하고 실행해보자
누락된 도메인 지식이 잘 반영되었다.
제품을 업데이트 후 고객에게 배포하자
여기까지 코드 기능 명세에 대한 간단한 리뷰를 해봤다.
좀 더 자세한 이야기가 궁금하면 이규원님의 TDD 수업을 결제해서 보는 걸 추천드린다
'교육 및 인강 > 이규원의 현실 세상의 TDD' 카테고리의 다른 글
이규원님의 현실 세상의 TDD 기초, 6편 : 정리된 코드(리팩토링) (0) | 2021.04.14 |
---|---|
이규원님의 현실 세상의 TDD 기초, 5편 : 테스트 우선 개발 (0) | 2021.04.13 |
이규원님의 현실 세상의 TDD 기초, 4편 : 단위테스트 (2) | 2021.04.13 |
이규원님의 현실 세상의 TDD 기초, 3편 : 코드 분해 (0) | 2021.03.10 |
이규원님의 현실 세상의 TDD 기초, 2편 : 테스트 기법 (0) | 2021.03.10 |