[우테코 프리코스] 1주차 회고

 

드디어 우테코 프리코스가 시작되었다. 

 

1주차 과제는 숫자야구게임 구현하기!

 

과제 설명은 아래 깃허브 링크에서 확인할 수 있다.

https://github.com/Gyu-won/java-baseball-6

GitHub - Gyu-won/java-baseball-6

 

과제는 요약하면 기능명세, 코드 구현, 리팩토링 이다.

 

과제를 진행하면서 디스코드에서 공유된 자료들의 도움도 많이 받았으며, 학교에서 2명의 친구와 함께 스터디를 만들어서 서로 코드 리뷰를 하는 과정에서도 다양한 관점을 배울 수 있었다. 

 

여러 관점들과 방식들을 배우면서 정답은 없다는 것도 알게되었다. 앞으로 이어질 과제들을 잘 풀기 위해서는 일관된 나만의 방식을 확립해 나가는 것이 중요하다고 생각하였다. 그래서 1주차 과제를 통해 했던 고민들과 고민의 결과들을 기록하기로 하였다. 디스코드에서 공유된 자료들, 각종 자료들을 참고하여 작성하였으며 이 방식도 정답이 아니라 나만의 방식이라고 생각하고 보면 좋겠다.

---

과제를 수행하면서 했던 고민들

1. 기능명세서 작성

"객체지향의 사실과 오해" 책에서 배운 객체지향적 설계방식으로 문제에 접근하면서 기능명세서를 작성하였다.

 

각 객체는 역할이 있고, 역할에 따른 책임을 수행하며, 객체들의 협력을 통해서 문제를 해결한다. 이 관점에서 객체를 어떻게 나눌 것이며 각각의 역할은 무엇인지 고민하였다. 객체는 역할이 정해지면 메소드를 통해서 역할에 대한 책임을 수행한다. 이러한 책임들이 기능과 연결되기 때문에 기능명세서 역시 객체가 수행해야하는 책임에 초점을 맞추어 작성하였다. 또한 기능명세서의 가시성을 높이기 위해 다른 자료들도 참고하여 수정하였다.

 

아직 기능명세서 작성이 익숙하지 않은 1주차는 코드 구현을 하면서 계속해서 설계방식이 수정되었다. 아래 블로그에 1주차 기간동안 좋은 기능 명세스를 만들기 위해서 공부한 내용을 기록하였다.

 

https://gyuwon-tech.tistory.com/3

기술명세서 작성법

 

2. 단위 테스트 수행

리더 포비님이 작성하신 책 'nextstep'의 1장을 공부하고 단위 테스트의 중요성에 대해서 알게되었다. 책에서 StringCalculator를 만들어 본 경험을 바탕으로 숫자야구 게임에서도 이 방식을 적용하려고 노력하였다.

 

하지만 StringCalculator와 달리 이번 과제는 사용자의 입출력을 받기 때문에 JUnit test로는 전체 test를 돌리는게 어려웠다. (가능은 하지만 사실 값을 입력하는 것은 test를 할 필요도 없다고 생각되었다) 

 

또한 객체별로 코딩을 하여서 각 test들이 연결되지 않았기 때문에 연결하는 과정에서 test code들도 계속 수정해야 하는 문제가 발생했다. 수정해야하는 양이 2배로 늘어나고, 코드을 하고 test를 맞추는 방식이 되어버려 unit test를 더 공부해야겠다고 생각했다. 

 

1주차에서는 리팩토링에 중점을 맞추어서 구현하고, 2주차 과제에서는 처음부터 test code를 짜면서 논리 순서대로 코드를 구현하기로 하였다. 또한 코드 작성의 시간을 줄이고 명확한 의도를 드러내기 위하여 test 코드 메소드의 이름은 한글로 작성하기로 하였다.

 

3. 리팩토링

과제를 진행하면서 가장 많이 고민했던 부분이 리팩토링이다. Discord의 함께 나누기 방에서 공유했던 자료들이 많은 도움이 되었다. 아래 블로그에 1주차 과제를 하면서 했던 리팩토링에 대한 생각을 적어놓았다.

 

https://gyuwon-tech.tistory.com/4

클린코드를 연습하는 이유

 

프리코스를 진행하면서 계속해서 클린코드에 대해 고민할 것이다. 클린코드를 무작정 받아들이는 것이 아니라 정확한 의미 전달과 가독성을 위한 도구로 클린코드를 사용할 것이다.

 

4. 명시적인 커밋 메시지 작성

