📑코드 기능 명세
1. 도메인
- 소프트웨어는 문제를 푸는 도구
- 도메인은 소프트웨어가 풀어야 할 문제가 정의되는 공간
- 문제를 충분히 이해하지 못하면 도구를 잘 만들 수 없다
2. 비즈니스 시스템의 도메인 지식 흐름
비즈니스 전문가
- 문제를 가장 잘 이해
- 문제 설명력 부족 (상대방이 당연히 알거라는 착각)
- 풀이도 가장 잘 이해한다고 착각
분석가
- 비즈니스 전문가로부터 시스템 요구사항을 발굴
- 발굴된 요구사항의 오류 탐색
- 구현 작업 전 비즈니스 전문가와 프로그래머 둘 다하고 긴밀하게 소통해야함
- 요구사항이 모순되거나 구현 가능한지 판단
- 코드 고치는 작업의 비용이 매우 높기에 매우 중요한 과정
프로그래머
- 정제된 기능 명세를 아키텍쳐와 코드로 번역
- 제품 제작 과정 중 비용이 가장 큰 작업
- 설계 결정을 끊임없이 해야함
- 지식 흐름 과정에서 마지막 인간
컴퓨터
- 코드를 통해 프로그래머로부터 지식을 전달받음
- 철저히 수동적
- 융통성 없음
3. 프로그래머와 기능 명세
- 충분히 명확한 도메인 지식을 확보하지 못한 프로그래머는 지식을 보강을 요청해야함
- 하지만 어떤 프로그래머는 스스로 결정을 내림
- 도메인 지식 투영에 오차 발생
- 무책임하고 위험한 도박
💻테스트기법
1. 수동테스트
- 품질 담당자가 UI를 사용해 기능을 검증
- 최종 사용자의 사용 경험과 가장 비슷하게 검증
- 실행 비용이 높고 결과의 변동이 큼
- 가장 온전한 코드 실행
- 인수 테스트
소프트웨어 회귀
원래는 동작하다가 어떤 사건 이후로 작동이 안됨
2. 테스트 자동화
- 기능을 검증하는 코드를 작성
- 테스트 코드 작성 비용이 소비되지만 실행 비용이 낮고 결과의 신뢰도가 높음
- 테스트 코드 작성과 관리가 프로그래머 역량에 크게 영향 받음
3. 인수 테스트
- 배치된 시스템을 대상으로 검증
- 전체 시스템 이상 여부 신뢰도가 높음
- 하지만 매우 높은 비용 (작성, 관리, 실행)
- 피드백 품질이 낮음 -> 현상은 드러나지만 원인은 숨겨 짐
4. 단위 테스트
- 시스템의 일부를 대상으로 검증
- 낮은 비용 (작성, 관리, 실행)
- 높은 피드백 품질 -> 원인을 알아내기가 쉬움
- 전체 시스템 이상 여부 신뢰도가 낮음
📘코드분해
1. 문제의크기
- 프로그래머가 한번에 다룰 수 있는 문제의 크기는 한계를 가짐
- 프로그래머는 더 큰 문제를 자주 마주함
- 시스템의 크기는 점점 커짐
- 큰 문제는 작은 문제로 분해할 수 있음
- 작은 문제의 일부는 반복됨
- 한번 쓰여진 코드는 여러번 읽혀지게 된다
- 코드 가독성이 생산성에 큰 기여
2. 코드 재사용
- 반복되는 문제의 풀이는 재사용 가능
- 소프트웨어 개발 비용 절감
3. 모듈화
분해
- 큰 시스템은 더 작은 하위 시스템으로 분해 가능
- 교체 가능
조립
- 작은 시스템은 더 큰 상위 시스템으로 조립 가능
- 모듈 재사용
- 라이브러리
📗단위테스트
ex) 공백 문자 없애주는 테스트(Javascript)
1. 공백문자 2개, 4개, 3개 각각 작성
- 2,4 성공 3 실패
2. for loop를 통해 테스트 작성
- 어떤 테스트에 대해서 실패하였는지 보여주지 않음
- 중간에 실패하면 이후 테스틑 성공 여부를 알 수 없음
3. 파라미터라이즈 테스트
- 테스트 테이블 작성
- 한번에 테스트 하지만 결과는 각각 따로 출력
📕 테스트 주도 개발
1. 테스트 코드를 먼저 작성
- 명확하고 검증 가능한 목표를 설정한 후 목표를 달성
- 프로세스가 코딩에 앞선 목표 설정을 강요
- 프로그래머는 자신이 풀어야 할 문제를 구제적으로 이해해야 함
2. 리팩터링
의미를 유지하며 코드베이스를 정리
더 단순하게 표현
2. 테스트 실패
- 구체적인 하나의 요구사항을 검증하는 하나의 테스트를 추가
- 추가된 테스트가 실패하는지 확인
- 실패하는 것을 확인해야 테스트가 동작함을 믿을 수 있다
- 운영 코드 변경이 진행되지 않았기 때문에 실패했는지 확인해야 한다
3. 테스트 성공
- 추가된 테스트를 비롯해 모든 테스트가 성공하도록 운영 코드를 변경
- 테스트 성공은 요구사항 만족을 의미 (코딩의 가장 중요한 임무)
- 테스트 성공을 위한 최소한의 변경 (가장 중요한 임무를 가장 빠르게 안수)
4. 리팩터링
- 의미를 유지하며 코드베이스를 정리
- 구현설계 개선 - 가독성, 적응성, 성능
- 모든 테스트 성공을 전제
켄트 벡의 설계 규칙 (2,3 충돌 가능)
1. passes the tests
2. reveals intention
3. no duplication
4. fewest elements
5. 테스트 주도 개발 세부 흐름
6. 테스트 주도 개발의 비용
- 시간이 길어질수록 TDD 사용하는 것이 유리
- 모든 개발에서 TDD를 해야하는 것은 아님
7. 테스트 도구
- 기술 생태계의 테스트 도구 지원이 테스트 작성 비용에 큰 영향
- 풍부한 테스트 도구는 테스트 코드가 도메인 지식 표현에 집중하도록 응집도와 가독성을 높임
☀️프로그래머 피드백
1. 여러가지 피드백
사용자 피드백
- 사용자가 직접 코드를 사용한 후 경험한 버그나 불만을 제보
Quality Assurance
- 전문 인적 자원에 의한 인수 테스트
프로그래머 테스트
- 프로그래머가 직접 피드백 장치를 준비
- 조금 더 이른 시점에 피드백 가능
도구 피드백
- 컴파일 오류, 정적 검사 등 프로그래머가 사용하는 도구가 제공하는 피드백
2. 오버엔지니어링
- 프로그래머는 요구사항 명세에 명확히 지정되지 않은 성능 달성이나 구현 설계 품질 개선에 빠져드는 경향을 가짐
- 이런 목표는 지나치면 더 중요한 목적, 기능 요구사항에 써야 할 자원을 불필요하게 낭비하게 됨
- 테스트 주도 개발은 가장 중요한 목표를 우선 달성하도록 유도
- 오버엔지니어링에 빠졌음을 느낄 때 안심하고 다음으로 나아갈 수 있도록 피드백을 제공
3. 핵심은 피드백
- 테스트 주도 개발의 핵심은 정해진 절차가 아니라 짧은 주기로 지속되는 피드백
- 피드백에 기반에 안정적으로 지삭과 코드를 늘려 나가는 것이 목적
