사실 1일차가 아니긴하다.. 벌써한 5일차쯤 되는거같다. 물론 1,2차 회의때 정해진내용도 은근히 있었다. 그덕에 타입스크립트를 공부하자던가
여러 의견이 오고갔고,
mysql+mongodb의 데이터베이스를 다루며
express.js 기반의 서버를 운영한다.
react.js와 redux,redux-toolkit등등. 스택선택부분에대해서 많이얘기를나눳다.
정해진건 거의 5일차쯔음 ?
에초에 프로젝트에 영입될즈음에 멤버를 구성하시는 프로젝트 기획멤버가 큰틀을 어느정도 잡고있엇고, 꽤 어려운 프로젝트이므로 4주차때 할것이 이미 큰그림이엿다, 그러다가 2주차때 약간 그기능중 일부를 구현하면서 공부해보는게 어떻겠냐는 얘기가 오고가고,
4주를 앵간치 사이트맵과 밑에 내용들을 준비하고했다.
Trollo 내용은 다만들고 편집됩니다.
Miro라는것을 처음 접해봤는데
협업툴로 이것만한게 없는거같다 (사실 아직 이거밖에 안써봤다.)
일단은 템플릿, 실시간 등 너무 좋았고
무엇보다. 사용법이 어렵지않앗다. 10분만에 앵간한 기능은 다 이해한다.
이작업을 4명이서 하는데, 사실처음엔 조금 헤맨감이 있엇다.
이 사이트맵을 처음그리면서 ( 라우트기준으로 한거같다 )
피그마로 각각 디자인하는부분이 있엇는데 이부분도 상당히 애먹엇다.
4주차 프로젝트를 기준으로 하는데, 아무래도 방대하다보니, 처음에 이슈가좀 있긴했다.
1920 과 1440의 문제였다.
나는 1440을 뭔가 요즘 그정도는쓰니까 그기준에 맞춰야한다고 생각했는데
이게 통상 1440p라고 부르는것은 2500?몇X 1440에서 뒤에꺼를 얘기하는것인데
앞에 숫자로 1440으로 착각한거같다.
실사이즈와 해상도는 다른데, 좀 이런분야를 다들 모르니까 약간의 트러블 ?이있엇느데
일단 1920을 기준으로 했다. 크게 디자인하고, 작은화면에서 보여지는것을뭐
flex-flow? 그 넘치면 알아서 다음줄로 가게하는거 그런거도 있고하니까 잘될꺼같다.
사실프론트의 문제긴하다.
그리고 디자인에대해서 많이얘기를나눳는데
이날 저녁쯤 나온얘기가, 한것이 많기는하지만, 들인 시간에 비해서 뭔가 더 효율적이지 못했던거같다는 얘기가 나왓엇다.
당연히 쉬는시간도 언급이있엇고, 휴일도 언급이있엇고, 하루에 몇시에 마감을할것인지도 이때쯤 정해졌다.
스키마 디자인으로 바로 달려가보려고했는데
중간에 기능프로세스를 어느정도 해야 스키마가 보인다고 해서 이과정을 꼭 했다.
하는거자체는 금방했지만, 중간중간 이해를 많이해야했다. 즉 , 하나의 기능들만 쭉쭉 뽑아서
약간의 프로세싱을 정리해서 보면
필요한 Db의 모양이 디테일해진다.
위에 기능프로세스를 한번하고나니 스키마디자인이 조금 널널했다.
workbench를 사용했고, 꽤나 단순하게 디자인이 완성되엇다.
N:M은 두개정도 나왓으며,
nosql을 섞어서 쓸것을 고려하여서 메모로 약간의 표시만해두었다.
사실 mysql과 mongodb를 섞어쓰는부분이 좀 걱정은되는데,
잘안돼면 그나마 강점인 mysql로 가는게 맞는거같다.
몽구스도 꼭 잘다뤄보고싶다.
유저의 완전 유저스럽게 시작해서 흘러가보는 화살표로 따라가는
플로우차트를 그리고나니,
어디서 에러처리를 이런것을 해줘야겠다,
어디서 어떤 처리가 가능해야하겠다.
유저가 느끼는것도 어느정도 그려지고,
물론 이과정을 하더라도, 직접 테스트해보면 불편함이 감지될꺼같다.
그래도 도식화가 제일 중요한거같다.
ㅇ위에 과정들도 결국에
어떤 데이터들, 이미지들, 디자인들, 흐름들을 사람이 보기좋게
개발자가 보기좋게 만드는 초반과정, 이후 헷갈리거나, 우리는 그래도 아직
초보 개발자 수준의 작은 프로젝트라서 머리속에 다 집어넣는게 가능할수도 있지만.
점점 커지면 그거는 힘들어질꺼같다. 그러므로 공식문서처럼,
진짜 공식문서처럼이 핵심인거같다. 각 사용법과 그 원리를 적어놓은 문서
그것을 이해하기 쉽게 도식화해놓는과정을 미리해두면
추후 코딩과 기능구현단계에서 , 다같이 모여서 이부분 어떻게하죠? 라는
허무맹랑한 미팅을 줄일수있는거같다.
모여야할이유는 꼭 중요한 사안, 미처 생각하지 못한 사안일때 다같이 생각해보는것이지
위처럼 어느정도 도식화로 해결될 부분은 꼭 해야한다는 느낌이 강하게 확신이됬다.
플로우 차트도 결국 미로에 작성하였고, 화살표 기능이랑 좋았다.
팀원중에 디자인적감각이나, 잘 꾸미시는분 계시면 좋다.
심플해진다.
그런사람이 없으면
화살표가 춤추고, 꾸불대는 괴상한 모양이나온다.
처음에 내가해보니까 고래같은게 그려졌다.
이부분은 Postman이라는 프로그램으로 작성해서 공유해봣다. (퍼블리시)
보니까 팀원 초대기능도있어서 오 이거로 초대해야지 했는데
무료 플랜에서는 나포함 팀원이 4명이 안되는거같다.
맥시멈 팀원 뜨더라 ...
그냥 퍼블리싱하고 링크줘서 보는게맞느거같다.
직접적으로 편집권한은 백엔드 맡은사람이랑만 에딧권한 가지면 되는거같다.
여기도 조금 고생했는데
분면 위 과정에서 생각할때는 잘 될거같고 이렇게하면 될꺼같앗는데
막상 문서화 하려고보니
빈틈투성이다.
그부분을 잘 기록해서
최대한 프론트엔드가 그걸 읽과 어렵지않게 api요청을 할수있게 만들었다.
오늘의 회고는 여기까지이고,
약간의 배포환경조성과 git을 서로 나눠서 조금 해보고
오늘은 마무리 될꺼같단 생각이든다.