고민점

타켓 : 누구를 위한 것인가

신규서비스 및 앱으로 작업이 전환되어 웹뷰 작업 범위가 변경됨

이에 따라 신규 팀원이 투입된다면 온보딩 시 시간적 소요가 상당할 것으로 판단.

따라서 온보딩할 문서 필요성 느낌

문서화 하게 된 시점 : 개발 완료 후+ QA에 따라 수정 중

개발 중에 문서화 작업을 했다면 변경되는 디자인에 따라 문서화 작업으로 개발이 더뎌졌을 것이다.

( 예를들면 예약하기 화면에서 차량상세 섹션에 기존에 없던 부분적 조건에 따라 아이콘 추가 등 )

개발이 완료된 후 문서화를 하니 완성된 코드로 쉽게 문서화 틀을 정할 수 있었고, 집중하는 업무가 한 개 뿐이라 논의의 속도도 빨랐다.

1차완성본을 만들고 나니 QA이슈에 따라 문서수정도 용이해졌다.

왜 : 문서화를 하게 됬는가

• 기존 문서

내용 : 개요, 디자인 소스 url, 개발진행방식, 배포방식

→ Atom구조를 설명하여 레포에 대한 이해도가 높아짐

→ 배포방식이 작성되어 있어 내가 배포할때 수월했음

내가 겪은 문제점

1. 기존의 히스토리를 알 수 없어 어떤 페이지들이 웹뷰로 개발되어있고, 스프린트에서 웹뷰로 페이지들이 새로 작성 혹은 수정되어야 하는지 알 수 없었음

2. api가 뷰베이스에서 리소스 베이스로 (?) 변경되어 개발중에 어떤 페이지에서 어떤 api들이 사용되고 네이티브로 액션이 부여되는지 알 수 없었음

3. 서로 개발 페이지가 달라서 팀원이 부재시 보수가 불편함 (코드를 다시 보아야 하고, 다른사람이 쓴 코드를 수정하는 것이 어떤 사이드이펙트를 가져올지 모르기 때문에 알 수 없었음)

목적 : 무엇을 보여주고자 하는가

나의 목표 → 프론트엔드 개발자가 볼 것이니 페이지별로 정리하고싶다.

팀원의 목표 → api를 가져오는 순서로 보고싶다.

절충안 → 페이지별로 순서를 나누고 페이지의 섹션별로 api와 네이티브 액션을 넣자

따라서, 다음과 같이 목차를 나눌 수 있었다.

느낀점

서로 개발하지 않은 부분을 문서화 했다. 그러다보니 팝업같이 조건별로 다른 화면이 보이는 부분을 놓쳐서 서로 피드백해주기도 했고 서로가 어떤 작업을 했는지 정확히 알게되었다. 내가 개발하지 않은 부분의 QA 이슈가 온 경우 로직을 빠르게 이해할 수 있어 사이드 이펙트 없이 수월하게 이슈를 해결할 수 있었다.

더불어 개발을 떠나서 두 사람이 하나의 문서를 작업하다보니 다르게 얽혀있는 부분들이 있어서 통일성있는 문서가 되기위해 논의도 했다. 구두로 하는 소통과 텍스트로 하는 소통을 통해서 다른 방법을 소통할때 정확하게 의미전달을 하는 연습도 했다. (예를들어 텍스트의 경우 순서를 부여해 의견 전달, 구두의 경우 이미지를 그려가며 의미 전달 등)

TODO 논의

추후에 이슈를 해결할 경우 문서를 수정할 계획이다. 그렇다보니 PR 리뷰 논의가 이어지는데….