✏240221 수요일 TIL(Today I learned) 오늘 배운 것 ~
✏240227 화요일 TIL(Today I learned) 오늘 배운 것
📖디자인 작업
수,목,금,토요일 :
- 기획에 이어서 디자인도 직접하게 되었다. 이번 프로젝트에는 디자이너 튜터님이 따로 시간을 내셔서 피드백을 주시는 시간이 있다.
- 우리는 미리 작성해 둔 UI틀에 가까운 와이어 프레임을 바탕으로 실제로 제공되는 어플들의 레퍼런스를 모아 필요한 부분들을 완성해나갔다.
- 디자인 튜터님도, 이미 서비스하고 있는 어플들의 장점을 따와서 화면을 구성하는 것은 문제가 있는 것이 아니고 오히려 사용자의 실사용 면에서 유용함을 입증한 디자인이기 때문에 최대한 고려하는 것이 좋다고 해주셨다.
- 이외에도 디자인 튜터님의 피드백을 모아보자면 아래와 같다.
- 그림자 같은 것은 함부로 쓰면 금방 촌스러워질 수 있다.
- 색감은 화사한 것을 고르는 것이 좋다
- 특별히 강조되어야할 정보가 아니면 흰배경에 까만글씨로 텍스트를 전달하는 것이 좋다고 생각한다.
- 각 페이지 용도에 맞는 디자인을 해주는 것이 좋다.
(ex.정보를 제공하기 위해서라면 그 정보를 충분히 보여줄 수 있다던가, 게시판 처럼 슥슥 훑고 지나갈 아이템들은 적당히 여유있는 패딩과 마진으로 피로도를 덜어야한다던가)
📖깃허브 세팅
월요일 :
- SA작성을 마무리하면서, 깃허브 Organization 세팅과 더불어 기본 환경을 세팅했다. 빌드 버전들과 안드로이드스튜디오 환경 세팅과 더불어서 본격적인 코드 작업에 들어가기 전에 Color, 이미지 아이콘, 폰트 등 필요한 재료들도 추가해 두었다.
- 이렇게 세팅한 것들을 커밋하면서, 한 번 더 커밋 컨벤션을 제대로 맞추고 풀리퀘스트 시 컨벤션도 맞춰보았다. 이번에 스쿼시머지라는 것을 처음 들어봤는데
다수의 커밋을 단일 커밋으로 압축하여 풀리퀘스트를 깔끔하게 유지하는 방법이라고 한다. 우리 팀은 이번에 스쿼시 머지로 히스토리 관리를 하기로 했다. 마지막 포트폴리오 이기 때문에 깃허브관리도 신경써서 해야겠다.
📖DB작업 with FireBase
수요일 : [DB구성정리]
- 사실은 수요일에 디자인 작업을 시작하기 전, 와이어 프레임을 구성한 후 부터 DB 작업을 했는데, 아무래도 로컬 데이터 만으로는 제공할 수 없는 게시판, 채팅 등을 포함하여 외부 데이터베이스를 바탕으로 데이터를 뿌려주는게 효율적이라는 의견이 나와서, 우선은 데이터베이스에서 관리해야할 데이터들이 뭐가 있는지 구성부터 했다.
- 각 페이지마다 제공되어야할 정보들이 뭐가 있는지 확인하고, 어떻게 관리할지, 어떤 키로 연결될지 등을 정리했다.
- 사실 디자이너 튜터님의 피드백에 따라 제공되는 정보가 좀 바뀌기도 하고, 우리끼리 의논을해서 재구성한 페이지들이 있기 때문에 초반에 잡아 놓은 DB 구성에서 디자인이 완성되고 다시 한 번 검증을 통해 필요한 정보들을 정리했다.
월,화요일 : [FireBase]
-
이렇게 정리한 데이터들을 바탕으로 우리는
FireBase를 사용하기로 했다.
FireBase에서는 구글에서 제공하는 간편로그인 관리부터, 채팅이나 게시판 같은 실시간 데이터들의 동기화를Realtime Database로 제공하고, 이에 대한 알림도FCM(Firebase Cloud Messaging)으로 쉽게 관리할 수 있는 등 애플리케이션 구축 및 운영 등에서 다양하고 효율적으로 활용되는 플랫폼이다. -
이번에 만드는 어플에서 우리가 원하는 모습으로 데이터를 가공하여 제공하기 위해서, 공공데이터 포털에서 제공해주는 api 데이터를 데이터베이스에 보관하여 사용하는 방법을 먼저 고려했기 때문에, 제일 많이 언급된
Realtime Database에 JSON 데이터를 집어 넣어 보기로 했다.Realtime Database는 JSON 트리 구조를 사용하여 데이터를 저장하기 때문에 CLI 등을 사용하여 쉽게 데이터를 업로드 할 수 있었다.
=> 문제는.. 업로드한 데이터에서 우리가 원하는 조건으로 데이터를 가져오는 것이 상당히 제한적이라는 것이다.Realtime Database에서는 쿼리지원을 정렬 정도로만 지원하고 복잡한 쿼리는 지원하지 않기 때문에, 구현하려고 하는 검색 기능이나, 조건에 맞는 데이터만 뿌려주는 것을 하기에 적합하지 않았다.
=> 그래서FireStore를 사용하기로 했는데,FireStore에는 Json 파일을 올리는게 쉽지 않았다. 하나 하나 넣는 방법은 많은데Realtime Database에서 처럼 CLI를 사용해서 올리는 것이 되지 않았다. 결국엔 팀장님이 node.js를 통해서 해결해주셨는데, 결제 계정 이야기와 더불어서 개인적으로 해결하기에 소극적인 부분이 아쉬웠어서 나중에 개인적으로 프로젝트를 진행할 때에는 좀 더 적극적으로 시도해봐야겠다.
✏ 느낀 점
-
사실 디자인을 할 때 시간이 너무 오래 걸렸다. 팀원분들도 다들 모르는 분야이고, 그렇다고 무시하기엔 서비스 제공 시에 보여지는 화면이 얼마나 중요한지 알아서, 최대한 모든 의견을 들어보고 좋은 것을 반영하려고 하다보니 제공된 시간에서 너무 많은 부분을 디자인에 할애해버렸다. 그래도 다같이 회고를 통해 원인을 파악하고 해결하기 위한 방안들을 이야기하는 시간을 통해 개선할 수 있는 시간이 있었어서 매번 정리하고 회고하는 시간이 중요하다는 것을 깨달았다.
-
나는 이전 프로젝트 때 매번 디자인을 후순위로 놓고 작업을 했어서, 이번에 이렇게 디자인을 먼저 고려하는 순위로 작업을 진행하는 것이 상당히 새롭게 느껴졌다. 그리고 내가 왜 여태 했던 프로젝트 들은 디자인이 단조로울 수 밖에 없는지 깨달았다. 이미 코드를 작성해서 기능을 완성해 버리면 그거에 맞춰서 겉 껍데기 색깔만 바꿔줄 뿐, 1열 수직 리니어레이아웃을 수평 2열 그리드로 배정해주거나 하는 문제는 시간이 오래걸리기 때문에 이번 프로젝트 처럼 미리 모양을 잡는 것이 상당히 중요하다는 것을 깨달았다. 그러고 보면 심화 수업 때 앱개발 프로세스에 대해 배울 때에도 디자인이 꽤 앞부분에 있었던 기억이 난다. 여태껏 프로젝트들에 제공되는 기간들이 짧았어서 급한 마음에 늘 디자인을 뒤로 밀었었는데, 이번 프로젝트 때에라도 알게 되어서 다행이라고 생각한다.
-
프로젝트를 위해 firebase를 배우는 것은 좋은데, 프로젝트 기간 내에 firebase를 배워서 하자니 시간이 오래 걸리는 것 같아서 조금 초조하다. 내가 맡은 게시판 부분을 위해서
realtimebase사용은 하나의 값 넣고 하나의 값 읽고 하면 충분할 것 같기 때문에 화요일처럼 어렵지는 않을 것 같은데, 이번 팀프로젝트를 진행하면서, 내가 배운 범위보다 훨씬 넓은 범위의 기술들이 등장하니까 좀 소극적이게 되는 것 같다. 최대한 따라가고 더 배우고 기운내야겠다! 파이팅!
