[1주차 회고] 자동차경주 페어 프로그래밍

우아한테크코스 첫 주차가 정말 정신없이 지나갔네요 

최대한 있었던 일들과 배웠던 것들을 기억해두려고 매주 회고를 꼭 작성해두려고 합니다

 

우아한테크코스 1주차에서는 페어 프로그래밍과 연극을 통해서 아이스브레이킹과 온보딩을 하는 과정을 중심으로 진행되었는데요

회고를 매주 적으려고 한 이유기도 하지만, 정말 좋은 페어를 만나고, 코드 리뷰도 받고, 연극도 진행해보는 것들이 하나같이 다 기억에 남는 경험이었습니다

안 적으면 까먹을 것 같았거든요

자동차 경주 페어 프로그래밍

2~3일 동안 페어 프로그래밍을 통해서 진행했는데요

 

페어 프로그래밍이나 협업하면 당연하지만 스타일을 맞추고, 전체적인 과정을 조율하는 것에 신경을 써야 합니다

 

조율했던 내용들

1. 기능 목록은 어떻게 작성하는지

2. 어떤 클래스를 둘 것인지

3. 어떤 패키지에 무엇을 작성할 것인지

추가적 언제까지 어느 정도를 마무리하고, 언제쯤 제출하면 되겠다 같은 큰 일정들을 생각해보고 갔습니다

 

실제 코드를 작성하고, 리뷰를 받는 과정에서 얻게 된 부분들이 많았는데요

1. 네이밍을 잘하자

프로젝트를 할 때는 항상 발등에 불이 떨어져서 개발하다 보니 기능이 작동만 하게 해주세요... 라면서 빌고 있었는데요

프로젝트가 규모가 작다 보니 서로의 코드에 대해서 유지보수를 하는 과정이 없다 보니 네이밍에 대한 필요성을 많이 느끼지 못했던 것 같아요
여기서는 리뷰어분들이 짧은 시간 안에 리뷰해야 했습니다
따라서 네이밍이나, 기능 목록의 형태, 줄 바꿈 같은 부분에 대해서 최대한 명확하게 작성해야 한다는 필요성을 확실하게 배웠습니다

 

2. 객체에 메시지를 보낸다. 어디까지?

위에 사진에서 보이는 것처럼 3가지 메서드가 존재합니다. 

1번째는 바깥에서 로직 상 필수적으로 사용되어야 하는 getter

2번째는 int 값을 받아서 같은지 여부를 return 해주는 것

3번째는 1이랑 같은지를 확인하는 메서드까지 있습니다

 

1번째와 2번째까지는 있는 것이 좋을 것 같습니다

메서드가 하나만 늘어나기에 괜찮은 것이기도 하고, 

==으로 비교가 되지 않는 double이나 float에서 유효 범위를 변경해야 하는 경우에 한 곳에 로직이 모여있다면 좋을 것 같습니다

3까지 가게 된다면 범위에 따라서 메서드를 몇억개 만들 수도 있을 것 같은데요

프리코스 때 숫자 야구 게임을 만들었을 때, ball의 수가 4개까지만 있는 경우에도 메서드가 4개나 되기에 테스트하기 번거로웠던 경우가 있었습니다

1,2 까지는 넣고, 3에서는 아주 특이한 케이스만 다루는 방향으로 사용할 것으로 보이긴 하네요

예를 들면 isOut() 같은 메서드를 활용해서 strike 가 3인지만 검증한다던가?

이런 방식을 사용할 것으로 보이긴 합니다

 

3. view 를 테스트 하기 위한 방법으로 좋은 것은 뭘까?

 

라는 내용의 질문 슬랙에 남기기도 했는데요

위는 static이 있다가 제거되었는데, 코드 리팩토링을 위해서 한 것이 아닌 테스트만을 위한 코드이기에 안 좋을 수 있다는 답변을 받았는데 

되게 좋은 의견이었던 것 같습니다

 

 

4. Random 같은 객체를 어떻게 전달받아야 할까?

위는 메서드에서 주입받는 방식이 됩니다

아래는 생성자에서 받고, 인스턴스 변수에 받아서 저장하는 방식을 사용하게 되는데요

객체에 책임만을 보게 된다면 자동차들을 관리하는 부분에다가 일부 메서드에서 사용하는 객체를 인스턴스 변수의 형태로 담아두는 것은 잘못된 것 같았습니다

5. 에러 메시지는 구체적으로 작성하자

이렇게 되어있는 경우에 이름이 null 때문에 실패한 건지, length 가 넘어가서 실패한 건지를 알 방법이 없습니다

null 인지와 length 가 넘어간 것인지는 이 객체를 사용하는 입장에서는 무조건 자세하게 알수록 좋은 정보이기에 이런 방향으로 작성하는 것이 좋아 보였습니다

 

6. 알아봐야할 함수

max 함수

 

Stream api 내부에 있는 max 함수를 쓰면 for 문을 더 깔끔하게 대체할 수 있다는 점이 있습니다

assertAll 

 

assertThat 만 사용했을 때는 앞에 하나가 잘못되었을 경우 뒤는 실행되지 않는데, 이때 assertAll 메서드를 한다면 모두 다 실행시켜주고, 에러 메시지를 잡아주기에 좋은 테스트일 것 같습니다

이외에 중요하게 생각한 점

POJO와 Spring은 무조건 분리해서 진행해야 한다는 생각인데요

spring bean을 활용하기 위해서면 Random 같은 것도 Bean에 등록해두고, 생성자에다 주입받는 것처럼 당연하게 작성했을 것 같습니다

하지만 현재는 전혀 사용하고 있지 않기에, 최대한 순수하게 의존성에 대해서 생각을 집중해야 할 것 같습니다

 

페어

페어 프로그래밍을 몇번 해보긴 했어도, 항상 배움을 받는 주니어의 역할이었기에, 어떤 식으로 진행해야 하는지에 대한 고민을 정말 많이 하게 된 것 같네요

고민이 되게 많이 되었던 부분 같습니다

 

연극

우테코에서는 되게 특이한 활동이 있는데요 서로 처음 친해질 만한 계기를 만들기 위해서 연극이나, 보이는 라디오를 하는 활동인데요

이번 기수는 연극을 하게 되었습니다

연극은 페어와 저를 포함해서 총 6명이 같이 진행하는데, 전부 다 열심히 참여하려는 모습이 너무 좋았습니다

되게 재미있는 팀원분들이 많아서 했던 모든 연극 중에서 가장 재밌게 준비했고, 재밌는 결과가 나올 것 같습니다