비전공자 && 자바 어린이의 백엔드 프리코스 회고
지난 주차 소감에, 전례 없이 몰입하겠다고 다짐했던 기억이 난다.
다행히도 이번 주는 그 다짐을 지켰다. 후회가 남는 순간이 떠오르지 않을 만큼 최선을 다 했다.
그만큼이나 많은 것을 배우고 느낀 시간이었다. 어느 정도였냐면..
미션 제출 시에 소감을 작성해서 내야 하는데, 명시는 되지 않았지만 글자수 제한이 5,000자라는 것을 누군가 공유해주셨다.
1주차에 그것을 듣고 "5,000자를 쓰는 사람이 있어..? 너무 늘여쓴 거 아닌가.."라고 생각했는데
이번 주의 내 소감 초안은 6,000자였다..
자소서를 다듬듯이 수정해서 글자수를 맞추고 제출했다는..
그리고, 여러번 검토해서 실수 없다고 생각했는데 제출하고 보니
"첫째로, 결과를 통해 과정을 돌이켜본다는 것입니다.."
라고 적은 것을 발견했다.
왜 아련한 건데..
아무튼 회고 시작!
기술적인 배움
클래스(객체) 분리
MVC를 흉내냈던 지난 주차와는 달리, '객체'에만 집중해서 프로그램을 설계했다.
M(model)도 잘 모르면서 MVC를 쓰던 나였는데,
코수타에서 말씀해주신대로 요구사항에 집중해보기로 했다.
(역시 그것만으로도 벅찼다..)
'도메인' 로직과 'UI' 로직을 분리하라는 요구사항도 있었다.
'도메인'이라는 단어가 잘 와닿지 않아 따로 찾아보며 공부했고,
'프로그램이 해결하려는 문제, 또는 그것이 속한 분야'라고 나름대로 정의를 했다.
객체를 설계할 때는 현실세계의 개념을 차용했다.
프리코스를 진행하며 '객체지향' 개념을 처음 제대로 공부했고,
'객체지향의 사실과 오해'라는 책의 도움을 많이 받았다.
이번 미션에서는, 책에서 배운 내용을 제대로 써먹을 수 있었다.
특히, 핵심 책임(행동)을 먼저 떠올리고,
- 입력한 금액 만큼의 로또를 발행한다.
- 로또의 당첨 여부를 계산한다.
- 총 로또의 당첨 결과를 계산한다.
책임을 위해 오고갈 메시지에 집중했다.
그렇게 도메인 모델을 설계할 수 있었다.
지금 다시 보니 부족한 부분이 많이 보이지만..
그래도 내가 이런 다이어그램을 손으로 그렸다는 것 자체가 뿌듯했다.
필요한 정보들이 많이 부족할 수도 있지만..
핵심 메시지만 간결하게 담아, 읽히기 쉽다는 장점은 확실히 있는 듯하다.
이후에는 기능 구현 목록을 자세히 작성하고, 구현을 시작했다!
아무튼, 이렇게 설계에 공을 들이고나서 구현을 시작하니, 거칠 것이 없었다. (사실 많았다..)
도메인 로직에 대한 단위 테스트
지난 미션을 통해 '테스트 케이스 구현'에 대해서 익숙해질 수 있었다면,
이번 미션을 통해서는, 테스트의 의미와 설계, 구조와 리팩토링 등 전반적인 실력을 향상시킬 수 있었다.
그에 앞서, 지난 주의 나는 public, private, default의 뜻만 알고,
그것을 어떻게 써야하는지 전혀 몰랐다.
대부분의 메서드가 default로 선언된 것만 봐도 그렇다..
하지만 피어 리뷰와 아고라 정독을 통해 관련 키워드를 공부할 수 있었고,
이번 주에는 public 메서드와 그것을 뒷받침하는 private 메서드를 분리해서 구현했다.
하지만 private 메서드를 어느 범위까지 설정하고, public 메서드 테스트로 대체해야하는지 정확한 감이 없었다.
--> 3주차 공통 피드백에서, private 메서드 사용 범위에 대해 짚어주셨다.. 나름대로 소름이 조금 돋았다..
또, 2주차 미션에서는 테스트 코드의 가독성이나 컨벤션을 전혀 고려하지 않았다.
하지만 3주차 미션에서는 구현이 익숙해지니 가독성과 유지보수 같은 것들을 신경쓸 수 있었다.
should_기대결과_When_테스트상태 컨벤션으로 메서드명을 수정했다.
물론 DisplayName이라는 어노테이션으로 테스트 케이스 설명을 작성할 수 있지만,
메서드명을 아무 의미 없이 흘려보내지 않고, 직관적으로 이해할 수 있도록 작성하는 것은 의미가 크다고 생각했다.
BDD 패턴의 일종인 'given, when, then' 패턴도 적용해보았다.
테스트 코드 가독성 뿐만 아니라, 테스트 케이스의 목적을 스스로 정확히 이해하는 데에도 도움을 주었다.
직관적인 코드는 언제나 득이 된다.
그리고, 공통 피드백에 언급되었던 내용대로
테스트 코드를 작성하는 이유에 대해 고민해보았다.
기능을 빠르게 검증할 수 있어서 구현 당시에도, 리팩토링 시에도 큰 도움을 받을 수 있는 것은
지난 주에 이미 절실히 깨달았다. 그리고 그 외에도 느낀 점이 많았다.
첫째로, 결과를 통해 과정을 돌이켜볼 수 있다는 것이다.
기능을 구현할 때는, 내가 알고 있는 이론들로 가설을 세우고 코드로 표현한다. 거기에 더해 테스트 코드를 작성하면, 기능 요구 사항을 토대로 다양한 케이스를 검증할 수 있다. 결과를 토대로 프로덕션 코드의 과정을 되돌아 볼 수 있는 것이다.
마치, 경제학의 이론을 세우는 것이 구현이라면, 그것이 시장에서 적용이 되는지 확인하는 것은 테스트와 같다고 생각했다.
테스트를 구현하고 실행하면, 그 즉시 코드의 실용성을 많은 부분 파악할 수 있었고,
부족한 부분, 모순된 부분을 파악해 이론에 적용할 수 있었다.
둘째로, 학습을 위한 새로운 도구가 되어줬다는 것이다.
공통 피드백에 있던 내용인데, 테스트를 학습 도구로 사용했다.
기존에는 어떤 자료형과 메서드를 사용해보고 싶으면, 새로운 프로젝트를 만들어 실행시켰다.
여간 번거로운 일이 아니었다.
하지만, 테스트 코드로 원하는 기능을 작성하고 실행하면 간단하게 그 결과를 확인할 수 있었다.
거기에다 프로덕션 코드 작성 중 학습 기록을 아주 쉽게 참고할 수 있어 더욱 좋았다..
이런 생각을 여태 못 했다니..
특히 이번 미션에서는, 나를 아주 못살게 굴었던 수익률 계산을 연습할 때 큰 도움을 얻었다.
Math.round(), String.format() 등 다양한 메서드를 사용하다가
DecimalFormat이라는 녀석을 알게 되었고,
테스트 코드를 통해 쉽게 연습할 수 있었다!
종합하면,
테스트 코드는 기능을 검증하고, 촘촘한 기능 설계를 도우며, 학습을 위한 도구로도 사용이 가능하다는 것을 깨달았다.
설계, 작성, 학습, 유지보수까지, 개발 전 과정에 걸쳐 지대한 영향을 미치는 것이다!
예외 처리
메일로도 공지가 왔던 예외 처리 요구 사항을 구현하면서,
많은 지원자들이 겪던 문제를 나도 동일하게 겪었다.
사용자가 잘못된 값을 입력할 경우 IllegalArgumentException를 발생시키고, "[ERROR]"로 시작하는 에러 메시지를 출력 후 종료한다.
위의 요구사항이었는데,
try catch를 통해 IllegalArgumentException을 발생시키고, 콘솔에서도 확인했지만
테스트가 통과되지 않았다.
테스트 코드가 정의된 곳에서 발견한 NoSuchElementException을 발생시키니 테스트 통과는 되었지만,
의도한 바가 아니라는 것을 쉽게 알 수 있었다.
아무리 생각해도 방법이 떠오르지 않자.. 그냥 포기할까 생각도 했지만..
나는 프로그램이 종료되는 것이 아니라 '종료한다'는 표현에 집중했다.
그 결과! 나의 코드는 프로그램을 종료한 것이 아니라, 비정상적으로 종료된 것임을 깨달았다.
예외의 메시지를 출력하고, 예외를 발생시켜서 비정상 종료되는 것이 아니라!
예외 메시지를 출력하고, 더이상 실행할 명령이 없어 자연스럽게 프로그램을 종료하는 그림을 떠올렸다!
그 결과, main 메서드에 try catch를 적용함으로써 문제를 해결할 수 있었다..
와.. 이걸 깨달았을 때 카타르시스는 정말 잊을 수 없었다..
그리고 이 과정을 통해 예외처리에 대한 없던 기초가 세워졌다.
내 프로그래밍 인생 처음으로(길지도 않지만 ㅋㅋ), 예외처리 개념을 제대로 이해했다고 느꼈다..
(관련해서 블로그 아티클도 적었다!)
[Java] 간단한 예외처리(try catch) 원리 (feat. throws IllegalArgumentException은 왜 빨간 줄이 안 생길까?)
예외를 처리하다 보면, 아래와 같은 에러 문구를 쉽게 볼 수 있습니다. 바로 Unhandled exception 입니다. 예외 발생 예외의 종류는 다양하고, 예외가 발생하는 코드도 다양합니다. 본 아티클에서는,
woojin.tistory.com
프리코스 커뮤니티
이번 주차 목표 중 하나는, 프리코스 커뮤니티에서 얻을 수 있는 모든 것을 얻는 것이었다.
- 주간 회고록 공유
- 동료분들의 회고 10개 정독하기
- 피어 리뷰 10개 작성
- 토론 글 전부 정독
- 토론 글 작성하기
위 내용을 목표로 나름대로 최선을 다해 커뮤니티 활동을 했다.
역시 넘치게 많은 것을 배울 수 있었다..
동료분들의 회고에서는, 프리코스를 바라보는 새로운 시각, 기술적인 배움을 구할 수 있었다.
피어 리뷰는 정말 기술적으로 크게 성장한 경험이었는데,
리뷰 경험이 거의 없던 나는 타인의 코드를 이해하는 것이 너무 벅찼다..
하지만 리뷰를 계속할수록, 로직을 이해하는 속도가 빨라졌다!
그리고 남의 시선으로 바라본 나의 코드의 문제도 계속해서 떠올랐다..
그리고 토론..
아고라 들어가보신 분들은 아시겠지만, 주제랑 의견의 퀄리티가 상당하다..
엄청나게 많은 글이 올라오지는 않지만,
미션 진행하면서 혹은 개발 공부하면서 한 번쯤 고민해봤을 문제를 가지고 의견을 나누고 계신다.
특히 getter의 사용 여부나, 테스트 네이밍 컨벤션에 대해 생각해볼 수 있어서 좋았다.
인간적인 배움..
나의 눈물샘을 자극하는 사건이 하나 있었다.
피어 리뷰를 나름대로 열심히 남긴 덕에, 많은 분들께서 나의 PR에 찾아와 리뷰를 남겨주셨다.
그중 특히 기억나는 리뷰가 있는데..
나를 '고수'라고 칭해주신 어떤 분의 코멘트였다.
올해 초, 개발 공부를 처음 시작하고나서
지금까지 단 한 번도 스스로 '잘한다'는 생각을 가져본 적이 없었다.
적지 않은 나이에, 나름대로 성취한 것을 다 버리고 새로운 분야에 도전했다.
그만큼 조급했고, 남들과 비교하며 부족한 점에만 집중해왔던 것 같다.
지난 7월에 네이버 블로그에 적었던 글의 일부.
개발 생태계에 입문하고, 계속해서 열등감을 느끼던 나의 모습이 기록되어 있다.
근데 저 리뷰 코멘트 한 마디를 보고,
'누군가는 나를 인정해주는구나'라는 생각에 자신감을 많이 얻을 수 있었다.
지나온 날들에 대한 보상을 받는 기분도 들었다.
돌이켜보면, 해야 할 일에 집중하기 바빠서 해내온 일들을 흘려보내는 경우가 많았던 것 같다.
가끔은 이렇게 이뤄낸 것도 돌아보며 자신감을 얻을 줄 아는 사람이 되겠다고 다짐했다.
그리고 나도 누군가에게 좋은 영향을 줄 수 있도록, 리뷰를 열심히 달겠다고 다짐했다.
이번 주에도 10개의 피어 리뷰를 아주.. 정성스럽게 달아보려 한다..
마지막으로, 이번 한 주도 밀도 높은 성장을 경험하게 해주신 많은 분들께 감사드린다고 말씀드리고 싶다.
아직은 막연하지만, 단단한 철학을 가진 개발자가 된 미래의 모습을 자꾸 그려보게 되는 행복한 한 주였다.
한 가지 안타까운 것이..
주차가 거듭될 수록, 지원자들의 PR 수가 떨어지고 있다는 것이다.
미션 난이도가 쉽지 않고, 시간 투자도 어느정도 해야하니..
사실 나도 학교, 알바를 병행하며 벅찰 때도 있었지만,
그래도 다른 프로젝트 개발을 미리미리 해둔 덕에, 나름대로 시간과 여유를 확보해둘 수 있었다.
하지만 일을 하고 계시거나, 다른 이유로 많이 바쁜 사람들은 미션이 정말 어려울 수도 있겠다는 생각을 했다.
그럼에도, 많은 사람들이 끝까지 함께 하며
많은 것을 함께 배우고 성장하면 좋겠다는 바람이 있다.
왜냐면 내가 성장하는 이 시간이 너무 좋아서.. (맛있는 건 먹어보라고 하고 싶은 것 처럼..)
아무쪼록 모두들,
무탈하면서도 크게 성장하는 마지막 주차가 되시길 기원합니다!
읽어주신 모든 분들께 감사드립니다.
'우아한테크코스 5기 백엔드' 카테고리의 다른 글
| 합격하고 적는 우아한테크코스 5기 최종 코딩테스트 #준비방법 #시험후기 #백엔드과정 (5) | 2022.12.29 |
|---|---|
| 프리코스 4주차 회고 - 곧은 철학의 개발자가 되리라 다짐하며.. (우아한테크코스 5기 백엔드 프리코스) (2) | 2022.11.23 |
| 프리코스 2주차 회고 - 나만의 페이스를 유지하자 (우아한테크코스 5기 백엔드 프리코스) (2) | 2022.11.11 |
| 프리코스 1주차 회고 - 더도 말고 덜도 말고 1주차만 같아라~ (우아한테크코스 5기 백엔드 프리코스) (2) | 2022.10.31 |