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

3주차가 종료되었습니다.

이번 미션은 로또였습니다. 이번 주차 목표는 "MVC 패턴 도입해보기" 였기 때문에, 문제 자체는 어렵지 않았지만 처음으로 설계부터 MVC를 고려해서 작성하려는 것이 쉽지 않았습니다. 3주차 회고의 꼭지는 총 5개 입니다.

  1. 2주차 피드백을 통해 배운 것
  2. 하드 코딩 고치기 (Enum과 static final의 쓰임)
  3. static에 대하여
  4. 테스트 코드의 최고 강점
  5. 정해진 루틴의 소중함

BTS 봉준호 손흥민 3주차 회고 let's go

1. 공통 피드백을 통해 배운 것

공통 피드백은 매주 굉.장한 도움이 되고 있습니다. 생각하지 못했던 것과 생각했던 것 모두 다 잡아주는 문서였어요. 이 문서를 통해 제가ㅏ 몰랐던 클래스 작성 컨벤션과 상수 사용, README.md 작성에 대한 설명 등에 대해서 알 수 있었습니다.

특히 인상적이었던 것을 적자면,

- README.md에 구현에 대한 상세한 사항은 적지 않는다. 예외 상황은 함께 정리한다.
- 기능 목록은 처음부터 완벽하지 않아도 된다. 변경이 있을 때마다 잘 정리해서 업데이트 하면 된다.
- 값을 하드코딩하지 않고 상수로 정의하여 사용하자
- 변수 이름에 자료형 사용하지 않는다.
- 메서드는 15라인이 넘지 않도록 노력한다.

가 있습니다.

README.md를 어느 정도까지 상세하게 적어야 하는지 고민하다가 2주차에서 기능에 따른 메서드 명을 표로 작성하였습니다. (사실 매번 변경이 있을 때마다 수정해서 반영하기 귀찮으니) 구현하면서 이름을 바꾸는 게 좋을 것 같다는 생각이 들어도 소극적으로 해결했었습니다..허허... 이름이나 구성을 크게 바꾸지 않는 선에서 수정을 한다거나...(주객이 전도된 상황이라고 볼 수 있지요^^...)

 

근데 이번 피드백에서 딱 "구현에 대한 내용은 변경되기 쉬우니 README.md에 넣지 않는다"라고 명시돼서 너무 좋았습니다~~~ 피드백에 적혀 있던 대로 기능목록이 죽은 문서가 되지 않도록 계속 최신 것을 유지할 수 있도록 노력했습니다.

 

또한 메서드를 15라인이 넘지 않도록 작성하는 것도 아주 즐거운 챌린지였습니다. 의식하면서 작성하다보니 생각보다 15라인이 길다는 것을 알 수 있었어요...!!!왠만하면 1기능에 15라인 넘기 쉽지 않더라구요. 넘는 경우는 거의 하나라도 역할을 더 하고 있는 경우가 많았습니다. 열심히 최소의 기능만을 갖도록 나누다보니 15라인 넘지 않는 선에서 모든 메서드를 작성할 수 있었습니다.

 

2. 하드 코딩 고치기

1주차, 2주차 모두 하드 코딩을 통해 입출력을 했었는데, 피드백을 반영하여 이번엔 상수를 이용해보았습니다. Enum을 사용하라는 요구 사항도 있어서 Enum에 대해서도 알아볼 수 있었는데, 이게 진짜 재밌는 개념이더라구요.

2-1. Enum에 대하여

처음에 파악한 Enum은 "상수 모음"이었는데요,

필요한 상수가 있다면, 그것을 Enum에 넣어 이용하는 것입니다. 그래서 처음엔 입출력에 관련된 문자열 상수를 Enum으로 저장했었습니다. 어쨌든 상수는 상수니까. 그런데 Enum을 다른 곳에도 적용해보면서 Enum의 최고 강점 포인트를 알게 되었습니다. 그것은 상수에 있기 보다는 값의 연관성에 있었습니다. 

Enum은 연관된 값을 이어주기 위해 사용하는거네...!!!!!!! 

