[우아한테크코스] 2주차 회고

 

아 정말.. 2주차에 쓰기 위해 문서에 메모해놨던 내용이 지워졌다 ㅎㅎ 어쩔 수 없지.. 다시 생각해서 써야겠다.

 

 

2주차에는 1주차에서 페어 프로그래밍으로 진행했던 자동차 경주에 대해 혼자만의 리팩토링 과정을 거칩니다.

저는 미션을 진행할 당시 '팩토리 메서드' 와 '전략 패턴' 에 대해 집중해서 구현했었습니다.

 

또한 2주차에는 연극 발표를 진행했고, 저희 조가 1등을 했습니다..! 

그리고 방과후 수업이라는, 크루 간 자체적인 세미나 교육을 시행하면서 첫 주자로 참여했습니다.

DI와, 의존 역전 원칙에 대한 발표를 진행했습니다.

 

그리고 자동차 경주 미션이 명시적으로 종료되었고, 새로운 페어와 함께 새로운 로또 미션이 시작되었습니다.

로또는 TDD를 기반으로 구현해야 하는 요구사항이 추가되었습니다.

 

 

이번 주차에서 중점적으로 학습했던 내용은 다음과 같습니다.

 

---

 

 

TDD

테스트 주도 개발, 여태까지는 클래스 도메인을 먼저 구현한 뒤에 테스트 코드를 작성하여 검증했다면,

반대로 '이러한 객체가 이러한 과정을 통해 이 결과를 가지면 좋겠다' 라는 테스트 코드를 먼저 작성하고 (당연히 실행 성공하지 않음 = 레드)

그 이후에 클래스 코드를 구현합니다.

이 때, 커밋 단위를 어떻게 두어야 할지 고민했습니다.

 

1. test 코드를 구현한 뒤에 커밋, 기능을 구현한 뒤에 커밋

2. test 코드를 구현한 뒤, 기능을 구현하고 나서 한 번에 커밋

 

커밋은 실행 가능한 단위로 되어야 한다는 생각을 갖고 있어서 2번을 지향하고 있었지만

페어와의 의견 조율을 통해 1번으로 진행해보기로 했습니다.

 

그리고 리뷰어님에게 관련된 질문을 남겨봤을 때, 협업 과정을 위해서도 2번을 지향하는게 더 권장이라고 하셨고

앞으로도 해당 방법을 지향해서 커밋을 진행할 것 같습니다.

 

 

toString의 관념

객체 내의 정보를 포맷화하여 출력하는 경우가 있을 때, 도메인의 toString을 재정의하여 포맷을 맞춘 String을 리턴한 뒤에 OutputView에서 이를 활용하도록 구현했었습니다. 그 이후 toString의 활용 방안에 대한 피드백을 요청드렸고, 어떻게 구현하는지는 사실 상관이 없기에 뭐라고 정해놓은 강한 컨벤션 정도는 없지만, toString이 원래는 디버깅에서 객체의 정보를 출력하여 개발자가 확인하기 위한 용도로 생겼다는 점을 비추어 볼 때 앞으로는 해당 출력 포맷 등을 만들 때에는 코드가 더 지저분해 질 수 있더라도 OutputView에서 처리해주는 방향이 더 나을 것이라고 생각했습니다.

 

 

 

객체스러운 설계

이번에 클래스를 모듈화 할 때 상상을 하면서 구현했습니다. 내가 어떤 사람이고 어떤 금액을 지불하면 그걸 책임 지고 무언가를 만들어 줄 사람은 누구이며, 어떤 것을 리턴해 주길 원하는지 등을 현실에 빗대어 생각해서 클래스를 구분하여 생성하게끔 설계했습니다. 해당 방식을 적용한 덕분인지 리뷰어님께서 깔끔한 분리를 진행한 것으로 보아 도메인의 설계에 대한 충분한 고민을 가졌던 것 같다고 말씀해주셨습니다.