[LEVEL 1] 출석 미션 회고 - (1)

☕ 출석 미션(Step1)

두 번째 객체지향 프로그래밍 미션은 출석 미션이었다. Step1은 페어와 같이 프로그래밍하는 것이다!

 

출석 미션은 우아한 테크코스 7기 최종 코딩테스트에 나온 미션이기도 하다. 그때 5시간동안 구현했었는데, 4가지 기능 중 3가지만 구현을 했던 것으로 기억한다. 그마저도 객체지향 코드를 신경쓸 틈 없이 구현의 완성에만 급했었다. 시간이 부족하기도 했지만, 구현하기도 어려운 미션이었던 걸로 기억하였다.

 

이 어려운 미션을 익숙하지도 않은 TDD로 구현해야 한다니 참 막막했다. 나는 평소에 TDD에 대한 살짝의 거부감이 있었다. 뭔가 이상적인 방법인 것 같았지만 실현 가능성이 너무 적은 것 같기 때문이다. 아직 실무를 경험하지 못했지만, 그냥 그럴 것 같다고 생각했다. 온전히 나의 생각이다. 하지만 TDD가 우테코 커리큘럼에 포함되어있기도 하고 TDD를 아직 제대로 공부해본 적은 없어서 이번 기회에 열심히 공부해보려고 한다. 깊게 공부하지 않았는데 TDD를 부정적으로 말하는 것도 웃기기 때문이다.

 

🤲 페어 프로그래밍

웨이드와 머피

어려운 미션을 페어와 함께 같이 코드를 작성해 나가야했기 때문에 걱정도 많았다. 서로의 개발 스타일과 생각을 맞춰가며 구현해야하기 때문이다.

하지만 든든한 머피를 만나게 되어 조금은 다행이었다. 머피와의 페어 프로그래밍은 많은 것을 알게된 3일이었다.

 

레이어드 아키텍처? 트랜잭션 스크립트?

첫 번째로 나는 자바 프로그래밍을 전부 Layered Architecture로만 구현했었는데 “왜 나는 Layered Architecture로만 구현하고 있었을까?”라는 생각이 들게되었다

이전에 스프링을 많이 사용하다 보니 레이어드 아키텍처가 익숙하기도 하였고, 미션 요구사항에 나와있지도 않는 재사용성을 자꾸 고려하고자 했던 것 같다.

 

위의 생각을 정리하고 고민한 결과, 나는 레이어드 아키텍처를 원하는 것이 아니었다. 비즈니스 로직을 무조건 서비스 계층에서 구현을 해야한다고 생각한 것이다. 그것이 옳다고 생각했고, 그것밖에 할 줄 몰랐다. 이것은 보통 트랜잭션 스크립트라고 불리었다.

 

하지만 정말 위 방법밖에 없었을까?를 고민하며 찾아본 결과 리치 도메인 모델과 순수 도메인 모델 두 가지가 있었다.

 

리치 도메인 모델은 모든 비즈니스 로직을 도메인 내부에서 구현하는 것이었다. 자신의 도메인만으로 해결할 수 없고 여러 도메인의 조합을 통해 구현할 수 있는 비즈니스 로직도 도메인 내부에서 구현하는 것이다.

순수 도메인 모델은 자신의 도메인으로만 해결할 수 있는 비즈니스 로직을 도메인 내부에 구현하고, 여러 도메인의 조합으로 해결해야 하는 비즈니스 로직은 협력 객체를 생성하여 그 내부에 구현하는 것이다.

 

위와 같은 방법들이 있었다니 정말 신기했다. 왜 나는 틀에박힌 사고만 하고 있었을까 반성하는 계기가 되었다.

 

이번 페어 프로그래밍에서는 리치 도메인 모델을 사용했던 것 같다. 모든 도메인 로직을 도메인 내부에 구현하는 방법이다.

