0. 근황
- 일기쓰는 습관
- 8월 초에 글을 거의 쓰지 못했는데 반성하고 있다. 아주 적은 글이라도 조금씩 작성하면서 습관을 들여야 했는데 그것조차 쉽지 않았다. 당연히 게으름 때문.. 아직 일기를 쓴다는게 익숙치 않은 것 같다. 마치 운동을 하는 것 처럼. 최근 습관에 대한 책을 읽고 있는데 이를 기반으로 일기 쓰는 습관을 가지도록 노력해 볼 생각이다. 좋은 습관을 기르고 싶은데 자주 실패한다면, 습관의 힘을 잘 모르겠다 라고 생각하는 사람이라면 "아주 작은 습관의 힘" 매우 강추!
- 휴식
- 휴식이 너무 필요한 것 같아서 금, 월 휴가를 신청하고 3박 4일 괌으로 휴가를 다녀왔다. 가서 스노쿨링과 스쿠버다이빙을 배웠는데 너무 재미있었다. 다음 번 여행갈 때 스노쿨링 할 수 있는지 를 우선적으로 볼 것 같기도 하다. 추가로 회사에서 프리다이빙 하는 그룹이 있어서 해당 그룹에 들어가 취미로 발전까지 시켜볼까 생각중.. 우선 와인 자격증부터 따고!
1. 폴더구조 두 번째 논의
회사에서 폴더구조를 논의하고 있다고 이전에 적은 적이 있는데 이후 두 번째 논의를 했다. (논의를 한지 꽤 되었는데 정리를 최근에 했다.) 해당 논의를 하고 난 결론을 간단히 적어보려고 한다. 논의를 진행 할 때 네이버 클로바로 전부 녹음을 했고 논의가 끝난 후 모두 옮겨젹고 요약을 했다. 글을 적으면서 알게 된건 모두 생각이 다르다는 것 (물론 같은 생각을 한 것들도 많았다). 이렇게 논의를 여러번 해나가면서 좋은 결과를 만들길 기대한다.
1. 이랬으면 좋겠어
팀원 A
- 폴더구조에 대한 논의를 통일 시키지 않으면 앞으로 계속 혼란이 생길 것 같다.
- 한 사람이 다른 생각을 가지고 있으면 원레포로 작업하는게 오히려 고통이 더 따를 것 같다.
- 나중에 구분이 애매해지는게 별로
- 유지 보수성 측면에서 앞으로 의논을 최대한 덜 하는 방향으로 이야기 해보고 싶다.
[의견]
- 큰 단위의 통일을 시켜야 하는데 이걸 초반에 잡는게 현실적으로 힘들 것 같고 발생할 때마다 논의를 해야 한다.
팀원 B
- 나중에 혼란이 생기는게 별로다.
- common과 shared의 기준이 애매하지 않았으면 좋겠다.
[의견]
- 사람마다 다르게 생길만한 요소가 있는것들은 정해버리면 좋을 것 같다.
팀원 C
- common과 shared를 비즈니스 로직의 포함여부로 구분하고 애매한게 생기면 그때그때 이야기 해보자. 그게 많이 생기지는 않을 것 같다.
팀원 D
- 혼란스럽고 헷갈리는게 없었으면 좋겠다. (지금도 앞으로도)
[의견]
- 사람마다 생각이 다른 부분들이 존재하기에 이것들을 매번 논의하고 합의를 보기 보다는 그냥 이렇게 하자!로 정해버리면 좋을 것 같다.
2. 중간 정리
모두가 원하는거
- 모두가 생각이 일치하는, 동의하는 구조를 만들어야함.
- 기준을 애매하게 정해버리면 안됨.
- 앞으로 논의를 최대한 덜 하는 방향이 되어야함.
- 애매하게 정하면 혼란이 생겨서 매번 논의를 하고 고민을 하고 불필요한 논의만 많아짐
생각이 조금 다른거
- 팀원 B, D: 애매한게 아예 없어져 버리면 좋겠다. 그게 지금 당장 결정되었으면 좋겠 다. (지금 명확한 기준을 정해버리길 원함)
- 그래서 "애매한건 그냥 이렇게 해버리자! 정해버리면 애매한게 사라지고, 매번 고민하거나 논의할 필요가 없어지지 않을까?" 로 의견을 냄
- 애매한게 많이 생길 것을 우려함. 위에서 정의한 것들을 바탕으로는 논의를 많이 하더라도 애매한게 줄어들지 않을 것으로 생각함.
- 팀원 A, C: 애매한게 없어져야 하는건 동의한다. 지금 애매한걸 다 추려낼 수는 없을 것 같다. 애매한게 생각보다 많지 않을 것 같다. 애매한게 생기면 그 때 깊이 논의해보면 좋을 것 같다.
- 팀원 A: 애매한게 많이 있을 수는 있겠지만 점점 애매한게 줄어들 것이다.
- 팀원 C: 서로 생각하는 부분이 비슷할 꺼라고 생각한다. 그래서 애매한게 많이 없을 것이고 생기면 그 때 깊이 논의하면 점점 애매한게 줄어들 것이다.
3. shared, common 기준
1) shared
- page 내부에 있는 것들 중에서 다른 도메인에서도 사용되면 shared로 옮긴다.
- 여러 도메인에서 사용되는 것들 (component, util, hook, etc)
- 비즈니스 로직이 들어간 것
service
- 외부에 의존적인 것들을 모아둔 것.
- 외부 라이브러리를 한 번 wrapping 한 것
2) common
- 도메인, 비즈니스 로직들이 없는 것
4. 결론
- 매번 고민하지 않도록 shared에 기본적으로 만들고 shared에서 common으로 파일을 옮기거나 추상화 시킬 때 깊게 논의하고 고민해보자. 그러면 매번 고민해야할 부분이 많이 없어질 것이다.
여기까지가 회의 내용을 정리한 것 이고 이후 내 생각을 적어보자면
- common과 shared를 구분하는 가장 큰 기준이 비즈니스 로직이다. 비즈니스 로직이 없다면 무조껀 common에 넣으면 되는 건가? 명확한 기준이 아니라 느낌적으로 common에 넣을지 안넣을지 정해버리는 일도 생길 수 있지 않을까?
- -> 비즈니스 로직 말고 다른 기준은 필요 없는걸까?
- 저번 회의 때 비즈니스 로직을 가지고도 생각이 달랐었다.
- -> 비즈니스 로직에 대한 정의를 다 같이 내려봐도 좋지 않을까?
- common과 shared에 대한 기준을 더욱 명확히 정하지 않는다면 (누구나 동의할만한, 누구나 쉽게 구분할 수 있도록) 아무리 논의를 많이 하더라도 기준은 애매모호하게 계속 남을 것 같다.
- 음.. common과 shared를 구분하는 기준을 비즈니스 로직으로 잡은게 문제였던 것 같다. common과 shared를 구분하는건 자주 변하는것 vs 자주 변하지 않는것 으로 삼아야 한다. 비즈니스 로직이 common에 들어가면 안되는 이유는 비즈니스 로직이 포함된 것들은 자주 변하기 때문이다.
2. 문서화: 팀원 모두의 생산성을 끌어올리는 방법
문서화의 중요성에 대한 글을 읽었는데 매우 공감가는 말들이라 들고왔다.
문서는 지식을 전달하는 좋은 방법
- 개발자가 익숙하지 않은 특정작업을 수행하는 경우에 특히 중요함.
- 문서가 부족하면, 개발자가 작업 수행 방법을 스스로 연구해야 하고, 실수를 하고 작업을 다시 수행하거나, 다른 팀이 질문에 답변할때까지 기다려야 하므로 작업 속도가 느려질 수 있음
- 이는 1시간 짜리 작업을 금방 2일짜리 작업으로 만들 수 있음
- 100명의 개발자가 이 일을 해야한다면, 문서 한페이지 누락으로 인한 비용은 개발자 한명의 연간 급여에 해당할 수 있음
다른 모든 조건이 같다면, 관련 지식이 많은 개발자가 더 생산적임
- 코드가 어떻게 동작하는지 알기 때문에 코드를 깊게 들여다 볼 필요가 없고
- 도구를 사용하는 방법을 알고, 피해야하는 함정을 알고 있음
다른 팀들(네이티브 개발자, FE 코어 개발자)과의 컴이 많이 필요한 것들은 문 서화를 하지 않는다면 이후 다른 개발자들이 시간과 노력을 매우 많이 사용하게 될 것이다. 기존에 했던 논의, 버그, 검색등을 되풀이하는건 정말로 없어져야 한다. 문서화만 잘해도 엄청나게 많은 노력, 시간을 아낄 수 있지 않을까?
물론 스팩에 대한 문서화는 호불호가 있다. 매번 sync를 맞춰줘야하고 관리해줘야 하기에 불필요한 노동이기에 코드에 스팩을 녹이면 된다고 생각하는 사람도 있다.
물론 동의하는 부분도 있다. 하지만 그건 모든 팀원들이 해당 코드에 익숙할 때의 이야기다. 만약 다른 개발자(백엔드 개발자, 다른 프로젝트를 진행하며 코딩스타일이 완전히 다른 FE 개발자)의 경우에는 이해가 힘들 것이다. 코드에 히스토리를 남기게 되면 본인의 스타일로 만들 것이다. 하지만 문서는 누구나 알기 쉽게 쓰여야 하기 때문에 이는 안하느리만 못하다. 문서화를 굳이 할 필요가 없을만한 간단한 맥락, 특정 기능에 대한 히스토리는 주석으로 코멘트를 남기거나 해당 논의가 이루어졌던 스레드를 남겨보자.
하지만 특정 기능을 개발하면서 겪었던 트러블 슈팅이나 앱의 큰 기능에 대한 것들은 문서로 남겨야 한다. 게속 명세가 변한다면 sync를 맞춰야 하는 수고도 당연히 필요하다. 귀찮다는 이유로 이를 하지 않는다면 문제가 생겼을 때 항상 본인이 해결해야한다. 남들이 이 문제를 해결해주길 기대해서는 안된다. 해당 히스토리는 본인의 머릿속에 있고 다른 사람들이 이를 해결하기 위해서는 엄청나게 많은 시간이 소모될 것이며 본질적인 문제를 해결하는게 아닌 동작하도록 만 코드를 짤 것이 뻔하기 때문이다.