과제테스트 회고

과제 테스트를 끝냈다.
기간은 일주일이 주어졌지만 실질적으로 작업 한 시간은 주말 2틀정도?
왜 하필 그 전주에는 해외여행다녀와서 여독이 있었으며, 업무는 왜 또 많았고, 술자리도 많았을까? 머피의 법칙 같은걸까?(머피 rosha...)
핑계는 이정도하고 잘한 점, 잘못한 점, 아쉬웠던 점, 앞으로 점점 발전할 점에 대한 회고를 기록하려 한다.
다른 사람이 과제 테스트를 진행하기 전에 이 글을 보면 도움이 될 수 있도록 상세히...

 

잘한 점

뭐가 있으려나? 있긴하려나
굳이 생각해보자면, 과제테스트를 시도했던 점? 뭔가 결과를 내기위해 몰입했던 점?, 실제로 TDD로 구현했던 점? 좋은 코드를 짜기위해 고민했던 점?
생각해보니 많은데 전부 잘 한 부분이면서 못한 부분인 아이러니한 상황
먼저, 과제테스트를 시도했던점은 제일 잘 한 부분인것같다. 밑에서 적겠지만 이번 과제테스트로 굉장히 많이 배우고, 성장한게 느껴졌다. 일단 부딪혀봐야 깨지고 성장한다는 말이 뭔지 느낄 수 있었다.

이 세계 벽 절대 안 높아. 할 수 있어!
남자는 뭐? 자신감! 자신감! 남자는 뭐? 자신감이야.
일단 붙어봐야 될 것 아니야. 저질러보고. 깨지고, 박어.
가슴만 뛰는 개발자 아니라, 가슴하고 내가 같이 뛰어야 돼.

갓웅정의 명언. 겪어보고 나서야 이해가 되는 말이었다.

 

두번째로 결과를 내기 위해 몰입 했던 점은, 내가 개발하면서 하루종일 앉아서 집중하고, 늦은 시간까지 열정적으로 무언갈 만든게 최근 몇 년간 있었던가? 익숙해서 나태해진 업무의 코드들, 혼자 짜다보니 짜게식은 코딩컨벤션 등 나태해진 내 상태를 바로 알 수 있게 하였다.

세번째로 TDD는 말로만 해야지~ 또는 업무코드는 너무 복잡하고, 급한 이슈부터 처리해야지~ 하다가실제로 처음 적용해봤다. 미친놈이지. 시간도 없고, 할줄도 모르는 상태에서 처음시도해보다니. 근데 막상 적용하니 좋은 점이 많았다.

1. 매번 빌드해서 포스트맨으로 테스트하던 내가 테스트 코드가 익숙해지고, 검증이 완성된 코드를 적용하였다.
2. 제출 6시간 전 발견했던 버그 및 미구현 기능들을 고치고 추가하는데 적은 시간이 들었다.
3. 테스트하기 쉽게 기능들을 파일로 나누었고, 그결과 자동적으로 객체지향적인 코드작성이 가능했고 리팩토링이나 기능수정 시 버그가 현저히 줄었다.
4. 리팩토링 대상이 줄었으며 막상 진행해도 굉장히 쉬웠고 안정적이었다.

네번째로 좋은 코드를 짜기위해 고민했던 점인데 그동안 책이나 블로그로 열심히 눈동냥했던 내용들을 적용해봤다. 정책은 언제든 변경이 일어나기때문에 확장 가능한 코드를 짜고싶었다. 그외에도 스태틱빌드패턴, TDD, 테스트모듈화 등 다양한 기능을 적용해본것 같다.

잘한 점이 있긴 한가? 해놓고 많이쓴 느낌...

 

잘못한 점

 

잘못한 점은 너무 명확했다.
준비가 안돼있었다. 아쉬운 점에 쓸까 하다가 여기 적는게 맞는것 같다.
평소에 준비안한게 내 잘못이다.
성공에 운이 정말 중요하다고 하지만 그 운도 볼 줄 모르고, 능력도 안되면 잡을 수 없는것같다.
"난 내가 능력이 좋아서 성공했다고 생각하지 않아요. 정말 운이 좋았어요" 라고 말하는 사람들은 본인 기준이 높을뿐 그 운을 잡을 능력이 있었고 준비된 사람이라 생각한다.
또 과제를 진행하며 잘못한 점은 침착하지 못했던 것 같다.
평소였으면 큰 문제가 있다면 작은 단위로 나눠서 해결하여 진행했을 것 같은데, 겁많은 개가 사납게 짖는걸까? 뭔가 이만큼이나 알고있다고 보여주고 싶어서였을까? 큰그림을 그려놓고 크게 개발을 해버렸다.
큰 그림을 그리고 작은단위로 완성해나가야 하는데 그 부분이 아쉬웠다. 이부분은 밑에 아쉬운 점에 나오겠지만 평소에 구현해보지 않았던 스프링시큐리티가 큰 부분을 차지하는 것 같다. 개념도 잘모르고, 구현할줄도 모르는데 이틀만에 하려다보니 시간에 쫒기는 느낌... 평소에 준비가 너무 안된게 드러났다.

 

