[많은 시간을 투자한 부분]
피어 리뷰
이번 프리코스를 진행하면서 현업에서 프로젝트를 진행한다는 마인드로 프리코스에 임했습니다. 그 중 실천하고자 했던 것이 “주 1회 피어 리뷰 실천하기” 이었습니다. 매 주 저의 PR링크를 올렸으나 3주 차 과제를 올렸을 때 처음으로 리뷰를 받았습니다. 리뷰의 내용과 공통 피드백을 비교하면서 공통 피드백의 내용도 실제로 어떻게 적용할 수 있을지 이해가 되기 시작했습니다. 리뷰를 바탕으로 리팩터링을 하는 과정에서 getter를 어떻게 줄일 것 인지, 객체의 책임 분배를 어떻게 할 것인지, 테스트 코드 리팩터링 등 많은 깨달음을 얻었습니다.
2. 컨트롤러 분리
처음 설계에서는 메인 컨트롤러 1개가 모든 control flow를 담당하고 있었습니다. 구현을 하는 과정에서 요구사항인 메서드 10 라인을 넘기지 않기가 매우 어려웠습니다. 컨트롤러 또한 분리가 필요하다고 생각해서 초기 설정을 담당하는 SettingController와 게임 플레이를 담당하는 PlayingController로 분리하고 이 두 가지를 제어하는 BridgeController 로 설계를 변경하니 컨트롤러의 책임이 더 명확해졌습니다.
3. 리팩터링
이번 과제는 완벽한 설계를 하려고 너무 많은 시간을 쏟지 않으며 구현을 하고, 리팩터링을 하는 방식으로 진행했습니다. 구현한 기능 중에서 “이동한 칸을 선택해서 정답이고 다리의 끝에 도착하면~” 또는 “이동한 칸이 오답이고 재시도 입력을 받으면~” 와 같은 기능을 의식의 흐름대로 중첩 if문과 반복문으로 작성했습니다. 완성된 코드를 보고 if문 줄이기, Enum 사용, 메서드 분리 등 하나씩 개선하면서 훨씬 가독성이 좋은 코드로 리팩터링에 성공했습니다.
[배운점]
1. 객체답게 사용하기
이전에는 필요한 값들에 대해 인스턴스 변수를 선언하고 이에 대해 get해서 사용하는 방식으로 구현을 했습니다. 피어 리뷰와 공통 피드백을 수용하여 값을 get해서 외부에서 계산하지 않고, 필요할 때 객체 내부에서 계산해서 결과만 돌려주는 형태로 구현했습니다. 이러한 과정에서 인스턴스 변수도 줄고, getter도 없어져서 더 깨끗한 코드를 작성할 수 있었습니다.
2. 명확한 예외 처리
예외처리를 할 때 단순히 Exception e; e.printStackTrace; 로 구현을 하곤 했습니다. 이렇게 구현하니 다른 사람은 나의 코드를 보고 어떤 예외가 발생할지 예측이 어려웠습니다. 이번 과제를 진행하면서 잘못된 입력에 대하여 예외를 명확하게 지정함으로써 처리한 예외의 범위가 확실해지고 가독성이 높아지는 것을 느낄 수 있었습니다.
[느낀점]
기능 목록 분리, 클래스 분리, 테스트, 리팩터링 등 처음에는 매우 어렵고 고민도 많이 했지만 조금씩 익숙해 지는 것을 느꼈습니다. “첫 술에 배부를 수 없다.” 라는 말처럼 꾸준히 적용하고, 피드백을 수용하며 학습을 하다 보면 저도 좋은 개발자가 될 수 있을 것 이라고 생각했습니다.
이번 프리코스를 진행하며 1주 마다 제출했던 과제를 보면서 1주일 마다 크게 성장한 것을 확인할 수 있었습니다. 이 과정을 모두 마치고 많은 것을 배우고 경험하며 성장했음에 매우 뿌듯합니다.