2023년 11월 4주차 주간회고

내고나서 불안

내고 났는데 리뷰를 보다보니 들었던 생각
'내 마지막 코드가 이렇게 부족했다니... '
'빠진 예외 처리를 보면서 괜히 이것 때문에 떨어지는 거 아니야?' 이런 생각이 들며 1차 땅굴을 파고들었던 이번주 초반이었다.

맞다. 이성적으로 생각하면 그거 하나 잘못 썼다고 떨어지는 것은 아닌데,
불안하니까 이런저런 말도 안되는 생각들이 드는 것 같다🥲
망상 멈춰✋✋ 지나간 코드 생각해서 뭐하니~~

확장성 vs 최종 코테 제한사항

좋은 프로그램으로써의 확장성 vs 최종 코테 제한사항에 맞추기에 대한 생각이 들었던 한 주인데
마지막주 코드리뷰라 그런지 최종 코테의 제한점을 고려한 리뷰들도 있었다.

우테코 미션의 학습 목표이자 최종 코테를 고려했을 때, 확장 가능성에 맞춰진 설계보단 이것들을 우선적으로 고려할 필요가 있다는 점!

1. 요구 사항 준수
2. 객체 분리
3. 테스트 코드

코드에 감정이입하지 말자

이제 슬슬 나만의 코드 기준이 생기다보니 코드 리뷰를 보면서 아잇.. 근데 그래도 내가 쓴 이 코드도..! 하고 방어적인 생각이 들 때가 생기는 것 같다.

물론, 기준이 리뷰를 받을 때마다 바뀌는 것도 문제겠지만,
개발을 공부하는, 그것도 걸음마를 뗀 수준의 내가 벌써 리뷰에 방어적인 태도가 생기기 시작한다면, 그건 경계해야한다고 생각이 들었다.

코드 != 나

내가 짠 코드에 감정이입하지 말자!

🚨 처참히 멸망한 첫 실전 대비 코딩 테스트

보이는가. 이 빨간 tests failed가! 하하하하🚨🚨🚫🚫

그렇다. 어제 최종 코딩테스트 대비 스터디에서 처음으로 실제로 5시간을 재서 이전 기수 문제를 풀어봤는데.

멸.망.엔.딩을 맞았다.....!
결국 기능 테스트는 통과하지 못한채로 첫 모의고사(?)를 제출하게 되었는데

멸망한건 멸망한거고, 다시 부활시켜야하지 않겠나!
스터디 후에 스터디원들과 이야기를 나눠보고, 혼자도 돌아보면서 이유를 생각해보니,

1. 과도한 설계

프리코스 동안 미션을 진행하기 전 나는 항상 이 정도의 설계는 해놓고 시작했다.
어느정도냐 하면, 클래스명과 그 클래스의 필드, 메소드, 컨트롤러에 어떻게 연결될지까지
한 마디로 거의 다 코드를 짜놓는 수준으로 설계를 하고 시작했던 것이다.

물론, 프리코스 때에는 이 방법이 객체 분리와 협력하는 객체들, 의존성 파악이 쉽게 돼서 공부도 되고, 유용했다!
문제는, 5시간이라는 제한시간 중 2시간을 설계에 쓰다보니 마지막에 돌아가는지 확인할 시간도 없었다는 것.

2. 요구사항 제대로 안.읽.어...?

위의 설계를 보면 직직 줄 그어져있는 부분도 있고 할텐데, 맞다 설계를 다 해놓고, 요구사항을 제대로 읽지 않은 걸 발견해서 수정한 부분들이다.
이 수정에 30분~1시간이 들었으니, 시간부족의 아주 큰 요인 중에 하나라고 할 수 있지...
요구사항은 시간이 걸리더라도 잘 읽고, 이해하고, 설계에 반영하라고오오 현지야😭😭😭

3. 시간.. 시간.. 시간!

초반에 너어어~무 여유를 부렸다ㅎㅎ

객체 지향 필요하고, 원시값 포장 다 좋은데, 일단 구현을 해놓고 해야하는 거야!!
처음부터 잠깐만.. 이렇게 하면 한 객체의 책임이 너무 큰데? 어떻게 분리하지? ... (10분후) 이랬더니 시간 부족 엔딩을 맞게되었다.

원시값 포장, 테스트 코드 작성, 상수화 다 나중에하자!
일단 구현하기!!

뭐 첫 술에 배부르겠나!

기왕 망할 거 제대로 망해보는 거고, 원래 멸망했다가 다시 올라와야 재밌는거지!
(하고 어제 내내 좌절모드였던 사람이 씀)