아쉬웠던 점

잘못한 점과 마찬가지로 준비가 너무 안돼있었다.
평소에 보일러플레이트처럼 과제테스트용으로 준비된 레포가 있었다면 기본적인 구현시간은 줄일 수 있지 않았을까?
그 시간에 비즈니스적으로 처리할 로직이나, 예외처리등 진행이 부족했던게 너무 아쉽다.
실제 평가 기준이 어떨지 모르지만 내가 심사를 한다면 이런 비중에 더 큰 점수를 주지 않을까?
알면서 못한게 가장 아쉽다.. 지금 내가 하는 업무, 강조되는 부분이 그 부분인데!!!
구현에 바빠 로직에 신경쓰지 못한게 이번 과제테스트에서 가장 아쉬운 부분이다. readme도 @쌈뽕하게 적고, 예외처리도 이런것 까지 생각했어? 들 정도로 하고싶었는데...
지금이라도 생각나는 부분을 적어보자면

• 정책적으로 정해져야 할 부분정리, 그중 임의로 하나 진행후 주석으로 표시
• 스크래핑시 컬림이 있을경우, 없을경우
• 스크래핑 요청이 여러번 올 경우 처리 방안(처리하긴햇는데.. 중복조건 잘못줌..연도별로 스크래핑 하는건데 중복 조건에 연도가 빠졌어요 담당자님....)
• 외부api요청시 타임아웃관련 설정들
• jwt refreshToken관련
• 예외처리 부분에 대한 좀 더 상세한 테스트코드
• 등등
  다음에 잘할게요는 없다. 이 글을 읽으신 분은 지금부터 잘하길... 나도 지금부터 잘할게요

 

발전할 점

 

징징댈거 다 징징댔고, 그래서 어떻게 발전할까?
먼저 잘못된 점에서 발전 할 부분은 평소에 준비를 해놔야겠다.
스프링은 php와 다르게 공부할 부분이 너무 많다. 정말 뛰어난 개발자들이 구현한 기능을 잘 가져다 쓰면되는 편함도 있지만, 알지못하면 제대로 쓰지도 못한다... 컨벤션도 빡빡하고,,, 공부할게 많다.
주변에 있는(이번에 이직하는) 개발자친구는 새로운 기술이나 관심있는 기술이 있다면 깃허브 저장소 하나 파서 붙여본다고 한다...역시 이직자는 뭐가 달라도 다르다. 내가 생각하는 이직하는 사람의 기준은 회사에서,적어도 팀에서 가장 잘하고 인정받는 사람인것같다. (나처럼 운이좋거나, 옆그레이드가 아닌 하고싶은 도메인이나, 원하는 회사로 이직하는 사람 기준)
아무튼, 기본적인 기술에 대해서는 가볍게라도 적용 해 봄으로써 사용법정도는 익혀놔야할것같다.
그래야 필요한 부분이 있으면 추가로 적용하고, 고칠 수 있으니 말이다.
이번 잘한점에서 적은 TDD도 업무에 적용해서 고도화 시키면 과제테스트 같은 간단한 테스트는 금방 짤 수 있을 것같다. 우선 테스트코드가 익숙해질 수 있도록 테스트 방식이나 어노테이션들 정리를 진행 할 예정.
우선 가볍게 이정도? 이정도만 발전해도 다음 과제테스트가 있을때

(없길바래봄)

구현에 힘쓰지않고 좀더 도메인의 비즈니스로직이나 예외처리 부분에 집중할 수 있을 것 같다 .

느낀점

매일 한걸음씩 성장했다고 했을 때 이번 과제테스트로 세단뛰기는 한 것 같은 성장을 경험했다.
이 글을 읽을 누군가도 갓웅정의 명언을 따라 이 경험을 해봤으면 좋겟다.
나는 이만 또 깨지로 가야겠다.(어제 한 마이그레이션 잘 못 된듯)