이 포스팅은 Development Method 시리즈 10 편 중 7 번째 글 입니다.
목차
- 신뢰성
- 지속가능성
- 성능
- 가독성
TDD
TDD workflow
sprint를 기준으로 설명!
- 코드를 짜기 전에, 명세서를 적는다.
- 함수 interface, 클래스 명세 등등
- 이를 위한 Test Code를 작성한다.
- 테스트를 수행한다. 통과하지 못하면 Production code 를 다시짠다.
- 다 통과했다면 refactoring한다.
sprint2
- sprint2에서 만들 기능을 정의하고 테스트 코드를 작성한다.
- Production 1의 정돈된 코드를 기반으로 해당 테스트 코드가 돌아가는지 확인한다.
- 만약 한개라도 true가 나온다면, 테스트코드를 잘못짠 것이다.
- production 2의 코드가 생산되지 않았는데 어떻게 통과?
- 모두 fail이 뜬다면 다음단계로 넘어간다.
- production 2코드를 작성한다.
- 테스트를 돌린다.
- 코드를 정돈한다.
- 굉장히 짧은 개발 과정을 반복하는 것!
- 테스트 케이스를 바탕으로 확인하면서 가는 과정
- 소프트웨어가 버전업되는 것을 경험하면서 갈 수 있음
- Agile은 얼마안됐지만, TDD는 사실 오래됐다.
- Kent Beck이 “재발견”했다.
- Agile하고 TDD가 잘 맞아떨어짐
- 기존에 있는 코드가 현재 요구사항을 만족하는지 확인할 때도 사용
- 안되면 안된 케이스에 대해 역량을 집중하는 것
TDD Cycle
- 1
- 테스트를 새롭게 작성한다.
- 매우 명확하고 심플하며 우리가 테스트하고 싶은 곳에만 집중해야 함
- 올바르게 동작했을 때, 잘못되었을 때 등
- 스펙, 요구사항에 대해 명확하게 이해한 사람이 할 수 있음
- 그래서 시퀀스 다이어그램 이런 것들이 중요한 것
- Use case에 대해 분석할 수 있어야 함
- 테스트 코드를 잘 짜는 사람이 더 실력이 좋음
- 두번째 부터는 수정된 테스트가 되는 경우가 많음
- 2
- 테스트를 돌려보고 통과하지 않는지 본다.
- 코드가 돌아가면 잘못된 것. 구현도 안했는데.
- Fail이 나야 한다.
- 3
- 코드를 짠다.
- 목표는? : 테스트를 패스하기 위한 코드를 작성한다.
- 이게 제일 중요. 우아하고 이딴거 필요없고. 요구사항만 만족해라
- 무조건 통과만 해라. 이 이상의 것을 하지마.
- +가 -가 될 가능성이 더 많을 수 있음
- 4
- 테스트를 돌린다.
- 이전에 만든 테스트까지 함께 돌린다.
- 새롭게 만든 테스트가 잘돌아가면 개발자는 기분좋아도된다.
- 근데 만약에 이전의 테스트가 안돌아간다?, 성능이 낮다?
- 지금 만든 코드에 의해 이전 코드가 훼손된 것.
- 문제를 찾거나, 안되면? Rollback..
- 5
- Refactor code
- 임시용 코드를 마스터에 집어넣는 과정
- Merge할 때, 코드를 예쁘게하는 방법
- 중복 제거
- 이런 것이 코드 리뷰
- 지속가능성과 신뢰성 향상, 즉 유지보수
- 이름 예쁘게 지어라.
- 상속 관계, 클래스 관계도 잘해야 함.
- 이런 걸 잘하는 사람이 경력이 많은 사람, 가이드라인을 잘 따라야 함
- 편집증 처럼 테스트를 주기적으로 계속해주는게 좋음, 조금씩 해서 테스트하는 방법 - 알고리즘짤때 처럼
- 반복..!
- 새로운 테스트, 새로운 코드가
- 너무 많은 양으로 하면 안되고, 적은, 적당한 양
- 여차하면 revert가 가능해야 한다.
- 남의 코드를 가져왔는데, 미심쩍으면 테스트 코드를 짜서 확인을 한다.
- A부서, B부서 나름의 TDD로 짠다.
- A에서 짠걸 B에서 테스트하겠다. -> A입장에서 놓치는 경향이 있을 수 있으니 하는게 맞다. 감정 상하지 말자.
- 남을 우째 믿냐.
- 남이 짠건 버그가 있다. 즉 철저하게 테스트를 하고 사용하는게 맞다. 믿지마.
- 본인이 짠 것 이상으로 테스트..
변형 형태
변형 형태
인포그래픽!
개발자스럽게 이해해보자.
- Keep the unit small
- 함수는 하나의 동작을 하도록 만들어야 하고, 명확하게.
- 함수가 명확할 수록 하기쉬움
- 그래야 디버그 노력이 줄어든다.
- 너무 코드가 잘짜여져 있으면 (작게, 명확하게) doc이 덜필요함
- 잘못 이해해서 일단 돌아가면 doc없어도 된다. 이게 아니고
- 잘 짜여진 코드가 있으면 없어도 된다가 맞는것
Unit Test
Unit test
- Test case
- Single test에 대해서 내가 원하는 하나의 케이스
- Test Suite
- 그 test case의 집합
- Test Runner
- 실제 이 테스트 케이스를 넣고 돌리는 녀석
Unit Test mock
mock 이해
- mockup : 모형을 한번 만들어 보는 것임
- mock object는 가짜 object!
- 실제 돌아가려면 필요한 객체가 있는데 이를 가짜를 사용해서 모사함으로써 프로그램의 동작을 확인하는 행위
- 위에서 초록색을 테스트하려면 상하좌우 퍼즐이 필요한데, 이를 오른쪽과 같이 생각하여 동작을 확인함
Profiling
- 프로그램을 분석함
- 프로그램의 메모리, 디스크, cpu 등의 분석
- 시간복잡도, 시간, 어디서 시간이 오래쓰이는지
- 사용하는 함수는 뭔지
- 함수의 call횟수는 얼마인지
- 이렇게 해서 최적화를 하는 것.
- 이런 것을 하도록 하는것이 profiler
- 파이썬은 이미 있다…
profile
Coding Guideline (Convention!)
- 가독성의 핵심이다.
- 아주 중요한 편
- 소프트웨어의 유지보수
- 가이드라인 체킹 프로그램도 있다. 하라는 걸 해.