연관이 없거나, 값이 하나뿐인 상수를 저장해 사용하고 싶다면 static final을 사용하면 됩니다. 연관성이 없는 값이었던 입출력 관련 문자열 상수는 어디서도 부를 수 있는 상수인 static final로 수정하여 손쉽게 이용할 수 있었습니다.(값이 하나뿐이라 훨씬 경제적)

그러나 여러 개의 값이 일정한 시퀀스를 가지거나, 각자의 역할은 다르지만 연관되어 있는 경우라면 Enum이 빛을 발하게 됩니다. 저의 경우, Enum을

감격의 이넘

당첨 관련 정보를 저장하는 곳에 사용하였는데, 심각하게 효과적이었습니다............

 

enum안에 getter를 만들어 값을 가져올 수 있는 것 뿐만 아니라, 구현만 하면 값을 통해 객체의 이름(FIFTH, FOURTH 등)을 가져오는 함수를 구현해 유용하게 이용할 수 있습니다. 나는 matchNumber를 통해 객체의 이름을 key로 갖는 map에 당첨 내역을 저장할 때 이 방식을 이용했었습니다. 처음에 이름만으로 값을 가져올 수 있는 줄 알고 아 별론데...라고 생각했었는데 .toString으로 이름을 가져올 수 있는 것을 알고서는 값으로 이름을 가져오는 함수도 구현할 수 있다는 것을 알게 되었습니다..(ㅠㅜ..) 이번 미션의 최고의 발견 2가지 중 하나가 이것이었답니당.

 

3. static에 대하여

static에 익숙해진 줄 알았지만 이쯤되니 알다가도 모를 static.. 너는 누구야...? 그래서 static에 대해 알아보는 시간을 가져보았습니다.

 

static은 메서드에서도 사용할 수 있고, 변수를 선언할 때도 사용할 수 있어요. 이 녀석의 이름이 static인 이유는 정적인 시간(클래스가 메모리에 할당될 때)에 메모리에 할당되기 때문입니다. 함수를 스코프로 갖는 변수는 함수가 실행될 때 메모리에 할당된다면, static은 아예 클래스가 만들어질 때 값이 할당됩니다. 그리고 해당 클래스의 인스턴스가 만들어지면 모든 인스턴스가 하나의 값을 공유하는 개념이 됩니다. 마치 전역변수처럼 사용되는 것이죠. (올해 정처기에도 나왔답니다..C언어로 나오긴 했지만요...(틀림))

static final이 짝꿍으로 다니는 이유?

static은 클래스 변수임을 의미합니다. 인스턴스들이 해당 변수를 공유하는 개념이에요.

final을 붙이면 "최종"이라는 의미로, 수정이 없을 것이라는 이야기가 됩니다. 

즉 static final은 인스턴스가 공유하는 최종 변수라는 의미로, 상수를 의미하게 됩니다.

static 메서드는?

메서드에 static을 붙이면 해당 클래스의 인스턴스를 여러 개 만들어도 static 메서드는 딱 한번 메모리에 할당되어 모든 인스턴스들이 그 메서드 하나를 공유하는 형태가 되는 것입니다. 매번 새롭게 선언할 필요가 없는, 인스턴스를 변경하지 않는 메서드라면 static을 고려해볼만 하다고 할 수 있습니다.

 

이번 미션을 통해 static이 어떤 녀석인지 알아볼 수 있는 시간이었습니다. 아직 완벽히 마스터했다고 할 수는 없지만 4주차엔 조금 더 적절한 곳에 static을 쓰는 사람이 될 수 있지 않을까 기대해봅니다.

 

4. 테스트 코드의 최고 강점

테스트 코드...이제 너 없인 기능 구현 못할 것 같아...

테스트 코드를 작성하기 전, 매번 실행하고 일일이 입력하고, 하나라도 오타나면 다시 처음부터 입력하고..제 자신이 테스트 코드가 되는 노동을 했었는데요, 테스트 코드를 작성할 줄 알게 되고나서는 손가락 까딱(실제로도 까딱임)하면 모든 기능을 검사할 수 있게 되었습니다. ㅈ가 이번 미션을 하면서 발견한(어쩌면 나만 몰랐을지도 모르는..) 2가지 중 나머지 하나가 바로 이것입니다.

"테스트 폴더 전체를 테스트하기" 

