[일일 회고] 22.02.16~17 - DCI 패턴의 테스트 코드 적용하기!, 개발에 정답은 없다. 그래서 ~?

14일에 이어 어제 오늘도 사다리 게임 Step 3, Step 4를 구현했다. 프로젝트를 하며 피드백, 기술 적용, 생각을 정리한다.

 

✅ 역할과 책임을 분명히 하기

MVC 패턴으로 프로젝트 구조를 잡았다. 문제는 InputView에서 메시지 출력을 위해 OutputView의 메서드를 InputView에서 사용했다. 두 사이의 결합도가 높아졌다. InputView에서 OutputView를 사용해도 문제없지만, 사용자 입력을 받는 것은 InputView의 책임이니 InputView에서만 모든 일이 끝나도 문제없어 보인다. 정답은 없겠지만 설계 시 역할과 책임을 분명히 해야겠다는 경험을 쌓았다.

 

✅ 처음부터 완벽한 설계란 불가능하다. 미래 지향적으로 코딩하지 말자(YAGNI)

모든 상황에 맞진 않겠지만 현재 주어진 요구사항에 맞춰서 구현하자. 필요한 작업만 하자. YAGNI(You Ain't Goona Need It)의 원칙과 동일하다. 미래가 안올 수 있다. 미래가 생각과 다를 수 있다. 미래를 고민하다 현재를 구현하지 못한다. 당장 할 수 있는 것부터 작게 구현하고 리팩터링 하자. 설계를 진화시키자. 필요할 때 클래스, 메서드를 분할하고 작업하자. 그래야 일찍 퇴근도 할 수 있으니까

 

✅ DCI 패턴의 테스트 코드

Step3에서 TDD으로 Line, StringUtils를 만들었다. 호눅스의 말을 통해 BDD를 알게 되었고 Step 4에서 처음으로 BDD와 유사한 방식을 적용해보았다. 코드의 행동을 설명하는 테스트 코드는 처음엔 낯설었지만 결과를 봤을 때 해당 객체의 행동들이 한눈에 들어왔다. 이종립님의 Junit5로 계층 구조의 테스트 코드 작성하기 의 레퍼런스로 구현하니 어렵지 않았다. 행위 중심으로 테스트를 하니 전에는 보이지 않았던 누락된 예외나 추가 테스트 항목이 보였다.(TDD를 잘 못했을 수도 있겠지만) BDD 연습은 좋은 경험이었다. 앞으로도 조금씩 실천해봐야겠다. (작성했던 BDD 코드 LineTest, StringUtilsTest)

 

LineTest

StringUtilsTest

 

✅  private 메서드를 테스트해야 할까?

테스트 코드를 작성하며 종종 private 메서드를 테스트하고 싶을 때가 있다. 해야 할지 말아야 할지 고민이 되었다. 보통 public 메서드가 private를 커버하고 있기 때문에 안 해도 된다는 의견이었지만 페이스북 그룹 javawocky 박성철 님의 글을 통해 생각을 정리할 수 있었다.

private 메서드의 테스트 여부는 정답이 없고 현재 프로그래밍하는 시점의 context을 고려하자였다. 자세한 요약 내용은 private 메서드도 테스트를 해야 할까? (private 메서드 테스트하고 싶을 때...) ✅이다.

 

✅  🤝 프로그래밍, 개발에 정답이 있을까?

프로그래밍은 컴퓨터로 하는 것이니 이분법적인 사고로 정답이 있다고 생각했다. 하지만 요즘 개발을 배우면 배울수록 개발에는 하나의 정답이 없다는 것을 알게 되었다. 다양한 풀이가 있고 그중에 현재 주어진 문맥(context)에 맞는 최적의 솔루션을 찾아야 한다. 그렇다! context가 중요하다. 현대의 개발은 대부분 혼자가 아닌 팀으로 한다. 따라서 context를 적확하고 빠르게 이해하기 위해선 뛰어난 커뮤니케이션 능력이 필요하다. 아, 이래서 개발자가 개발 능력과 함께 커뮤니케이션 능력이 좋아야 하는구나를 느낀다.

---

👍 Keep

- 새로운 것을 배우고 적용했다. 문서화했다.

- 과정에서 작은 성공의 기쁨을 느꼈다.

- 동료와 함께 의견을 나누고 토의한다.

🔥Problem

- 코딩의 컨텍스트 스위칭을 하자. 하나만 작업하니 일률이 안사는 것 같다.

🚒 Try

- 배우고 나누기를 멈추지 말자.

- 작은 성공의 기쁨을 누리자

- 뽀모도로 시계를 활용해 일정을 세분화하자

- 운동하자!