현실 세상의 TDD 를 보면서 개인적인 생각 정리

1부 기초

좋은 코드?

* No silver bullet (trade-off)

* 협업 가능한 코드

* 서로의 기준을 충족 하는 코드 <= 목적을 달성 하는 코드

 

개발 카톡방에서 자주 "임금님 귀는 당나귀 귀" 사례

1. 왜 옆동네에서 제공하는 API 는 이모양일까?

2. 왜 이런 식으로 코드가 짜여진거지?

3. 레거시 등의 불편불만

=>  당시 개발자의 지식(외부 + 내부 도움)내의 최선의 선택이였고, 비즈니스를 잘 수행했다면 좋은 코드고 이를 개선하는 코드를 작성하는 것은 멋진 경험이라고 생각합니다. 신기능도 즐겁지만, 당시에 코드 작성자가 어떤 생각이였고, 이를 추적하는 과정도 즐거움의 과정

 

코드명세?

문제를 정의하고(Input), 해결(Output) 하기 위한 명세

프로그래머는 정제된 기능 명세를 아키텍처와 코드로 번역

개인적으로 조엘 온 소프트웨어 책의 손 쉬운 기능 명세 작성법이 큰 도움이 되는 것 같음.

코딩의 시간이 길어질수록 비용은 오름(개발자에 따라 선형적, 지수적일 수도 있음) => 따라서 코드 명세 중요!

 

도메인

ex) 게임을 만드는데 게임의 룰을 이해하지 못한다면? 당연히 만들수 없음.

=> 도메인은 메우 중요함.

=> 코드를 짜기 시작할 때는 도메인 지식이 명확하게 결정되어 있어야하고, 부족하다면 적절히 요청하여 습득 해야됨.(스스로 결정을 내리면 리스크를 가질 수 있음)

=> 도메인 요구조건이 자주 바뀐다? => 개발자는 어려움을 느낄 수 있음.

 

소프트웨어 회귀(리그레이션)

=> 동작하던 기능이 어떤 이벤트 이후로 동작하지 않는 것

코드는 결합되어 있고 예상치 못한 결과를 만들 수 있음

A, B, C, D 기능이 만들어져 있고, E 기능만 추가되었다고 A, B, C, D 기능이 정상 동작할 것이라는 100 % 보장이 어려운 경우가 빈번히 존재 => 결과적으로 A, B, C, D 도 테스트가 수행되어야 하는데 비용이 발생.

 

테스트 자동화(강의 참고)

기능을 검증하는 코드를 작성

테스트 코드 작성시 비용이 들지만, 실행 비용은 낮고 결과의 신뢰가 높음

But . 테스트 코드 관리가 필요하고 프로그래머 역량에 크게 영향을 받음

 

인수 테스트(강의 참고)

개발이 완료되어야 진행되는 경우가 많음

비용이 높음

피드백의 품질이 낮음(현상은 드러나지만, 원인 판단이 어려울 수 있음 = 부족한 피드백)

 

단위 테스트(강의 참고)

시스템의 일부를 검증

낮은 비용

높은 피드백 품질

But 전체 시스템 신뢰도는 낮음

 

코드 분해

작은 단위 => 테스트 코드를 작성하기 쉬움, 재사용되기 쉬움, 다른 시스템과 조합 가능 => 비용 절감

현실의 문제는 프로그래머가 한번에 다룰 수 있는 문제의 크기보다 클 수 있음 -> Divide Conquer(분할 정복) 해야됨

문제를 분할하고 작성하는 중에 이미 경험했던 작업이 있을 확률도 있고, 작고 디테일한 문제일 수로그 웹서핑을 통해 힌트를 얻을 확률이 높아짐(자신감 상승)

 

모듈화

인터페이스/구현으로 크게 볼 수 있음(느슨한 설계)

인터페이스 : 행위(ex. 저장하다)

구현 : 실제 행위에 대한 구현(ex. 로컬에 저장하다, 서버에 저장하다)

 

이미 동작하는 프로덕트 코드에 기능 추가가 필요하다면, 추가되는 테스트 케이스(+ 이전 동작에 대한 테스트 케이스도 함께 작성되면 시너지 냄)를 작성하고 통과하면 프로덕트 코드의 모양새가 합리적이지 않아도 신뢰를 높일 수 있음(건드리기 어려운 레거시에 대한 접근)

 

하나의 테스트 안에 다른 테스트 들을 진행하지 않음

=> A 테스트 안에 B, C 테스트가 존재하고 B 테스트 실행중 에러가 발생하면 A, C 테스트를 검증할 수 없음 => ParameterizedTest 를 활용해볼 수 있음

ex. https://github.com/JavaUnit/AutoParams

 

테스트 우선 개발

=> 운영 코드 보다 테스트 코드를 먼저 작성(Red -> Green)

=> 테스트를 미리 작성하며 기획에서 부족한 부분이나, 개선점, 어려운 부분등을 조기에 발견할 수 있음

 

정리된 코드

=> 생산성에 영향을 미침

어떤 책인지는 기억이 나지 않지만 깨진 유리창 법칙이 생각났음.(클린 코드였던 것 같음.)

=> 오늘 작성한 코드는 내일의 작업 환경이 됨

 

켄트 백의 설계 규칙

1. 모든 테스트에 대해 성공시키기

2. 코드가 어떤 일을 하는지 의도를 노출 시킨다(가독성)

3. 중복되는 코드를 제거한다

* 2, 3 번의 규칙은 서로 상충될 수 있다고 함(ex. 가독성을 높이기 위헤 중복을 허용한다)

4. 테스트 통과에 필요하지 않은 코드는 최소한을 유지한다

 

테스트 주도 개발은 낯설지 않음

* 개발자에게 개발하고, 버그가 발생하면 코드를 수정하고 버그가 재현되는지 확인하는 물리적인 과정은 너무나도 익숙하고 해당 과정을 "코드로 대신한다" 라고 생각하면 됨

 

TDD 도입 여부는 항상 이득인 것은 아니고, 합리적인 결정 과정을 가져야 함.

프로젝트의 기간 뿐만 아니라 프로그래머의 테스트 구현 역량, 테스트 생태계 에 따라도 달라짐.

 

오버 엔지니어링 ?

요구사항 명세에 명확히 지정되지 않은 성능 달성이나, 구현 설계 품질 개선에 빠져드는 경향을 가짐(당연히 코드 구현하는 것을 좋아하니까) 그 자체로 나쁜 것은 아니지만, 프로그래머의 자원을 낭비하는 경우가 있고, 구현중 개발자가 오버엔지니어링에 대한 고민이 있는 경우, 오버엔지니어링에 빠지지 않게 안심하고 넘어갈 수 있도록 하는 맹우 중요한 피드백을 제공함 그것은 바로 "모든 테스트가 성공했습니다"

=> 다음 작업으로 넘어가도 됨.

핵심은 짧은 주기로 지속적으로 피드백을 받아 코드를 늘려 나가는 것이 목적이다.