테스트 코드를 여러 개로 분리하고 싶었는데, 분리해도 한번에 돌리려면 대단한 기술이 있어야 하는 줄 알고 원하는대로 못 나눴었습니다. 파일마다 일일이 들어가서 테스트 코드 실행 버튼 누를 거 생각하니까 머리가 아찔해지더라구요..그러다가 테스트 폴더에서 마우스 오른쪽 버튼을 누르니 대단한 것을 발견. 패키지 내 테스트 코드를 한번에 실행하는 것이었습니다. 심지어 각 파일의 어느 함수에서 에러가 났는지도 잘 알려주더라구요....이 발견 이후로는 테스트 코드 작성의 즐거움을 무한으로 즐길 수 있었습니다.(행복~)

 

5. 정해진 루틴의 소중함

여기서의 루틴은 생활면에서의 루틴보다는 문제 풀이의 루틴을 의미합니다. 문제 풀이를 할 때, 루틴을 정해놓고 풀진 않았습니다. 이번 프리코스를 통해서 얻고 싶었던 목표 중 하나가 하루 중 일정한 시간에 문제를 풀고 그것을 기록하는 루틴을 만들고 싶다는 것이었습니다. 정해진 시간에 자리에 앉아 코딩을 하는 생활면에서의 루틴도 어느정도 만들어졌지만, 3주차를 끝내면서 문제 풀이의 루틴도 확실하게 얻어갈 수 있었습니다.

 

3주간 "문제파악 및 설계(1일)-설계 다듬고 문서화(1일)-구현(2일)-리팩토링(1일)-회고(제출 후 1일)"의 흐름으로 문제를 풀고 기록했는데요, 구현하는 이틀만큼 설계에도 이틀을 쓰게 되었다는 것이 새로운 변화를 만들었습니다.

 

첫날 문제를 생각하고, 이튿날 다시 고치는 시간이 올 때까지 문제에 대해 다시 생각해보면서 내 설계를 어떻게 바꿀 수 있을지 고민할 시간을 통해 추가적으로 알아야 할 것, 공부해야 할 것을 정리해볼 수 있었고 구현에도 잘 적용시킬 수 있었습니다. 설계를 공들여 하니 구현은 금방 걸렸던 것 같습니다.

구현 후에 리팩토링하는 시간도 하루 간 가지면서 구현에 급급해서 미뤄두었던 문제나, 다시 코드를 보니 떠오르는 더 좋은 방법들을 적용해보는 시간도 경험할 수 있었습니다. 사실 리팩토링하면서 더 많은 것을 배웠던 것 같기도 합니다. 

리팩토링 후 문서를 다시 정리하고 제출한 후에, 문제가 발표되는 화요일 전날인 월요일에 회고를 쓰곤 했는데요. 한 주 간의 회고를 쓰면서 저의 감정적인 변화와 기술적인 변화, 태도까지도 다시 돌아볼 수 있어 좋았습니다. 무엇보다 기억 속에만 남겨두면 쉽게 휘발될 수 있는 경험을 글로서 잘 기록해둘 수 있다는 것이 가장 보람찬 과정이었습니다.

 

6. 3주차 최종 소감과 마지막 주차의 포부

저의 문제 풀이 루틴의 마지막인 회고를 모두 작성하고 나니 이제서야 3주차를 마친 기분이 듭니다.

벌써 마지막 주차네요. 3주간 무엇을 배웠는지 다시 돌아보면, 소극적인 취준이 이어지면서 무얼 해야하지?라는 고민과 함께 매일을 살아야 했던 것과 다르게 바쁘게 계속 배워야 할 것, 해야 할 일이 있었던 3주가 꽤 달콤하기도 했습니다. 열심히 해결해야 할 것들을 해결하고 난 후 하루를 끝내면 뿌듯했었는데 마지막 주차가 끝나면 해야 할 것이 사라져 공허할 것 같기도 합니다. 그러나 이것은 시작을 마련하는 좋은 기회였다고 생각합니다. 이 기회에 좋은 틀을 만들었다고 생각하면서 작은 문제 풀이들에도 배운 방식들을 적용하고 계속 앞으로 나아가기를 고집하고 싶습니다.

 

마지막 주차, 우리 모두 파이팅!!!