[우아한테크코스] 우테코 4기 프리코스 회고2 - 1주차 미션

우아한테크코스

1주차 미션

1주차 미션의 목적은 개발 환경을 세팅하고 우아한테크코스에서 앞으로 적용해야 할 기본적인 컨벤션 등을 익히는 것이다.

일반적인 프로그래밍 과제와는 달리 기능 요구사항 뿐만이 아니라, 프로그래밍 요구사항과 과제 진행 요구사항이 추가적으로 있어 그것을 적응하고 적용하는데 힘을 썼다. 특히 자바 코드 컨벤션을 지키며 프로그래밍하는데, 나는 자바를 사용한 경험이 적을 뿐더러 이러한 컨벤션이 있는지 조차 무지했어서 미션 수행 전 컨벤션을 먼저 이해하려 노력했다. 컨벤션을 정독하고 이전 기수분들이 구현한 코드와 비교해 보며 조금씩 컨벤션을 이해할 수 있었다.

 

 

- 메소드는 한 가지 일만 하자.

프로그래밍 요구사항 중 인상 깊은 요구사항은 "메소드가 한 가지 일만 하도록 최대한 작게 만들어라." 이다. 이전까지 프로그래밍을 하면서 함수를 나누려고 노력은 했지만, 해봐야 아주 커다란 기능 단위였다. 하지만, "한 가지 일" 이라는 것이 내가 이전까지 적용했던 아주 커다란 기능 단위는 아닌 것은 분명했다. 최대한 아주 작은 기능 단위로 메소드를 분리하려고 노력했고 구현을 다 한 이후 코드를 보니 훨씬 간결하고 가독성 있는 코드가 되었다.

 

- 패키지 및 클래스 분리

메소드도 한 가지 일만 하게 분리를 했으니 그 역할에 알맞게 클래스를 만들어 줬고 또 그 클래스들에 알맞게 패키지를 만들어 줬다. 하지만, 아무런 기준도 없이 스스로 괜찮을 것 같은 네이밍을 고민해서 다음과 같은 구조가 만들어졌다.

프로그램 구조

당시에는 적절한 네이밍으로 잘 분리된 것 같아 뿌듯했고 만족스러웠는데 이후에 디자인 패턴을 알아보게 된 계기가 되었다.

 

- 상수

상수 선언

미션 수행 전에 이전 기수분들의 여러 코드를 살펴봤는데 전부 상수를 static final로 따로 정의하여 사용하는 것을 알 수 있었다. 처음에는 무작정 상수를 선언하면서 이것이 과연 의미 있는 일인가 의문이 있었다. 하지만, 각 상수가 의미하는 바를 생각하여 네이밍을 해본 결과 같은 상수라도 다른 의미가 있어 그냥 상수로 남아있을 경우 의미가 혼동되었을 것이라 생각이 든다. 찾아본 결과, 하드 코딩을 하게 되면 프로그램 규모가 커질 때 유지 보수하기 어려워진다. 또한, 피드백에서 역시 "매직 넘버를 사용하지 말고 의미를 나타낼 수 있는 상수(static final)로 치환하여 코드의 가독성을 높인다."라고 왔다. 따라서 의미 있는 일임을 깨닫고 이후로도 네이밍에 집중하게 되었다.

하지만, 아직까지 혼동인 부분이 있다. 예를 들어서 변수를 0으로 초기화하거나 for-loop의 시작인 0 같은 경우는 굳이 네이밍이 필요할까 의문이 든다. 앞으로 더 공부를 하고 경험이 쌓이다 보면 나만의 기준이 생겨서 그것에 맞춰 프로그래밍을 하지 않을까 싶다.

 

피드백

일주일 간의 1주차 미션 종료 후 메일로 2주차 미션 공개와 함께 1주차 미션에 대한 공통적인 피드백이 도착했다. 화요일에서 수요일로 넘어가기 직전인 11:59에 미션이 마감되는 것으로 보아 약 15시간 내에 참가자들의 모든 코드를 파악하고 공통적으로 부족한 부분을 피드백 해 준 것이다. 1:1 피드백을 받았다면 더욱 도움이 많이 되었겠지만, 제한된 시간안에 공통 피드백을 주신 것만으로도 너무 감사했고 도움이 되었다. 이 중 몇 가지 도움 받은 내용을 공유하면 다음과 같다.

 

- 주석

이전까지 프로그래밍을 할 때 주석은 어느 정도는 필요하다고 생각했었다. 이번 미션을 진행하면서 클래스에 대한 주석, 메소드에 대한 주석을 전부 달았다. 하지만, 피드백에서는 "의미 없는 주석을 달지 않는다."라고 왔다. 모든 변수와 함수에 주석을 달기 보다는 가능하다면 이름을 통해 의도를 드러내는 것이 좋다는 내용이다. 이외의 피드백 내용을 덧붙이자면, 다른 개발자와의 소통을 위해 가장 중요한 활동 중 하나가 좋은 이름 짓기이다. 이름을 짓는데 시간을 많이 투자해서 이름을 통해 해당하는 역할에 대한 의도를 드러내고자 노력하라.

즉, 무분별한 주석을 통한 설명 보다는 이름을 통해 역할과 의도를 파악할 수 있도록 하는 것이 중요한 것임을 깨달았다.

 

- README.md

미션 설명 중 미션 진행 방식에 대한 설명에 다음과 같은 내용이 있다. "특히 기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다." 해당 내용을 지키기 위해 미리 미션 내용을 파악하여 어떤 식으로 만들어 갈지 설계를 하여 README.md 파일에 작성하였다. 다행히 이번 미션 내용이 그렇게 어렵지 않아서 내용을 파악하는데는 시간이 오래 걸리진 않았지만, 설계를 하여 문서화하는 작업이 생각보다 오래 걸렸다. 이것은 처음부터 전부 생각하고 너무 완벽하게 정리하려는 부담 때문이었다. 피드백 역시 기능 목록을 업데이트하라는 피드백이 왔다. 기능 목록은 구현을 하면서 언제든지 변경될 수 있으므로 처음부터 완벽하게 정리하지 않고 기능을 구현하면서 문서를 계속 업데이트하라는 내용이다. 즉, 죽은 문서가 아닌 살아있는 문서를 만들기 위해 노력하라는 것이다.

해당하는 내용에 어려움을 겪어서 그런지 해당 피드백이 와닿았고 앞으로 살아있는 문서를 만들고자 노력할 것이다.

 

공통 피드백이지만, 전부 나 자신에게 해당되는 피드백이었다. 이후 피드백을 곱씹으며 과제를 리팩토링했고 2주차 과제는 피드백 덕분에 더욱 성장한 프로그램을 작성할 수 있었다.