짧지만 길었던 3주간의 스터디 회고
내가 입사한 11월 부터 1월 중순까지 우리팀은 스프린트기간이었다. 1-2달로 예상했던 스프린트가 3달까지 연장되면서 이건뭐 스프린트가 아니라 전속력 마라톤인가 라는 의문을 가지게 하였다. 그렇게 헥헥거리면서 달려오다. 1월 말부터 2월 두째주까지 숨고르기를 하는 스터디기간을 가지게 되었다.
내가 스터디한 항목
- css와 semantic tag
- 디자인패턴
- nest js
- mobx, nextjs 구멍난 지식 채우기
- typescript
- tdd + jest
css와 semantic tag
스터디를 하면서 가장 많이 성장했다고 생각하는 부분은 css+semantic tag 부분과, 디자인패턴이다.
회사에 오기전에는 나는 코드를 잘짜는 사람이 되어야겠다고 생각하여 css적인 부분은 뒷전에 두었다. 하지만 프론트엔드 개발자로 일하다 보니 프론트개발자의 업무에 있어서 css는 꽤나 중요한 요소임을 알게되었다. 큰회사에서는 전문 퍼블리싱을 담당하는 분이 따로 계시는 경우가 있지만 스타트업에는 모든 업무가 분업화 되기는 어려운 상황이기 때문에 보통은 프론트엔드 개발자가 퍼블리싱까지 담당하게 된다.
그러다보니 전문퍼블리셔가 아닌데다, 나의 가장 약점이 css였기에 웹사이트를 뼈대부터 만들어야하는 상황에서 나는 꽤나 짐이되는 개발자였다. 그래서 이번 스터디 기간때에는 꼭 css를 짚고 넘어가야겠다고 생각하였고, 반응형사이트 하나를 똑같이 스타일링하는 작업하였다.
직접 만들면서 css에 유용한 가상선택자들을 익히고, flex, grid를 다시한번 짚고넘어갔다. 막상 하고나면 그리 어렵지 않은데 왜이렇게 못했나 싶다. 하면서 html태그와 classname은 최대한 semantic하게 짜기위해 노력하였다.
이렇게 한번 훑고 나니 나의 소스코드가 부끄러워지기 시작했고, 한번 이렇게 알고나니 이제까지 왜 이런식으로 했지 하는 후회가 든다. 이런식으로 리팩토링 해가는 거겠지..?
디자인 패턴
디자인패턴은 우리제품팀의 공동목표였다.
지난 스프린트 기간 동안 우리팀은
다양한 디자인 패턴을 이용해서 사이트를 마이그레이션하였다. 프론트에서는 mvvm, command 패턴을 주로 사용해왔는데. 디자인패턴이란걸 처음접하다 보니, 뭣도모르고 그냥 사용해왔다.
디자인패턴 책의 시작점은 객체지향인데. 이또한 그저 객체를 주로 사용하는구나 정도로만 알고 그리 깊게 알지는 못했다.
객체지향과 디자인패턴을 공부한 결과 코드를 보는 시야가 굉장히 넓어졌다. 전반적으로 코드는 이런식으로 짜야하며, 이래야 버그가 적게생기는 구나라는걸 깨닫게 되었다. 클린코드를 짤려면 뭘 공부해야 하나 그저 짧고, 깔끔하게 짜면 되는걸까하는 의문도 풀리게 되었다.
클린코드는 곧 디자인패턴이었고, 리팩토링또한 디자인패턴에 기반하여 짜는것임을 깨닫게 되었다.
디자인패턴과 oop와 fp 각각 대한 철학들을 잘생각하면서 코드를 짜자.
팀의 가장 중요한 공동목표였던 tdd + jest는 50%의 목표만 달성했다고 말할 수 있을거 같다.
회사에 오기전 개인프로젝트에서 tdd+react testing library를 공부한 적이 있었다.
프론트의 테스트는 어떤방향으로 가져가야하는지 방향성을 알게된 시간이었다.
타입스크립트
타입스크립트 누가쉽다했어…
typescript의 t도 모른채 입사하자마자 타입스크립트를 써야했는데 벌써 4개월이 지났다.
지식의 깊이가 얕아 그동안 타입을 사용하다 막히면 그냥 다른 타입으로 주고 가장 기본적인, interface, type이런것들 밖에 모른채 돌려막기 하듯이 사용해왔다.
이번 스터디를 통해 내가 코드를 짜면서 발생했던 타입에러들을 어떻게 체킹해야하는지 조금씩 알아가게 되었고,
이또한 그동안 작성해온 나의 코드들이 모두 쓰레기처럼 느껴지고 빨리 리팩토링을 하고싶다.
but 아직 통달은 하지 못했다.
그동안 nextjs를 하면서 가장 어려웠던 점이 ssr이다. csr로만 프로젝트를 만들어 오다. ssr로 바뀌니 못보던 에러들이 생겨나고 어디서 왜 발생하는 에러들인지 혼란스러울 따름이었다.
따라서 ssr과 관련된, serverside props, hydration등에 대해 공부하였다. 사실 이 용어들이 명확하게 와닿지는 않지만 그래도 어디서 어떻게 왜 이오류가 나는지의 선에서 만족한다.
nest js
이또한 우리팀의 공동목표였고, 프론트와 백엔드 함께 공부하였다.
책으로 nest js을 공부하게 되었고, 처음으로 백엔드를 공부하는 기회였다.
사실 프론트도 공부할게 많은 나에게 nest까지 확실하게 가져가기에는 3주간의 기간이 너무 짧았다. 또한 다음 스프린트때 nest를 잘 이용하여 업무에 적용하는것? 또한 NO였기 때문에 빠르게 책을 1회독하고 지나갔다.
책을 보면서 배운점은 그동안은 백엔드가 어떻게 코드를 짜는지 정말 1도 몰랐더라면 이제는 아 이렇게 crud를 짜는구나 정도를 마음속으로 이해할수 있게 된거 같다.
nest는 뭔가 백엔드의 react같은 느낌이 아닐까 싶다.
리액트의 다양한 훅들이 개발을 편리하게 만들어 줬듯이 네스트의 다양한 데코레이터들이 존재한다. 그래서 더욱 개발을 편리하게 해주는 것이 아닐까 싶다.
오늘 있었던 팀회고에 대한 소감.
팀회고 시간에 각자 좋은점과 안좋았던 점을 말하라고 하셨고, 소통문제, 일정문제 등 다양한 이야기들이 나왔다. 하지만 대부분의 이야기들은 개발자들 개인의 능력이 부족하고, 기본기가 안되어있기 때문에 이런 문제가 발생한다로 귀결되었다.
현재 우리팀은 나를 포함한 팀내 대부분의 개발자들이 cto님의 인정을 받지 못하고 있는 상황이다. 프로젝트 초기 당시 cto님은 그냥 팀을 키우지 않고 본인이 혼자 프로젝트를 끝낸 뒤 팀을 키워야 했었나 후회한적이 있다고 하셨다.
이에 대한 내 생각은...
우선 1인분을 해내지 못하는 개발자로서 1인분은 거뜬히 해내는 개발자로 인정받기위해 더욱 노력해야 하는건 당연하다고 생각한다.
하지만 주니어니깐 부족한건 맞는데 주니어들로만 이루진 다른 개발팀도 이렇게 개발자들의 자존감을 깍아내리는 환경인가 라는 의문이 들었다.
주니어들이 생각외로 부족할 수 있지만 그렇다고 해서 팀내에서 발생하는 다양한 문제들이 모두 주니어라서,개발이 느려서, 발생한 문제로 치부되어서는 안된다고 생각한다.
이런상황에서 나의 자존감도 지키고, 회사에서 (cto한정 아님)인정받는 개발자로 성장하기 위해서는 어떻게 해야할까
이 문제에 대해서는 주말에 깊게 고민하는 시간을 가져야겠다.
