https://www.youtube.com/watch?v=mlbSfpVu_sA&feature=youtu.be&ab_channel=_X
폴
개발에 필요한 화면을 잘 구현했기 때문에 시간 대비 잘했다고 생각합니다.
하정
팀장 님이 뼈대를 잘 잡아 주셔서, 개발을 순조롭게 할 수 있었다고 생각합니다.
정은
저는 기획적으로만 치중되어 있고 개발에 대한 부분은 미흡 했던 것 같아요. 디자인에 너무 몰입했었고요. 사실 사이트맵이 컴포넌트 구조도와 관련이 있었는데, 라우팅까지만 고려하고 그 부분은 마무리 후에 깨달은 것 같아요. 다음에는 컴포넌트 구조도를 별도로 제작하는 게 어떨까요?
시영
아토믹으로 시작해서 상위의 state 관리를 파악하기 힘들었어요. 각각의 컴포넌트를 어떻게 이용해야했는지 세밀한 논의가 필요했습니다. 나중에 state 넣으니 에러가....ㅠㅠ
폴
정은님이 토대를 잘 만들어주시지 않았다면 진행이 어려웠을 것
시영
스토리보드와 피그마는 기획단에 대한 이야기지, 개발자는 다른 문서를 작성하지 않을까요?
폴
정은
폴
시영
피그마가 대체적으로 쓰인다고 합니다.
보통은 스토리보드를 맨 처음에 작성하는것으로 알아요. 그리고 디자이너와 개발자들이 스토리보드 피드백을 하고 수정하는 방향으로요. 피그마를 어떻게 하는지 공부하면 작업 속도가 빨라지지 않을까요? 레이어가 뒤죽박죽이어서 나중에 이미지 추출하는데 힘들었었네요. 피그마와 스토리북을 연동시켜 사용하는 방법도 있다고도 하고요.
피그마를 너무 중구난방으로 사용했습니다. 디자인 가이드라인의 기능은 못했던 것 같습니다.
기업들이 제공하는 디자인 가이드를 참고하면 어떨까요. 컴포넌트 디자인 단계에서도 메테리얼 UI나 차크라UI 참고하면 좋을 거 같습니다.
정은
시영
하정
폴
정은
폴
API document를 만들긴 했지만 실제론 참조를 하지 않았다. Firebase를 사용해서 그랬던것 같기도 해요. 필요한 api를 client에서 만들어 쓸 수 있었으니까요.
너무 공부를 하면서 바로바로 습득해야 할 게 많았어요(맞아맞아) 정형화된 API가 없고 체계가 없다보니까 소통을 다르게 했었죠. NOSQL이라는 새로운 체계를 배우다보니 서툴렀던 것 같습니다. 다음번에는 정형화된 툴을 써보고 싶다는 생각을 했요. 파이어베이스를 더 잘 이해하기 위해서요.
뭘 반환하고 뭘 찾아야 하는지 에러 처리에 대한 목적성이 없었습니다. 파이어베이스를 사용한 사람들이 경력이 있었던 사람들일텐데, 문서 자체가 이해를 전제한 사람을 타겟으로 정해져있다고 생각해요. 공식 문서 이해하기가 쉽지 않았어요. 마법이 있는데 쓰는 방법을 몰랐죠... 머글이 된 느낌. firebase 정형화된 것은 없고 거의 프론트엔드의 영역 같았어요.
파이어베이스가 스택오버플로우에도 활성화되지 않아서 리서치하기 힘들었습니다. TypeOrm 추구하는 방향과 쓰는 방법이 정형화되어 있어서 쓰기 좋았는데 파이어베이스는 그런 게 없었어요. 개인적으로는 일반적인 서버를 만들어보면 오히려 좋지 않을까 싶습니다.
아직은 우리가 파이어 베이스를 사용한 방식에 대해 맞고 틀린지 판단하기 어려운 것 같습니다. 공식 문서가 초보자가 이해하기엔 추상화가 심하고 구체적인 설명이 부족했어요. 그래도, 서버리스 서비스가 간단한 앱을 만들기 적합했던 건 사실이었던 것 같아요.
방법론을 알고 있어야 자유로운 툴을 주었을 때 잘 사용할 수 있겠네요.
정은
폴빈
시영
폴빈
하정
돌이켜보면 너무 제 기준만으로 적었던 것 같네요. 다같이 익숙한 룰이 있어야 따르기 쉬운데 합의가 없어서 더 어렵지 않았나요.. 의도를 충분하게 설명해야 했는데, 사전에 전달이 부족했었죠.
저는 반대입니다. 저는 그 틀이 없었다면 아예 시작도 못했을 것. 이 룰은 절대 지켜질 수는 없지만 왜 이렇게 하자고 했는지 룰의 중요성을 깨닫게 되었습니다.
코드 규칙은 나름 체계적으로 만들었던것 같아요. 시간이 없었을 뿐. 에러핸들링을 하면서 봤는데 잘 지켜졌다고 생각합니다.
변수, 함수, 주석 등등에 대한 합의가 없었죠.중구난방 하다 가독성을 놓쳐서 에러가 많았던 것 같아요. 그런 걸 통일하면 좋을 것 같아요.