- Timer를 통해 학습 시간을 관리하고 SNS로 인증하고 공유할 수 있는 Android 앱
- Rest 서버와 통신하며, MVVM과 Clean Architecture를 기반으로 유지보수성을 향상시키고자 함
- 기간 : 2022-010 ~ 2022-11+ (총 7주+)
- 인원 : 6명 (Android 4, Backend 2)
실제 공부하는 시간을 측정하는 타이머를 통해 공부 시간을 측정하고 기록을 저장할 수 있어요.
타이머로 기록된 특정 일자의 공부 시간과 내용을 리포트를 통해 확인할 수 있어요.
다른 사람들과 공부한 내용을 공유할 수 있어요.
오늘 하루 공부한 결과를 통계 자료를 통해 시각적으로 볼 수 있어요.
| 🐬Front-end | Android, Kotlin, Jetpack, Figma, Clean Architecture |
|---|---|
| 🍀Back-end | Spring Boot, Spring Security, JPA, Querydsl, JWT, MariaDB, Firebase, JUnit, JMeter |
| 🛠Server | EC2, Docker, Jenkins, Nginx, Certbot |
| 👨👩👦👦Collaboration | Gitlab, Jira Software, Mattermost, Notion |
🌐 Git Flow
master : 제품으로 출시될 수 있는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
🌐 Git branch 생성 규칙
master ← (release) ← develop ← be/fe ← feat 순서대로 머지 한다.
개발 시 feat-기능 이름 으로 브랜치를 만들어 상위에 머지한다.
- BE/feat/naver-login
- FE/feat/naver-login
UI만 작업을 할때는 가장 뒤에 UI를 작성한다.
- FE/feat/naver-login-UI
🌐 Git 커밋 컨벤션 생성 규칙
feat : 기능 추가
fix : 버그 수정
docs : 문서 수정
style : 단순 수정 (세미콜론, 코드 이동, 띄어 쓰기, 이름 변경)
rename: 추가된 기능, 별 내용 없이 폴더 및 파일만 추가, 폴더 및 파일 이름 수정, 옮기기
refactor : 코드 리팩토링
test : 테스트 추가
study : 학습 내용
ver01(간략) : commit type: Epic/대분류 | 작업 단위 [Jira 이슈 번호]
feat: 회원관리 | 네이버 로그인 기능 추가 [Jira 이슈번호]
ver02(설명) : ver01양식(Jira 번호 빼고) - 본문 - [Jira 이슈 번호]
feat: 회원관리 | 네이버 로그인 기능 추가
본문은 위, 아래 한 줄 띄우고 원하는 대로 작성한다.
=> 이런 식으로 특수기호를 쓰거나 이모티콘을 쓰는 것도 가능하다. 😄
단, 한 줄에 너무 길지 않도록 작성하자.
[Jira 이슈 번호]
-
Git과 Jira Convention을 정하고 Git Flow에 따라 진행하고자 하였습니다.
-
기능 명세서, API 명세서, Figma, Notion, GanttChart 등을 이용하여 문서화하여 소통하고자 하였습니다.
문서화하여 소통하니 보다 확실히 진행이 가능했습니다. 가령 Backend가 우선 진행하고 Android가 진행하는 것이 이상적이나, Infra 세팅 및 DB 등으로 인해 그러지 못하는 경우 API 명세서를 미리 작성하면 이후 크게 수정하지 않고도 진행할 수 있었습니다. -
Google Playstore 출시 및 사용자 피드백을 받아 유지보수를 하고자 하였습니다.
Playstore에 출시할 시 고려해야 할 문서, 권한 등에 대해 이해하게 되었습니다.
또 Git Flow를 이용한 버전관리와 Playstore 버전업데이트 방법에 대해서도 알게 되었습니다. -
활발한 의견 교류가 프로젝트의 완성도를 높인다는 것을 느꼈습니다.
같은 부분을 학습하거나 함께 구현할 기능을 정하여도 모두 다르게 이해하는 부분이 생겼지만,활발한 의견 교류와 토의를 통해 미리 파악하고 의견을 좁힐 수 있었습니다.이로인해 프로젝트 진행 시 서로의 이해와 구현을 확인하고 정리하기위해 끊임없이 소통하려는 노력이 중요함을 느꼈습니다.
오류를 해결할 때도 Front나 Back에서 문제가 생기면 각 자의 부분만 확인하기보다는 의견 교류를 하는 것이 효과적인 경우가 많았습니다.
코드 리뷰를 하여 피드백을 주고 받아 구현 방법을 보완할 수 있어서 많은 도움이 되었습니다.
| Used | AndroidStudio / Kotlin / MVVM / Retrofit / OKHttp / Paging / Coroutine |
|---|---|
| Used | Bottom Navigation / RecyclerView / DataBinding / ViewModel / LiveData |
| New | Clean Architecture / Coroutine Flow / BaseActivity / ResultState / Hilt / Lottie |
| Collabo | Git / Git-Flow / Jira / Notion / Mattermost / Swagger / Figma / GanttChart |
구현 :
모듈을 3개로 나누어 각 모듈이 책임을 나눠서 가지도록 하였습니다.
ㄴPresentation(View, ViewModel 등 Android 종속성이 높은 UI 관련)
ㄴData(Datasource, ResponseDto, API 등 Data 처리와 서버 통신 관련)
ㄴDomain(Usecase, Dto, Repository Interface 등 Android 종속성이 없는 비즈니스 로직 관련)
느낀점 :
DB 변경, Local과 Remote 변경 등 데이터 저장 방식의 변경이 간편해지고, Server의 데이터 Response가 변경되어도
Mapper를 두어 다른 계층에의 영향이 적어지는 등 UI, Domain, Data가 변경되더라도 서로에 대한 수정이 적어졌음을 크게 느꼈습니다.
또 통일된 구조로 앱 구조 파악 용이, Usecase 등으로 인한 코드 재사용성 강화, 각 모듈의 역할 분담에 따른 코드 유지보수성 향상을 확인했습니다.
전체적으로 기존의 방식과의 비교(ResultState, Mapper, Flow 와 LiveData, Clean Architecture 등)로 진행하여 각 기능들에 대해서 보다 이해할 수 있게 되었습니다.
구현 :
학습 시간 측정 시 기기 시간이 다를 것을 고려하여 Server로부터 시간을 받아 저장하고, Timer로 학습 시간을 측정하도록 하였습니다.
1초마다 현재 시간을 갱신하여 화면에 표시하도록 하였습니다.
측정이 종료되면 학습 내용을 입력받아 경과시간을 계산하여 Rest Server에 저장하도록 하였습니다.
느낀점 :
Data <-> String 변환과 같이 전체적으로 사용되는 함수는 Utils 등에 따로 두고 함께 사용하는 것을 설계 단계 부터 고민하는 것이 좋을 것 같습니다.
사용자 테스트 중 Timer와 같은 Background 기능 구현 시 안드로이드 버전에 따른 Background 제한 정책이 있음을 확인하였습니다.
해당 내용과 해결을 위한 WorkManager, ForegroundService 등을 학습하여 Bacground Limit, Doze Mode 등에서도
Background 기능이 정상 동작하도록 이해를 높이고자 하였습니다.
구현 :
Paging을 이용하여 유저들이 등록한 게시물을 조회할 수 있도록 하였습니다.
느낀점 :
Paing의 구현 방식에 따라 조회 시간에 차이가 남을 확인하였습니다.
Server 담당자와 기능 구현을 논의하여 기존 방식보다 Paging 조회를 빠르게 구현하는 방법에 대해 이해를 높이고자 하였습니다.