😖 느슨한 생각은 개발에 해를 준다.
집중하지 못했던 시간을 제외하고 작업을 진행하게 된 지 약 2~3주 정도가 지난 것 같다.
기본 요소 이후로 어느 정도 뼈대가 잡아지긴 했지만, 하다 보니까 크게 반성하게 되었던 부분이 몇 가지 있었는데 가장 컸던 건 ‘느슨하게 생각’했다는 점이었다.
지난 번, 웨잇세컨드는 사실 제안서 정도의 기획을 만들어두고, 직접 레퍼런스도 찾아보면서 케이스를 연구하고 했었는데 이번 프로젝트는 그 정도까지 하진 않았다.
심지어 브랜치 전략이니, 이슈 관리니 다 이것저것 해놓고서는 이번 프로젝트는 전혀 그러지 않다 보니까 작업하면서 너무 허술하게 만들고 있다는 걸 깨달았다.
이러다 보니 작업의 진도가 나가지 못하고, 헤메는 것도 발생하니까 이 상태로는 안되겠다는 판단이 섰다.
결국, 반성을 하고 노션을 켜서 작업 순서를 다시금 정리하면서 우선 순위를 나름대로 정리해봤는데..
개발 측면에서 보니까 반성해야 할 점이 많이 나왔다..🤦
- 라우팅 방식을 막무가내로 적어서 Restful하게 가지 않았다는 점
- 그로 인해 변경하면서 폴더 구조도 다시 고민해야 한다는 점
- 커밋 규칙도 제대로 생각해두지 않아 작성할 때마다 어떻게 써야할지 헤메는 점
- 어떤 일을 하고 있는지 제대로 관리하지 않아서 작업 순서를 헤메게 되거나 놓치게 된다는 점
이러다 보니 정말 답이 없다는 게 판단되면서 개발 과정을 멈추고 규격화 작업을 하기 시작했다.
PR과 이슈 템플릿을 생성하고, 라벨링을 수정하고, 태스킹을 위해서 Github Project를 생성하고.. API를 쓰진 않지만 Firebase의 모듈을 API에 빗댄다고 생각하면서 API 문서도 만들고..
덕분에 하면 할 수록 프로젝트 작업을 어떤 식으로 해야할지 가닥이 잡혔다.
이번 글에서는 위에서 언급한 프로젝트의 기초 작업 변경 사항들을 서술하고, 다음 편에서는 저번처럼 구현하면서 겪었던 사항들이나 생각했던 사항들을 기록하고자 한다.
✍️ 최약 개발자는 API 문서 만드는 여행을 시작했습니다
기존에는 컴포넌트명에 맞춰 path명을 동일하게 하는 식으로 진행했었는데, 최근 토이 프로젝트를 같이 하는 담 님(@herb1401)께서 왜 path가 RESTful한 방식으로 짜여지지 않았냐고 물음을 던졌다.
서버를 직접 만들지 않고 서버리스 SDK를 이용하는 개인 프로젝트이다 보니 해당 부분에 대해서는 고려하지도 않았고, 그러다보니 path도 컴포넌트명에 맞춰서 의미가 동일하면 좋겠다 싶어 통일한 거였는데, 그 말을 듣고 담 님이 이건 아닌 것 같다면서 백엔드랑 소통하면서 앞으로 일할 걸 생각하면 path는 RESTful하게 짜야한다고 말했다.
사실 백엔드가 없는 프로젝트라서 그럴 필요가 있나 싶기도 했지만, API는 백엔드와 프론트의 의사소통 창구라는 것에는 이견이 없었기 때문에 그 말에 수긍하고 고민 끝에 path를 RESTFul하게 바꾸도록 라우팅을 조정해 아래와 같이 수정했다.
단일 path에 대해서는 단수의 명칭을 쓰고, 부가적인 routes들이 있다면 이건 복수의 명칭을 쓴 뒤 따로 페이지를 분리했다.
그리고 이 과정 속에서 path만 나누는 걸로 끝나는 게 아니라 어찌됐든 API와 연동한다는 가정 하에 이렇게 만든 만큼 각 API가 어떠한 역할을 가지고 어떤 작업을 진행하는지 API 문서를 만들 필요가 있겠다 싶었다.
그래서 아래와 같이 노션에 데이터베이스를 이용해 API 문서 작업을 진행했다.
실제 백엔드 API는 없기 때문에 그 대신 어떤 모듈을 이용해서 통신을 하고 있는지 그 내용들을 정리했는데, 덕분에 Firebase의 각 모듈들이 어떤 일을 위해서 쓰이는지 파악하기도 쉬웠고 저장하고자 하는 값들을 어떻게 보내야할지 타입 정리를 하기도 수월해졌다.
우선 문서 자체는 현재 구현한 데까지만 작업되어 있다보니 허전한 것도 있고, 받아오는 Response도 정리가 다 되진 않았지만 그래도 역시.. 없는 것보다 낫고, 지속적으로 갱신 작업도 할 수 있도록 노력하고자 한다.
🚅 path가 이끄는 폴더 구조 변경 여행
컴포넌트명과 path명이 동일한 구조로 가는 식으로 만들다보니까, 폴더 구조도 이에 맞춰서 변경해야겠다고 생각했다.
하지만 path에 맞춰서 하자니 Next.js의 라우팅 방식과 동일하게 만들어질 것 같고.. (사실 이 방식은 자칫 폴더를 계속 타고 들어가는 구조가 될 수도 있기에 선호하지 않았다(….))
지금의 폴더 구조를 크게 바꾸지 않는 방법은 무엇이 있을까? 하면서 몇 시간을 고민했는데 결론은 상위 디렉토리를 바꾸는 것으로 끝냈다.
src ├─ App.css ├─ App.tsx ├─ common │ ├─ components │ ├─ policies │ ├─ styles │ ├─ types │ └─ utils ├─ layout │ └─ styles ├─ pages │ ├─ lists-create │ │ ├─ atoms │ │ ├─ components │ │ ├─ policies │ │ ├─ styles │ │ ├─ types │ │ └─ utils
기존에는 컴포넌트명에 맞춰 폴더명도 path도 전부 맞춰는데 이번에 path가 변경되면서 상위 디렉토리와 컴포넌트명도 path에 맞춰서 변경했다.
예를 들어 /lists/create 라는 path가 있다면 상위 디렉토리를 lists-create로 명칭을 바꿨고, 컴포넌트명도 ListsCreate로 변경했다.
굳이 이렇게 할 필요가 있겠나 싶겠지만, 컴포넌트명-폴더명-path명을 통일화하는 게 보기에도 관리하기에도 좋겠다는 단순한 이유여서 이렇게 했다.
⏳ 공주님, “문서화”의 시간입니다
여기까지 하고, 다시 작업하려고 코드를 보니 미묘한 기분이 들어서 여태까지 만든 것들을 훑어봤다.
코드에 대한 통일성도 제대로 없고, 브랜치도 뭔가 미묘하고, 커밋 규칙도 중구난방에, PR도 어떻게 써야할지 제대로 생각도 안해~
결국 내 코드가 이 모양 이 꼴인 이유가 왜인지 알겠다 싶었다(…)
이대로 괜찮은걸까? 어차피 제대로 한다면 확실하게 잡는게 좋지 않을까? 그런 생각을 하니 ‘개발 문화’에 진심이라고 말하는 내가 개인 프로젝트를 중구난방으로 하는 것은 왠지 모순됐다는 생각이 들었다.
그래서 결국 코드를 다시 내려놓고 여태까지 한 것을 기반으로, 그리고 앞으로의 업무 작업을 고려해서 어떻게 진행할 것인지 문서화를 하기 시작했다.
크게 PR을 어떻게 올려야 하는지, 업무 진행은 어떤 식으로 관리할지, 그리고 코드를 짤 때는 어떤 것들을 지켜야할지, 또 라벨링은 뭘 할지… 이런 것들을 정리하다 보니 아래와 같이 문서 작업을 완료했다.
코드 컨벤션은 특히 Toast UI의 코드 컨벤션과 AirBnb의 코드 컨벤션 문서를 보고 거의 복붙하듯이 하면서 만든 거지만, 그래도 이렇게 하고 나니까 코드를 짤 때 스스로 아! 하고 이렇게 짰어야 했지 하면서 경각심을 가지면서 작업을 하게 되었다.
문서 후에는 코드 컨벤션에 맞춰서 전반적으로 코드 통일화 작업을 진행했는데, 그러다보니 내 코드가 진짜 중구난방이었구나 싶기도 했었고 하면서도 변수나 함수명의 의미가 제대로 된 의미였나 싶은 것들도 있어서 이 과정 속에서 폴더 구조 내 유틸 폴더를 더 확장했다.
정말 조건만 체크하는 boolean으로만 return 하는 함수를 policies에 남기고, 인자를 통해서 다른 값으로 return하는 함수를 convert로 명칭한 뒤 utils 폴더로 옮겼다.
사실 이렇게 하는 과정에서 전반적인 구조 변경이다 보니 브랜치를 분리하고 작업했어야 했지만(…) 문서화하면서 변경도 계속하다 보니까 차마 그러지 못했는데 다음 태스크부터는 또 이렇게 크게 변경할 일이 있으면 브랜치를 분리하고 태스크를 만들어서 작업할 수 있도록 신경쓰고자 한다.
📏 어리석은 개발자는 템플릿과 춤춘다
위에서 문서들을 만든 것을 보니, 그냥 문서만으로 두지 않고 이걸 기반으로 Github에서 템플릿을 등록하고 이용할 수 있는 기능이 있지 않을까?
어떤 내용들을 작업했는지, 그리고 구현해서 어떤 결과를 보여주고자 했는지 기록하는 것은 매우 중요하므로 템플릿화를 시도하고 싶었는데 때마침 아래의 링크를 발견해, 덕분에 Pull Request와 Issue 템플릿을 만들었다.
리포지토리에 대한 끌어오기 요청 템플릿 만들기 - GitHub Docs
리포지토리에 대한 문제 템플릿 구성 - GitHub Docs
템플릿을 이용하려면 템플릿 마크다운 파일이 반드시 main 혹은 가장 앞 단의 브랜치에 있어야 한다. 그렇지 않으면 템플릿을 불러오지 못하니, 만들고자 하는 사람은 주의하자.
현재 구현된 템플릿은 아래와 같다.
이 정도까지 하니까 이제야 프로젝트를 프로젝트 답게 처리하고 있다는 생각이 든다..
하지만, 여기까지 했어도 뭔가 허전하다 싶었으니.. 바로 Task Management가 빠져있었다.
🗃️ 내 마음의 위험한 Github Project
이전 프로젝트인 웨잇세컨드는 Github Project를 진행했었다.
사실 유용하긴 했어도 Github Project 자체의 기능은 아쉬운 점이 많았는데 1년이 지난 지금 다시 사용해보니 프로젝트를 만드는 방식이 다양해지고 기능도 많이 생겨났다.
이번 프로젝트에서는 Project를 두 개 쓰기로 했다. 하나는 Task 용도로 쓰이는 거고, 다른 하나는 버그 트래킹 용도로 쓰기로 했다.
아, 그러고보니 Jira나 Asana, Trello와 같은 툴을 배제하고 왜 Github Project를 썼는지에 대해서 이야기를 덧붙이자면 Task든 Bug든 되도록 일을 처리하려면 원툴로 이걸 전부 관리하고 싶었다.
웨잇세컨드 때도 그 과정에서 발견한 게 이 Github Project였고, 동일한 이유 + 기능이 다양해짐에 따라 더욱더 써도 나쁘지 않겠다 싶어서 이 툴을 택했다.
정말 작년보다 Github Project의 기능도 늘어나고, 이렇게 양식도 늘어난 덕분에 사용성이 오르니 정말 좋은데 아쉬운 건 Project에서 생성한 Task에 템플릿이 제공되지 않는 점이었다.
아쉽긴 하지만, 반대로 이슈를 등록하고 Project에 연동한다면 그건 템플릿에 맞게 될 것…같은데 나중에 확인해봐야겠다.
아무튼 이런 식으로 문서화부터 코드 및 폴더 구조 수정, 그리고 템플릿화와 태스킹 관리까지 온갖 집중력을 쏟아부으며 업무 효율을 높이기 위한 작업을 진행했다.
💦 나의 문서화는 일입니다!
근데.. 이렇게 하면서도 아직도 남은 게 있다.
README.md도 일단 수정했지만 지속적으로 관리해야 하고, 기술 선정 이유에 대해서도 써보고, DB 구조에 대해서도 어떤 데이터들을 관리하고 있는지 정리해봐야하고..
그 밖에도 사실 디자인 문서에도 어떤 기능이 부족하고 추가해야 하는지 생각 정리를 해야하는데, 애초에 그게 원인이어서 시작한 일인데 그거를 안했다ㅋㅋㅋ….
프로젝트를 시작하면서 이 문제를 깨닫기까지의 과정을 보니 정말 입개발하고 있었구나 싶기도 하고.. 많은 반성을 했다.
사실, 여기까지 했다고 해서 지금은 입개발 아니냐고 하면 할 말이 없긴 한데, 그래도 이제서라도 이렇게 깨닫고 규격화한 건 정말 다행이라고 생각하고, 한편으로 개발 문화를 중요하게 생각한다고 스스로 말했으면서 개인 프로젝트는 날로 먹으려고 하니, 이거는… 돌이켜보면 반성해야 한다..^^
물론 이거 한다고 개발 실력이 오르는 것도 아니고, 잘 하게 된다고 생각되지도 않는다. 하지만, 적어도 개발할 때 어떤 점을 의식하면서 개발할지, 그리고 혼자 일하든, 협업을 하든 그 과정 속에서도 내가 어떤 것들을 고려하면서 일할지를 할 수 있다는 점에서 이렇게 한 것에 의의가 있다고 생각한다.
마지막으로 궁금한 사람들을 위해 Task를 관리하고 있는 Github Project와 레포지토리, 그리고 프로젝트 문서 링크를 아래에 남겨놓으며 다음 글에서 또 뵙도록 하겠다.
GitHub Project: project-elements-tasks
GitHub - DrunkenNeoguri/project-elements
준비물 챙겼어? - 여행 준비를 돕는 가벼운 내 친구 | Notion
Wir sehen uns!
🔖 참고 자료
리포지토리에 대한 문제 템플릿 구성 - GitHub Docs
리포지토리에 대한 끌어오기 요청 템플릿 만들기 - GitHub Docs
GitHub - airbnb/javascript: JavaScript Style Guide
GitHub - tipjs/javascript-style-guide: Airbnb JavaScript 스타일 가이드 한국어
