세 번쨰

2022.03.22 화요일
다들 와이어프레임과, api툴과 스키마와 나도 플로우 차트를 준비해왔습니다.
하지만 한 분이 오지않아서 두분에서 진행했습니다.
둘이서 이런 저런 애기를 나누는데, 똑같이 같은 느낌을 받았다는 걸 알 수 있었습니다.
어떤 느낌이냐면, 예상보다 사이즈카 커졌다는 것입니다!!

어떻게 해야할까?

예상보다 사이즈가 커져서, 어떻게 해야하나도 제가 준비한 질문 중에 하나였습니다. 기존의 와이어 프레임, UI로 드러나는 부분은 문제가 적었지만, 기술적인 부분이 문제였습니다. 기술적인 부분을 없애자고하니 기존에 준비했던 사이트의 정체성이 없어지고 클론코딩과 마찬가지여졌습니다.
그래서 결론내린게, 프론트엔드 수정할 부분을 수정하고 프론트엔드는 advanced사이즈로 백엔드는 base사이즈로 진행하기로 했습니다.
urclasss측에서는 기획을 최대한 하는게 좋다고 했지만, 수정하고 나면 또 하면서 수정하는게 나올꺼같아 코드를 작성하기로 했습니다! 그디어!

기획을..?

네! 저도 알고있습니다. 기획을 최대한 꼼꼼히 해야된다는 것 하지만 이렇게 결정내린 건, 그게 시간적으로 봤을 때 더 손해라고 판단했기 때문입니다. 그리고 first project니 오히려 그런 부분에서 에러가 난다면, 오히려 반면교사 삼을 수 있을꺼란 생각에 기획은 여기까지 마무리하는 걸로 했습니다.

느낀점

제가 준비한 플로우 차트에 아쉬움이 많이 남습니다. 클라이언트 측 흐름만 주로 기록하는게 됐는데, 다음에 한다면 클라이언트 서버 같이 세세하게 기록해보고 싶습니다. velog를 가지고 와서 같은 이미지를 공유하기 때문에 에러가 덜 날꺼라 생각하지만, 만약에 새로운 무언가를 만드는데 이런방식을 했다면 무조건 박살났을 꺼라 생각이 드네요.
아무튼 다음에 수정할 부분은 어떤 요청을 보내고 받아올건지 좀 더 구체화시키는 것입니다.

해야 할일

• kpt 회고
• 와이어프레임, 프로토타입, 플로우차트 확정
• 깃에 server, client 코드 작성

다음 회의 안건

• 로고 확인
• 위키 소개글 확인
• rich-text component
• 프론트 진행사항 확인
• 각 task 분배

피드백 스몰토크 후

스몰토크 후 결론을 말하자면...'다시'였습니다. 특히나 유용했던 부분은 API를 정리 할 때, 중복을 최대한 없앨 것, restful한지 점검할 것, 적합한 명령어인지 다시 생각해볼 것이었습니다.
코드만 지나가는 통로 정도로만 생각했다가 왕창 깨졌습니다.
그래서 플로우 차트를 없애고, 플로우차트와 와이어 프레임을 결합, 와이어프레임에서 흐름을 보여주고 와이어프레임을 더 발전시키는 쪽으로 방향을 잡았습니다.
그리고 스키마에서도 생각했지만, 스키마 만 봐서 사이트 흐름이 느껴져야한다고 하셔서 디테일하게 다시 수정하기로 했습니다.