[First Project] 개발 회고록_02

---

현황

오늘 기본적인 SR의 토대는 마무리되었다. API Documents, 스키마, 와이어프레임 등 문서 작업이 마무리되고 코드를 작성하기 위한 태스크 카드를 작성했다. 문서 작업을 모두 마무리하고 일정을 생각해보니 아무래도 이틀 내에 기본적인 코드 작업들은 모두 마무리하고 다음 주에는 시간이 좀 소요되는 어드밴스 작업에 포커싱 해야될 듯 하다. 처음에 일정이 2주라고 해서 평일 기준 10일의 시간이 주어진다고 생각했는데 10일 중 첫날은 팀 배정하고 인사하고 정신이 사실 별로 한 것이 없다. 그리고 마지막 날에는 발표가 있다. 아마 발표 전이라면 PPT 준비를 하면서 코드 작업을 하기가 사실 상 어려울 듯 하다. 그래서 최종적으로 온전히 프로젝트에만 신경쓸 수 있는 시간은 7일 뿐이다. ^^ 

 

그래서 오늘은 팀원들과 이에 관련한 이야기를 하고 기본적인 태스크들의 Due Date를 앞당겨서 잡았다. 최대한 앞당긴 Due Date에 맞추는 것을 목표로 프로젝트의 진행 속도를 높여야할 듯 하다.

 

회고점

API Document...

진짜 예상하지 못했지만 경험 부족이 크다고 느꼈고, 다른 API들을 참고하더라도 어떠한 기준으로 request의 parameter를 잡는 것이 바람직한지 감이 잘 생기지 않는다. response를 할 때의 내용도 감이 잡히질 않는다. 사실 API를 어떻게 작성하냐에 따라서 Back과 Front에서 투여되는 리소스가 편중될 수 있어서 어떠한 방식으로 API를 설정해야 비중이 유지될 수 있을 지가 고민되는 점이다. 그래서 우선 엔드포인트들만 설정을 해두고 적절한 request와 response는 앞으로 수시로 작성을 하기로 하였다.

 

Task Card 작성

기존에도 코드를 작성하면서 작성이 필요한 부분이 많은 경우 까먹지 않기 위해서 To do 형태로 작성을 한 경험은 다수 있다. 하지만 전체적인 진행 Task를 한번에 정리 해놓고 작업을 진행해본 적은 없는 듯하다. 그래서 오늘은 약간 Task를 러프하게 분류했다. 그리고 만약 Task의 양이 많은 경우라면 Card를 분리해서 Task를 나눌 수 있도록 팀원들과 이야기했다. 이 부분은 이번 한번 프로젝트를 진행해보면 분류하는 방식에 대한 감이 많이 생길 것으로 보인다.

 

Github에서 토글 작성

나는 노션을 사용하면서 마크다운의 문법 모습으로 많이 단축키를 활용해서 Github 마크다운에서도 노션과 동일한 형태로 토글을 쓸 수 있을 줄 알았다. 그런데 오늘 확인해보니 GitHub에서는 마크다운으로 토글을 활용하는 것이 불가능했다;;

 

HTML <details> 태그를 활용해서 토글 기능을 사용해야만 한다.

<details>
<summary>여기는 토글 버튼</summary>

- 토글 내용물 1
- 토글 내용물 2
</details>

위와 같이 작성하면 Github에서 토글 기능을 활성화할 수 있다. 그런데 인터넷에서 관련된 내용들을 확인해보고 있었는데 <div markdown= "1"> 태그를 <summay> 태그 종료 이후에 써주고 작성해야만 마크다운 문법으로 작성을 할 수 있다고 이야길 하고 있었다. 그런데 저 <div> 태그를 사용하지 않더라도 마크다운 문법이 적용되더라;;

 

그리고 가장 중요한 것은 <summary> 태그 아래 부분을 비워둬야 마크다운이 적용된다.