좋은 커밋 메시지를 작성하는 것은 협업의 관점에서 매우 중요하다. 또한 세부 기능 단위 커밋을 통해 내가 지금 어떤 기능을 구현하고 있는지 더 명확하게 알 수 있다.

 

기존의 커밋은 아래와 같은 방식으로 작성하였다.

[type](scope): [title]

ex) feat(Player): Add ball validation check and flag validation check

 

위의 경우는 세부 기능단위로 커밋이 분리되지 않았다(and로 연결되어 있기 때문). 또 영어로 작성하여 그 의미도 명확하게 알 수 없다. (영어를 못해서 그런건 아니다)

 

또한, 객체 분리와 같은 커밋 내용은 한개의 객체 뿐만이 아니라 그 객체를 호출하는 다른 객체에도 영향을 미치기 때문에 변경범위 scope를 작성하는것이 애매하다는 생각이 들었다.

 

커밋 메시지 작성과 관련된 다양한 자료와 내 경험을 토대로 필요한 내용을 정리하여 아래 블로그에 기록하였다.

 

https://gyuwon-tech.tistory.com/5

좋은 커밋 메시지 작성법

 

5. 성능적인 고민

Computer가 생성하는 숫자야구의 정답과 Player가 입력한 추측값을 저장하는 형태를 String으로 할지 List<Character>로 할지 char[]로 할지 고민하였다. 이때 type간 변형을 최소화하기 위하여 해당 값을 접근할때 어떤 형식이 유리한지 고민하였다.

• Player에서는 사용자에 의해 String으로 입력되기 때문에 String을 그대로 넘겨주는 것이 편하다.
• Computer에서는 random 숫자를 생성하고 조건에 맞으면 하나씩 더해가는 방식이기 때문에 add 함수가 있는 List가 편하다.
• Strike를 계산하는 부분은 index로 접근하여 한자리씩 비교하기 때문에 3가지 형식 모두 괜찮다.
• Ball을 계산하는 부분은 contain 메소드를 쓰면 가장 효과적일 것 같아서 List<>를 쓰는 것이 편하다.

각자 메소드에서 편한 type으로 변환하여서 사용해도 되지만 이렇게 하면 변환이 많아 성능이 저하될 것이라고 생각하였다. 또한 두 값을 비교하는데 타입이 다르면 코드를 이해하는데 가독성이 떨어진다고 생각하여 List<Integer>로 통일하여 코드를 작성하였다.

 

---

마무리

과제를 진행하면서 기존에 코드를 짜기 급해서 하지 못했던 다양한 고민들을 할 수 있었다. 그리고 고민을 해결하기 위해서 하는 공부는 재밌었다. 특히나 리팩토링 작업을 한 후 아름다워진 코드를 보면서 희열을 느낄 수 있었다. (사실 아름다운 코드가 아니였다)

지금도 코드를 잘 짜진 않지만, 잘 짜기 위해 공부하는 것에 열정을 가지게 되었다. 말로만 리팩토링이 중요하다고 듣는 것보다, 직접 리팩토링 후 처음 짠 코드와 비교하니 리팩토링의 중요성을 몸소 느낄 수 있었다.

 

앞으로

2주차 과제에서는 1주차에서 공부한 기능명세서 작성법, 리팩토링, 커밋 메시지 작성법을 적용하여 과제를 수행할 것이다. 또 1주차에서 하지 못했던 아래 내용들을 적용하면서 나만의 코드 작성법을 발전 시켜 나갈 예정이다.

 

• JUnit 단위 테스트 코드를 추가하여 구현-테스트-리펙토링-테스트의 과정으로 기능을 구현한다.
• for 문 대신 JAVA 8 부터 도입된 stream을 적용한다.
• 좋은 코드에 대하여 고민한다. 
  •  getter의 대안
  • 변수 및 메소드 명 짓는 법
  • 공통된 예외, 상수 따로 분리하는것
  • 계속 참조하지 않는 객체를 굳이 객체로 둬야 하는가
  • 클린코드 책을 통해 클린코드에 대해 고민

 

추가로 느낀것

블로그를 쓰면서 개발자도 글을 잘 쓰는게 중요하다는 것을 느끼게 되었다. 내가 배운 것을 간결하게 정리하는 것도 개발자의 중요한 역량 중 하나이다. 개발자가 글을 잘 쓰는 법과 관련된 세미나가 우아한형제들에서 열려서 신청하였는데 글 쓰는 법을 공부해서 2주차에는 더 좋은 블로그를 작성해볼 것이다.