이미 회사를 1년이나 다녔지만 다시 신입이 되어버린 강정. 그래도 일년동안 회사를 다니면서 배운걸 정리해보려고 한다.

빠르게 팀에 적응하기

처음에 입사를 하면 당황스럽다! 기존에 많은 코드가 짜져 있는데 이걸 어디서부터 어떻게 읽어야 하지? 이 방대한 코드를? 입사해서 사수가 코드 한번 보세요~ 했을 때 정말 어떤 파일부터 읽어야 하는지 막막했었다.

팀 서비스 사용해보기

우리 팀은 이런 걸 만드는구나~ 프로덕트를 직접 사용해보면서 어떤 기능이 있는지 익혀보면 나중에 작업을 맡을 때 편하다. 정말 기본중의 기본이겠지만 적어본다. 나는 팀에 배정받기 전에 프로덕트를 많이 사용해봐서 익숙했다. 팀에 들어와서 이야기 할 때 따라잡기도 좋았다.

api의 시작부터 끝까지 따라가보기

구조 익히기에 정말 좋다! 처음에 방대한 코드 하나하나 읽는것보다 (솔직히 이렇게 읽으면 이해도 안 된다) api 요청부터 응답까지 따라가는게 좋다. 나는 팀에 가면 콘솔 찍어보면서 api를 받고 -> DB에서 값을 꺼내오고 -> 돌려주는 과정을 확인해본다. 이러면 서버의 대략적인 구조를 알 수 있다.

이해한 내용을 바탕으로 직접 구조 그려보기

아마 팀에 들어가면 어떤 기능이 있고 어떤 구조로 되어 있는지 한번은 들었을 것이다. 이후에 내가 직접 코드를 읽어보면서 구조를 다시 그려보면 더 잘 이해할 수 있다. 그리고 그걸 팀원에게 피드백 받으면서 잘못 이해한 내용도 바로잡을 수 있고 팀원도 구조에 대한 회고를 진행할 것이다(..)

+ 덧

어떤 기능에 대해 알고 싶은데 어느 부분을 살펴봐야 하는지 모르겠다! 그러면 해당 기능에 대한 기획 문서가 있다면 기획 문서를 보고 코드는 PR을 통해 파악한다. 해당 기능을 작업하기 위한 PR이 분명 있을 것이다. 그럼 그 코드를 보면서 아 이런 부분이 추가되었으니 나도 여기를 봐야겠다 감이 잡힌다.

작업을 뒤엎지 않기 위해

아마 신입으로 작업을 맡아서 끝내고 PR을 올리면 아주 많은 리뷰를 받을 것이다. 당연하다.. 그것이 신입이니깐.. 농담이고 팀 컨벤션도 낯설고 기존 코드도 낯설고 이미 있는 기능도 못 쓸 수 있다. 그런데 그런 것보다 구조 자체를 잘못 구현할 수 있다. 이런 경우는 애써 짠 코드를 다 갈아엎어야 할 수 있다.

내가 느낀 건 바로 기능을 구현하지 말고 어느정도 설계가 된다면 공유해서 점검을 받는게 낫다. 그럼 어느정도까지 설계를 해야 할까? 나는 보통 아래 내용들을 공유한다.

• api의 request와 response값
• DB에 어떤 값을 저장할것인지
• 로직을 어떻게 할지 대략적으로 공유

api를 먼저 설계해서 프론트엔드에게 불필요한 값을 넘겨주지 않는지 점검하고, DB에 저장하지 않아도 되는 값이 있는지 확인하고, 간단하게 어떤 형식으로 구현할지 이야기한다. 이러면 엄청 크게 구조를 바꾸지 않아도 됐다. 이건 내가 스타트업에서 근무해서 그럴 수도 있겠다 싶긴 하다. 대기업은 어떻게 일하려나? 이제 공채 교육이 끝나면 알 수 있을 것 같다. 이제 다시 신입이 되었는데 이번 팀에서도 배웠던 내용을 작 적용해서 빠르게 적응해봐야지.