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

프리코스 2주차가 종료되었습니다.

2주차 미션은 자동차 경주 였습니다.

2주차에 배운 것은 다음과 같습니다.

1. 어떤 클래스로 함수들을 나눠야 할까 -> (디자인 패턴을 쓰지 않는다면) 현실상황에 대입해 생각해보자
2. 고민해도 답이 안나올 땐 나만의 기준을 세워보자.
3. 접근제어자를 이용해 최대한 보수적으로 작성하기
4. 잘 세운 계획은 수정도 쉽다.
5. 리팩토링 정리를 야무지게 하자.
6. 정해진 시간에 코딩하는 연습을 하는 중.

 

 

1. (디자인 패턴을 쓰지 않는다면) 현실 상황에 대입해 생각해보자

가장 고민했던 부분은 각 기능에 해당하는 메서드들을 어떤 클래스로 나눠야 보기도 좋고 이해하기도 편할까 였습니다. 코드가 길어질수록 클래스를 분리할 필요성을 느꼈고, 이해하기 편한 코드를 위해 자동차 경주 게임을 현실세계에 대입해 생각해보았습니다.

자동차 레이싱을 TV로 보면 대부분 경기 장면만 보여주는 경우가 많습니다. 시청자 입장에서는 선수를 등록하는 과정, 레이싱을 하기 위해 자동차를 줄 세우는 과정, 시상식을 준비하는 과정 등은 볼 수 없습니다. 꼭 봐야하는 과정이 아니기 때문에 "알아서 선수 등록했겠지", "차가 어찌저찌 출발선에 섰겠지" 이런 식으로 추상적으로 생각한다는 것이죠. 그렇다면 코드에도 적용할 수 있지 않을까? 라고 생각해보았습니다.

기존 코드는 CarRacing , Car 만을 클래스로 만들고, Utils를 이용해 자잘한 메서드를 구현했었습니다.

CarRacing.java 파일이 길어지면서 다음과 같이 "준비"-"게임시작"-"종료" 의 단계로 클래스를 분리하였습니다.

다양한 방식으로 구분할 수 있겠지만, 저의 경우 현실 세계에 대입해 해결할 수 있는 객체 지향 문제라고 느껴서 흥미로웠습니다. 여태까지 알고리즘 공부 등으로 이용했던 자바는 객체 지향과는 거리가 있었는데요, 이번 자동차 경주 문제를 풀면서 객체 지향과 현실이 가까워서 느낄 수 있는 java의 매력을 알 수 있게 되었습니다. java와 어사(어색한 사이)에서 조금은 더 가까워지지 않았나 싶습니다.

다음 3주차 미션부터는 MVC 패턴도 적용해보고 싶습니다.

 

 

2. 고민해도 답이 안나올 땐 나만의 기준을 세워보자.

"자동차 이름 5글자 이하, 구분자는 쉼표(,)"라는 조건을 제외하고는 입력에 대한 제약사항이 없어서 모호했습니다. 답이 없으니 틀 안에서 나만의 기준을 세워야 했고, 이것을 고민하는 연습이 막연함에서 구체적인 솔루션으로 갈 수 있는 방법이었던 것 같습니다.

• 특수문자가 허용되면 구분자인 쉼표를 작성하려다가 다른 특수문자를 쓴 경우를 대비할 수 없으므로 쉼표를 제외한 특수문자는 입력 시 예외처리가 되도록 구현했습니다.
• 구분자(,)를 쓰고 띄어쓰기를 하는 경우가 많아 이 경우만 공백이 인정되도록 제한하였습니다.

 

 

3. 접근제어자를 이용해 최대한 보수적으로 작성하기

상수 final을 꼭 이번 미션에 적용해보아야겠다고 다짐하면서 자연스레 final처럼 이름 앞에 오는 접근 제어자에도 관심을 갖게 되었습니다. 객체 지향 같이 외부 클래스를 import하거나, 인스턴스 접근, 상속하여 접근하는 등 다양한 방식으로 다른 파일과 상호작용할 수 있는 특성에 따라, 접근 제어자는 java에서 중요하게 사용될 수 밖에 없음을 알게 되었습니다. 상수와 함께 접근 제어자도 적극 활용하는 노력을 할 수 있었던 시간이었습니다.

public하게 사용할지, private하게 사용할지 아직 정해지지 않은 함수를 만들 때는 최대한 scope를 작게 설계하여 필요시 접근제어자를 하나씩 높은 것으로 바꾸면서 작성했는데, 확실히 불필요한 public 접근 허용을 막을 수 있었습니다.

 

 