도메인끼리 결합은 평소에 매우 안좋다고 생각하여 절대 시도를 안할 것 같은 방법을 페어프로그래밍때 해봤는데, 정말 좋은 경험이었다. 왜냐하면 왜 이런 방법을 사용하는지 이해하기 되었기 때문이다.

 

위 3가지 방법에 대해 더 공부해봐야 할 것 같다.

 

머피가 준 피드백

머피의 피드백 1

1번은 칭찬이니 감사히 생각하고 넘어가겠다! 감사합니다!

 

2번은 피드백이다. 머피가 솔직하게 나를 위해 피드백을 해준 것 같아 감사하다.

 

2번 피드백 중 첫 번째는 이전 히로가 피드백했던 부분과 같다. 내가 원하는 구현 방향에 대한 근거가 없다는 것이다. 내가 개선 방향을 말한다면 상대방에게 그것이 왜 좋은지 설득해야한다. 하지만 설득할 근거가 부족한 했던 것 같다. 히로와 머피가 똑같은 말을 하는 것을 보니 정말 바뀌어야 할 부분같다..ㅠ 노력해야겠다

 

두 번째는 앞서 설명한 트랜잭션 스크립트만 원한 것에 대한 피드백같다. 다양한 경험을 통해 다양한 시각으로 개발하는 프로그래머가 되어야겠다. 이번주 코치인 네오의 수업에서도 다양한 언어를 공부해보는 것을 추천하기도 하였다. 자바밖에 안해본 나에게 꼭 필요한 것 같다. 다른 언어… 언제해보지!?

 

세 번째도 두 번째와 비슷한 이야기같다. 기존 사용한 방식이 익숙하다고 해도 요구사항에 적합한 다른 더 좋은 방식이 있다면 받아들여도 좋을 것 같다. 무조건적 수용은 좋지 않지만 그렇다고 닫혀있는 마음도 좋지 않은 것 같다.

 

머피의 피드백 2

3번은 칭찬이니 감사하다 생각하고 넘어가야겠다. 감사합니다!

 

4번은 협업을 더 원할하게 하기 위한 피드백이다.

 

첫 번째와 두 번째는 반성해야할 점이다. 무언가를 주장할 때 나의 생각이 정리되지도 않았는데 주장하며 상대방에게 말하려고 한다. 그럼 상대방은 어떻게 이해를 하겠는가? 내 생각부터 정리하고 명확하게 말해야겠다.

나는 불평이나 불만을 표현을 잘하지 않는 스타일이라고 생각했다. 상대방의 기분이 상할까봐 걱정하는 것도 있다. 근데 혼잣말로 했나보다… 들렸나보다.. 그렇다면 이렇게 생산성 없는 혼잣말보다 단호히 나의 생각을 말하는 것도 좋은 방법이라고 생각한다. 다음부터는 단호하게 나의 생각을 말해봐야겠다.

 

세 번째는 협업보다는 나의 개발스타일의 문제점이라고 볼 수 있다. 하나의 기능에 대해 리팩토링 혹은 구현을 하다보면 자꾸 다른 곳에 시선이 가서 모든 일을 한꺼번에 해결하려고 한다. 하나의 일을 끝내고, 다음 일을 하는 노력을 해야할 것 같다.

 

TDD

페어 프로그래밍에서 TDD를 하려고 노력했지만 원활하게 된 것 같지는 않다.

그렇기에 어떤 점이 좋았는지도 파악하지 못했고, 오히려 단점만 보였다..

Step2에서 다시 출석미션을 혼자 구현하는데, 그때 제대로 한번 해봐야겠다

 

🥲 혼잣말

힘들고도 재밌었던 출석미션 페어 프로그래밍이었다.

페어 프로그래밍은 항상 힘들지만 얻는 것이 많다.

나의 장단점들을 알게될 수 있어 좋은 것 같다.

다음 Step2에서 혼자 출석미션 구현한 느낀점을 작성해보도록 하겠다!!!!