회원가입, 로그인 기능 구현 끝나고.. - 기능구현 1주차

회원가입과 로그인기능을 구현한 후 PR를 날린후 멘토님께 코드에대해 설명하면서 리뷰를 받았습니다.

더 정확한 리뷰는 PR에 남겨주신다고했습니다.

 

느낀점

🔨TDD 중요성

회원가입과 로그인 부분작성하는데 의외로 오래걸렸습니다

더 디테일하게 작성하고싶었지만 저희가 만드는 프로젝트는 유저를 가정했기때문에 Valid부분에서는 약간의 헛점이 보이기도했습니다.

이러한 헛점을 찾아낸것은 바로 테스트코드였습니다.

저는 이번프로젝트에서 가장큰 목표를 테스트코드를 작성하는 습관과 작성을 잘하고싶었습니다.

멘토링하기전까지의 저는 코드작성을하고 기능을 테스트하는것을 end to end test로 사용자의 입장으로 Postman을 직접 URI를 호출함으로써 작동을 확인했습니다. 그런데 이러한 것을 테스트코드를 작성해서 테스트하다보니 직접 Application을 돌리는데 시간을 들일필요가 없었으며 더 정교해지는것을 받았습니다. 심지어 저는 더 개발이 빠르게도 느껴졌습니다.

결론적으로 TDD라고 강요를 하는글과 코드작성에서 테스트코드의 중요성을 몸소 와닿게 느꼈습니다. 이러한 계기로 저는 앞으로 테스트코드에대해서 더 고민하고 최대한 많은 테스트케이스대해 생각해보는 습관이 생겼습니다. 말로는 표현못하지만 깨닫게 되는 느낌이 엄청강하게 들었습니다.

 

👓  리펙토링

멘토링을 시작하게된 이유는 이전까지는 막 기술을 사용하는거에 대해 의미를 두었지만 이러한 태도는 미래의 저의 개발자로 성장하는것에 도움이 될가? 라는 의문을 가지게되어서 저는 멘토링을 신청하게 되었습니다. 그래서 프로젝트를 진행한다면 최대한 이전의 저의 모습과는다르게 테스트코드와 리펙토링, 기술적 고민, 트레이드 오프 등등 생각하면서 코드작성과 이전과 다른 모습을 보여주고싶었습니다. 

그래서, 코드작성을 하면서 저는 더 좋은 코드는 없을가 라는 고민을 항상 했으며 이러한 부분을 고민하면서 여러글로 찾아봤습니다. 그결과 다른분들은 미리 확장성을 가지거나 중복을 미리 제거하고 개발을 했을가? 이렇게 생각했습니다.

그래서 제가 직접 코드를 작성한 후 리펙토링할 부분을 찾아보게되었습니다. 최대한 중복을 줄일수 있으면 줄이고 싶은 마음을 가졌습니다.

그런데 이번에도 몸소 와닿게 되었습니다. 코드부분에서 SignUpDto에서 모든 필드값을 필수적이기때문에 Valid 체크를 했지만, 저는 이부분보다 그렇다면 final로 둔다면 어떨까 라는 생각도 해보게되었습니다. 이과정에서 이미 @Builder이며 Valid체크가되어서 null값을 방지가 되는데 final키워드가 중복적으로 사용된다면 오히려 과한 방지라고 생각해서 바꿨으며, 또한 ResponseEntity를 raw(원천)타입을 사용해서 보냈는데 raw타입보다는 정교성이 더좋다는 의견의 글을 보면서 코드를 바꿔갔습니다. 글에 담지못했지만 중복코드를 줄이기위해 최대한 제 코드들을 살펴보며 다른 방법이있는지 코드 탐색을 하며 바꿔가는 방법에대해 고민하는 습관을 가지게 되는 계기가 되었습니다.

 

😢기능분담

로그인과 회원가입 구현까지는 공통적으로 서로 해보라고 하셔서 해보게되었습니다.

그리고 리뷰를받고 리펙토링이 끝나면 이제 동료분과 함께 페어프로그래밍을 하게될것인데 문제점이 생겼습니다. 바로 기능을 어떤식으로 나누어야할지 저희는 포트폴리오로 사용하고싶기때문에 저와 동료분 둘다 한쪽으로 치우치게된다면 자신의 능력을 못보여주기때문에 걱정이되었습니다. 왜냐하면 포트폴리오상이나 코드 PR상으로도 보여줄수있지만 PR한 사람만 구현한것처럼 보이기떄문입니다.

그래서 멘토님께 물어보니 멘토님도 현업가면 프로모션에 도움이되는 부분이 있기때문에 현업에서도 에러만 고치기보다 기능구현이나 새로운 시스템을 도입하는 부분에대해 느껴지는 경쟁이 있다고 하셨습니다. 

그래서 이번에 기능을 구현을 계속이어나갈텐데 누구는 구현을했지만 누구는 못했다 이렇게 보이는게 고민이됬습니다. 물론 그런부분이있지만 같이하시는분도 훌륭하시고 저도 노력을 하기때문에 기능을 나누면서 최대한 치우치치않게 나누고싶었기떄문에 같이팀인데 이러한부분을 고민하게되는게 슬펐습니다. 누군가 나눠줬으면 좋겠다...

 

그래서 팀원분과 이야기해본결과 해결방법은 바로 중요한 기능이 있는 부분이라던지 하고싶은 부분은 서로 구현을 해보고 PR을 날리고 토론을 가지고 merge를 하자 라는것이었습니다. merge도 물론 누가 잘했다 라고 판단이 힘들지만 서로구현을 해봤다면 구현을 한것이라 생각하고 문제해결한 경험이 중요하다고생각하기떄문입니다

여전히 해결했다고 말하지 못하지만, 이게 협업에서의 가장큰 어려움인것같습니다.

 

🦕성장

구현을 직접해보고 발표 해본주차에 느낀것은 저 나름대로 테스트코드도 중요성을 인식하고 작성을 무조건 할려고하며 또한 코드를 작성하면서 손이가는대로보다 생각하면서 변수이름, 메서드이름, rest-ful한 설계인지 또한 클래스 이름하나하나 고민 또한 서비스에대해서 고민과 빈등록 고민 등등 생각하면서 작성하게되었습니다. 

 

이전의 제가 작성한 코드가 부끄러울정도로 고민을 더 많이하게되었습니다.

이번주차에서는 몸으로 와닿게되는 부분이 많았고 성장이된듯한 저의 자세에대해 만족했습니다. 더 성장할것입니다.

 

보완할 점

문제해결시에 블로그에 글을 남기는 시간이 모잘라서 밀렸는데 글작성요령과 그리고 발표시에 이, 그, 저, 이렇게, 이러한 단어를 자제할려고 노력해야겠다.

그리고 프로젝트만 만드는데 시간을 사용했습니다.

더 좋은 프로젝트를위해서 개인적으로 공부를 많이했어야했는데 이번주는 개인적일이 많아서 못했습니다. 이번주부터는 개인적 공부와 알고리즘 + 정처기 또한 공부해야하는 한주가 되기위해 보완해야겠습니다.

TMI 운동시작했습니다.