4. 잘 세운 계획은 수정도 쉽다.

열심히 계획을 세워 코딩을 진행한다고 노력했는데도 결국 구현할 때 다 갈아엎게 되는 경험을 많이 해보았습니다. 나름 세웠다는 그 계획이 제대로된 것이 아니었던 것이죠... 물거품까진 아니더라도 원래 세웠던 것과 많이 달라지면 계획을 세운 의미를 잃어버린다고 느끼구요. 그런 상황이 반복되다보니 "계획..그거 간단해보이는 문제에서도 꼭 세워야하나..?" 라는 생각을 하게 됩니다.

이번에 1주차부터 기능목록부터 세우고 시작하는 것을 연습하면서 진짜 계획의 참 맛을 알게 되었습니다. 기능목록을 세우고, 함수를 네이밍하고 구현을 진행하길 목표로 세웠었는데요, 아주 성공적이었습니다. 완벽하진 않았지만 기능에 집중해서 세워둔 계획은 전체적으로 잘 흘러갔고, 수정도 세워뒀던 계획을 보면서 설계하니 오히려 더 편하게 할 수 있었습니다.

여태까지는 기능과 구현에 집중한 설계보다는 겉핥기식의 설계였다는 것을 깨달을 수 있는 시간들이었습니다. 제대로 차근차근 세운 계획은 구현의 속도와 리팩토링의 질을 높여줄 수 있고, 문제 해결을 유연하게 만들어준다는 것을 배웠습니다.

 

 

5. 리팩토링 정리를 야무지게 하자.

저는 회고도 쓰고, 리팩토링 정리도 쓰는 방식으로 프리코스를 진행하고 있습니다.

• 회고 : 감정적인 것, 전체적인 깨달음, 기술 외적인 부분 위주
• 리팩토링 정리 : 코드에 직접적으로 관련된 것, 기술적인 부분

을 정리하도록 나눠 놓았는데요, 리팩토링 정리에선 덜 정리된 기술적인 요소들과 문제 해결 및 구현의 과정을 담고, 회고에서는 리팩토링 하면서 느낀 점들까지 적는 용도로 이용하고 있습니다.

회고에 리팩토링 정리에 들어갈 내용까지 한번에 썼던 적이 있었는데, 그 시간동안 무엇을 느꼈는지는 잘 담기지 않더라고요. 분리하게 되면서 오히려 회고 적기가 편해졌습니다. 리팩토링 정리를 적으면서 구현하는 동안 미뤄두었던 자잘한 예외나 문제들을 하나씩 해결하는 과정을 실시간으로 적는 묘미도 있었습니다.

 

 

6. 정해진 시간에 코딩하는 연습을 하는 중.

무라카미 하루키처럼 정해진 시간에 글을 작성하듯이 정해진 시간에 코딩하는 습관을 들이려고 노력하고 있습니다. 코딩이 즐거울 때도 있지만 일처럼 반복하다보면 분명 즐겁지 않은 때도 올 것이기 때문에 습관처럼 익숙해지기를 연습하기 위해 시작했습니다.

사실 저는 개발에 미칠 정도로 흥미가 있는 사람은 아닙니다. 문제 해결은 너무 재밌지만 문제가 잘 안풀릴 때는 힘이 듭니다. 가지고 있는 지식이 늘 짧다고 느끼고 끊임없이 모르는 것을 마주하고 배워야 하기 때문에 재미만으로 이끌고 간다면 언젠가 흥미가 시들해졌을 때 견디기 어려울 것입니다. 좋아하던 것도 일로 하면 식는다는 말이 있듯이, 덕업일치는 참 재능인 것 같습니다. 코태기라는 말도 있으니 코딩을 좋아한다고 해도 마음이 잠시 예전같지 않은 상황도 올 수 있겠죠. 예전의 감정과 흥미 같지 않더라도 그 과정을 견디어 보는 것은 좋은 경험이 될 수 있습니다. 코태기나 코딩 슬럼프같은 시기를 잘 세워둔 습관으로 견딜 수 있다고 생각합니다. 그래서 정해진 시간에 코딩하는 것을 몸에 익히려 노력하고 있습니다. 아직까진 잘 해내고 있어서 뿌듯합니다.

 

3주차도, 4주차도 열심히 노력해서 오래 가지고 갈 수 있는 습관이 될 수 있도록 만들고 싶습니다.

 

앞으로의 미션들이 얼마나 저를 성장하게 만들지 기대가 됩니다. 우리 모두 파이팅!~!!