3주차 회고

 

❐ Description

---

3주차 작업 과정에서 느꼈던 점과 과제 후기를 작성한다.

 

 

 

 

 

❐ Source code

---

GitHub - Gilbert9172/java-lotto-7

 

 

 

 

❐ Self - Review

---

1.  [자동차 경주]에서 받은 피드백을 적용해보았는가?

1주차에는 다양한 시각으로 피드백을 받았었는데, 사공이 많으면 배가 산으로 간다고, 너무 많은 의견들을

적용하는데 작업의 효율성 측면에서는 별로였던 것 같았기 때문이다.

 

그래서 이번에는 스터디원(4명)으로 부터만 피드백을 받아보기로 했다.

 

#️⃣ 적절하지 않은 패키지명

같이 스터디하는 동훈님의 피드백이였다.

2주차 과제 구조

front 패키지를 보면 model이라는 패키지명 하위에는 InputManager, OutputManager가 위치한다.

위 두 클래스는 InputView와 OutputView에 의존하고 있어, model이라고 보기 어렵다라는 피드백이였다.

이 말에 동의하는 부분이고, 저번 과제에서는 패키지명에 신경을 많이 썼는데 놓쳤던 부분이라고 생각한다.

 

이번 과제에서는 해당 패키지가 무엇을 제공하는지 더 명확히 보여주기 위한 네이밍을 했다.

기존에 model이라고 사용하던 패키지명은 terminal로 해주었다. (맥북 터미널을 연상해서 네이밍했다.)

그리고 Validator 패키지의 경우도 하위에 도메인 별로 패키지를 두어, 어떤 도메인에 대한 validator를

제공하는지 한눈에 띄게 작업하였다. 

 

 

#️⃣ Eof

해당 피드백은 예찬님으로 부터 받은 피드백이다.

이런 소소한 부분도 꼼꼼하게 챙겨야겠다는 마인드 셋을 심어준 피드백였다.

 

 

 

2. 설정 목표를  성실히 수행했는가?

#️⃣ 최적화된 요구사항 분석 방법 찾기

이번에도 2주차와 똑같이 User와 System으로 분리하여 진행했다. 이번에는 Exceptions라는 파트 대신

Validation Check List라는 파트를 추가해봤다. Exceptions는 예외 상황만을 다루는 느낌이 강하게

들었기 때문이다. 확실히 해당 챕터가 포함하는 범위가 넓어지다보니, 생각하는 폭도 넓어졌다.

 

다음 과제에서는 User와 System으로 구분하는 것은 Fix할 것이고, Exceptions와 Validation Check의

적절한 조화를 찾아봐야겠다. 아마 아래의 구조로 설계할 것으로 생각하고 있다.

• xxXException
  • ~~~ 경우 
  • ~~~ 경우

 

#️⃣ 성장에 대한 욕구가 강한 개발자 네트워크 형성하기

팀원들과 좋은 코드 나쁜 코드라는 책으로 매주 1회 스터디를 한다.

각자 할당된 챕터를 읽고, 정리한 뒤 이슈를 생성한다. 그리고 해당 이슈에 다른 팀원들이 의견을 달아

서로의 생각을 공유하며 생각을 확장시키고 있다. 

뿐만 아니라 매주 화요일에는 오프라인으로 모여 이전 주차 과제에 대한 코드 리뷰를 진행하고,

서로 적극적으로 피드백을 주고 받으며, 긍정적인 방향으로 성장해 나아가고 있다.

마지막으로 매일 자신이 한 일을 Daily log 형식으로 공유하고 있는데, 이는 굉장히 좋은 자극으로

다가오고 있다. 

 

 

#️⃣ 아는 것과 모르는 것을 명확하게 구분하기

평소 EnumMap을 사용하곤 했었는데, 확실히 내부적으로 어떻게 동작하는지, 정렬되는 기준은

무엇인지에 대해서는 알지 못한다고 판단했다. 이번 과제를 통해 언제 EnumMap을 사용하고

왜 사용해야 되는지를 제대로 알게됐다. 

 

추가적으로 static 메서드는 언제 사용해야 하는지, 얼마나 사용해야 하는지에 대한 고민을 많이

하고 있었는데 이번 주차 과제를 통해 그 기준을 조금이나마 알 수 있게됐다. static 메서드를 

사용하게 되면 다형성을 제대로 사용할 수 없다는 특징이 있는데 다음 주차 과제에서는 이 부분을

주의하면서 작업을 진행할 것이다.

 

 

 

3. 과제 후기

3주차 과제에는 기능 구현도 중요하지만 1주차, 2주차 과제에서 놓쳤던 부분을 최대한 신경쓰면서 

작업을 했다. 손에 익지 않던 방식을 적용하여 작업을 하려니깐 작업 속도면에서도 더딘 느낌을 받았다.

하지만 이번 기회를 통해 좋지 않은 습관을 고친다는 마인드를 가지고 작업하게 됐다.

또한 이런 환경에 적응되는 것도 추후 회사의 컨벤션을 받아들이는데 있어서 좋은 훈련이라고 생각했다.

 

이번 과제는 살짝 요구사항이 아쉬운 부분이 있었다. 분명 문제에서는 수익률을 구하라고 했지만, 

아무리 계산을 해봐도 회수율을 구하는 요구사항이였기 때문이다. 처음에는 의문을 품고 작업을 했지만,

작업하는 과정에서 "혹시 이건 의도된거 아닐까?" 라는 생각이 들었다.

 

왜냐면 기획자도 사람이기 때문에 실수를 하기 마련이다. 한 번 실수했다고 비난을 하면 원활한 팀워크가

유지될까? 절대 그럴수 없다고 생각한다. 서로의 실수를 옹호해주는 것도 필요한 덕목이라는 것을

깨우치게 됐다. 물론 무조건적인 옹호보다는 비슷한 실수를 안하게 끔 적절한 피드백을 주면 될 것 같다. 

 

의도됐든 안됐든, 우테코에서는 프로그래밍 외적인 부분도 많이 배워간다는 느낌을 받았다.

참여하는 사람의 참여도에 따라 다르겠지만, 적어도 나는 3주동안 좀 더 성장한 느낌을 받고있다.

 

 

 

 

 

---