Gitbook을 이용한 Docs 작성

2024년 5월 23일 목요일

Today I Learned

날짜

2024년 5월 23일 목요일

내용

서비스 독스 작성

올해 회사에서 이룰 개인적인 목표 중 하나는 우리 팀의 서비스에 대한 Docs를 작성하는 것이다. 처음 계획은 어떤 기능이 어떤 함수, 어떤 파일에서 어떻게 데이터를 주고받는지를 기록하려고 했다. 내가 보기 위해서기도 하지만, 여러 사람이 협업하는 만큼 다른사람이 작성한 코드를 읽고 파악하는데 낭비되는 시간을 최소화하기 위해서였다. 문서를 작성하는 시간만큼 내가 코드 보는 눈도 좋아질 것이고..

조언과 여러 생각 끝에 방향을 틀어 기능과 흐름에 대해 작성하는 걸로 수정했다. 이렇게 되면 코드와 언어 자체에 대한 해석은 부족할지라도 전체적인 흐름을 파악할 수 있어 큰 그림의 이해가 더 쉽다. 또한 문서를 읽을 수 있는 사람이 개발자로 한정되지 않는다. 아주 약간, 조금의 짬이 차면서 기능을 개발하면서 생기는 고민은 코드 퀄리티나 방식에 대한 고민도 있지만, 지금은 에러가 나거나 로직상 구멍이 나서 유저가 원치않는 상황에 직면하게 되는 것을 더 걱정하게 되었다. 지금 시점에서 더 깔끔하고 근사한 코드를 짜는 사람보다는 계획 수준에서부터 그림을 그릴 줄 아는 개발자, 내가 들여야 할 공수와 시간을 정확하게 계산해 낼줄 아는 개발자가 되고 싶다.

앞으로 개발할, 혹은 이미 팀이 개발한 서비스를 총망라하는 문서를 작성하는 작업이 이에 도움이 되지 않을까? 우선 시범적으로 이번 스프린트에 개발한 기능에 대해 작성했다.

모르는체 안하고 알고 있기

오늘 문서를 작성하다가 로직에 구멍이 있다는 사실을 꺠달아버렸다. 프라이스 룰이 삭제되면, 이 룰로 만든 할인코드 들이 삭제된다. 이벤트가 수정되면서 고객의 쿠폰이 증발해버릴 수 있다. 이에 대해 해결책은 있으나 최선의 방식인지도 의문이고, 현재 공수에서 처리하기엔 일정이 촉박하다. 대신 문서에 적어둬서 향후 문제가 발생했을 때 바로 대비할 수 있도록 해놨다.

테스트 코드

pytest는 sqlite로 진행하는데, postgrsql 과 달리 jsonb 형식의 필드가 없다. 그래서 테스트가 불가능하기 떄문에, 별도로 생성해줘야 한다. 이번에 앱이 추가되면서 각 서비스를 활성화 할때 올바르게 데이터가 생성 및 수정되는지 확인하는 테스트 코드를 꼭 추가하고 싶은데, Factory로 관계도 잘 형성된 데이터를 만드는게 참 어렵다. 공부가 좀 필요할듯

회고

드디어 스프린트 하나 끝나간다.