현재 저는 테킷 안드로이드 앱 스쿨에 참여하고 있는데요
멋쟁이 사자처럼이라는 곳에서 진행하고 있습니다 🦁
열심히 배운 지식들을 쏟아부었던 ...
쇼핑몰 팀 프로젝트를 가지고 회고를 해보려고 이렇게 글을 쓰게되었습니당
(부제의 비하인드 스토리는 추후 공개...)
👩🎓 첫 시작_ 주제 잡기 + 기획
쇼핑몰이라는 큰 주제는 정해주셨지만 어떤 쇼핑몰을 기획하고 개발할지는 저희의 몫이였습니다,,,
그래서 첫 시작은 기획 회의를 진행했죠...!
제가 낸 아이디어는 대학생들의 작품 판매 쇼핑몰이였는데요 !
제 주변 미대생들의 얘기도 듣기도 했었고,,, 졸전이나 과제로 작품들을 만들면
교내 보관이나 개인 보관 폐기처리까지 잘 활용하지 못한다고 하더라고요...
그래서 낸 아이디어였는데 당첨~
앱 이름도 제가 낸 아이디어로 당첨 !
UniPiece (University Piece) 대학교 + 작품 이라는 뜻의 유니피스로 결정했습니당
어감도 유니피스 예쁘더라구요 (제가만들어서그런건아님)
근데 이 과정이 정말 힘들었습니다...
개발 일만 하다가 디자인이랑 기획까지 하니까 진짜
PM과 디자이너 그리워
내게 와 ...
그래도 팀원 분들 덕에 무사히 어찌저찌 잘 마치고 개발에 들어갔습니다!
저희 팀 로고입니다 하하 미리 공개하는데 괜찮나요?
안괜찮아도 괜찮다고 해주세요.
💻 개발 시작_ Git + UI
기획과 디자인을 완료하고 개발을 시작했습니다...!
저희가 디자이너분과 함께 개발을 한게 아니기 때문에
디자인을 제대로 구성하지는 못했어요! 사이즈나 그런 것들...?
그래서 최대한 구성을 비슷하게 하기 위해서 UI 규칙을 정하고 시작했습니다!
- 버튼 높이는 40dp 통일
- 최대한 가운데 정렬해보기…!?
- textfield 56dp 높이
- 툴바 아이콘 크기 24*24, 클릭 범위 48*48
- 툴바 높이 64dp, 툴바 오른쪽 왼쪽 정렬 16dp
- 툴바 제목은 세미볼드, 20sp
- 글자크기 20-(18)-16-14-12sp
- 버튼 텍스트는 18sp
- divider 간격은 16-16 띄우기
- material 디자인 사이트 참고해서 사이즈나 패딩 가이드라인 참고하면 좋아요!
- 화면 구성할때 전체적으로 각 컴포넌트들의 왼쪽 정렬 (margin)은 최대한 맞춰주면 좋습니다!
여기서 핵심!
사실 이 규칙들도 material 사이트를 참고해봤는데요 !
다들 material 사이트에 디자인 권장사항이 있다는 거 아시나요?
꿀팁입니다 다들 참고하세요
여기서 사용하시는 것 검색하셔서 specs나 guideline 보시면 됩니당 😊
이렇게 UI 규칙까지 정하고 본격적 개발에 들어가려 했으나...
저는 지금도 깃에 깃자도 모르고 안드로이드의 안자도 모릅니다.
잘은 모르지만 대학교 다니면서 팀프로젝트도 하고 이것저것 프로젝트를 했었던 경험이 있었죠...!
그런데 팀원분들께서는 거의 개발 경험과 팀프로젝트 경험은 없으셨고
Git, GitHub도 잘 모르시더라고요...!
그래서 제가 했었던 방법과 모든 지식을 소개해드렸습니다
(사실 저희 팀 말고도 저희 스터디 분들과 저희 회고조 분들께도 소개해드리고... 저 총 4번정도 강의한듯)
https://github.com/kangyein9892/TechitTest
https://github.com/kangyein9892/test
이렇게 제 깃허브에서도 총 두곳에서 함께 연습해봤어요 ...!
우선 저희 팀 깃브랜치 전략은 다음과 같았습니다!
- main
- 개발이 완료된 산출물이 저장될 branch
- develop (default branch)
- feature branch에서 구현된 기능들이 merge될 branch,
- 개발이 완료되면 main 브랜치로 merge
- 이슈 단위 브랜치
- 개발하는 branch, issue 단위로 생성하여 구현
이슈를 생성해서 이슈 단위로 브랜치를 만들어서 개발을 진행했습니다!
최대한 이슈를 잘 나누어서 현재 진행중인 작업이 어떤곳인지 알게끔 해주었어요
(지금도 사실 어렵습니다... 하다보면 작업이 뚱뚱해지더라고요..)
이슈 템플릿도 제가 하나하나 다 제작했습니다
이런게 있는지도 이번 프로젝트를 통해 알게되었어요!
통일성을 가지니까 확실히 팀원들끼리 공유하기도 편하더라고요~
실제 썼던 이슈 보여드릴게요 ~
그리고 또 하나 알게된 사실 !
깃허브에 칸반보드라는 게 있더라고요! -> 알려주신 분 감사합니다 ^-^
그래서 저희 팀 칸반보드를 만들어서 진행했답니다
(지금은 진행완료라서 다 진행완료로 가있네용)
[규칙은 밑에 쓴 것과 같이 진행했습니다]
- 진행전: 진행 전으로 만들어놓은 것들
- 진행 중지: 진행이 중단 된 것들
- 진행 중: 진행 중인 것들
- 진행 완료: 진행 완료된 것들
- 예상 종료 날짜 선택해주기!
제일 중요한 커밋 메시지도 컨벤션 규칙도 정해보았습니당
- commit 타입 및 메세지
- Fix : 버그, 오류 해결 [Fix] #10 로그인 오류
- Add : Feat 이외의 부수적인 코드 추가, 라이브러리 추가
- Design : xml 등을 통해 디자인 변경 혹은 설정
- Feat : 새로운 기능 구현
- Del : 쓸모없는 코드 삭제
- Remove: 파일 삭제하는 작업만 수행한 경우
- Style: 코드 포맷팅, 코드 변경이 없는 경우
- Docs : README나 WIKI 등의 문서 개정
- Refactor : 내부 로직은 변경 하지 않고 기존의 코드를 개선하는 리팩터링 시
- Rename: 파일 혹은 폴더명을 수정하거나, 옮기는 작업
- Chore : 그 이외의 잡일/ 버전 코드 수정, 패키지 구조 변경, 파일 이동, 가독성이나 변수명, reformat 등 (build.gradle 수정)
- Comment: 주석 추가 및 변경
- Test : 테스트 코드 추가
- [태그] #이슈번호 내용
이슈와 마찬가지 Pull Request도 템플릿을 만들어서 사용했어요!
급한 안건이나 본인 작업만 있을경우에는 바로 Merge 하도록 했지만
그런 경우가 아니고 특히 충돌이 있을경우에는 팀원들과 상의 후
그리고 코드리뷰 후에 머지하도록 진행했습니다!
이런식의 템플릿이였습니다...!
실제 썼었던 pr 입니다~
또 그리고 깃과 관련된 하나의 일화!
깃이그노어에 대한 이슈도 발생했었는데요...!
제가 멍청하게 실수로 깃이그노어에 추가해야할 부분을 추가 안했지 뭐에용...
https://yenitory.tistory.com/52
gitignore 설정을 잘못했는데 어쩌지😥
안녕하세요 오늘은 gitingore 설정을 잘못했을 경우에 대해서 얘기해보겠습니다! 개인프로젝트에서 잘못한게 아니라...무려 팀프로젝트에서 gitingore 설정을 잘못하고 사용했더라고요...! # Android S
yenitory.tistory.com
요기 올렸으니 참고 부탁드립니다 🤗
다들 팀프로젝트 할때 쉽게쉽게 요 방법으로 하시면 됩니다잉
👩💻개발 중_ 코드리뷰의 중요성
아무래도 제가 깃허브 저희 레포를 파서 올리기도 했고 초반 작업 틀은 만들어놓는게 좋을 것 같아서
bottom navigationbar를 만들어서 가장 큰 틀이 되는 fragment들을 만들고 github에 올렸습니다!
그래서 뒤로가기 부분이나 fragment 이동 부분을 제가 중점으로 맡아서 했었죠..
근데 여기서 이슈가 발생하는데 저희 팀 fragment가 크게
1. home
2. buy
3. rank
4. mygallery
5. mypage 였습니다
그런데 자꾸 뒤로가기를 하다가 꺼질 타이밍이 아닌데 앱이 꺼지는 거에요...?!
home에서 다른 화면을 갔다가 뒤로가기를 하면 꺼지더라고요...
대체 왜? 왜지?! 왜!!! 😥😥😥😥😥😥
진짜 이걸로 개발하면서 며칠을 고민했습니다...
근데 그러다가 ... 정말 멋지신 분과 같이 고민을 하다가 발견했습니다...
저는 mainactivity에서 fragment 이동을 하니까 거기만 보았거든요....
(mainactivity에서만 며칠 내내 삽질했습니다)
근데 home에서만 자꾸 꺼지니까... 멋진 분께서 homefragment를 가보셨는데
웬걸! 문제의 코드를 발견했습니다.
// backButton을 눌렀을 때
mainActivity.onBackPressedDispatcher.addCallback {
mainActivity.finish()
}
이래서 꺼졌던 것이였습니다...
home에서 백버튼을 누르면 mainactivity를 종료시키게 되어서...
이 부분이 제 작업 부분이 아니였기도 했고
저는 home이 문제라고 생각을 못했어요...!
그냥 fragment 이동 단위 전체가 문제라고 생각을 했기 때문에...
Mainactivity만 주구장창 팠습니다,,,
그 작업자 분이랑 한 번 더 얘기를 해보고 !
코드 리뷰를 좀 더 빡세게 하고 !
home이 문제라고 생각해보고 homefragment에 들어가볼걸 !
이라는 후회를 했습니다...
여러분 정말 코드리뷰는 중요합니다 팀프로젝트에서 코드리뷰는 최대한 필수.
그리고 코드리뷰를 해보니까 다른 사람 코드 이해하기 쉽지 않더라고요...
그리고 제가 이해를 시킬 수 있도록 코드를 짜는 것도 어렵지만...
쉽게 짜보려고 노력중에 있습니다!
함수명도 잘 지으려고 하고, 함수 단위도 잘 쪼개려고 하고!
너무 짧은 코드도 안 좋지만, 너무 긴 코드도 안 좋은 것 같아서... 적당히 하려고 하는 중입니다
아 그리고 다들 당연히 아실 것 같지만 코드리뷰에서 중요한 사실!
저는 보통 pr에서 코드리뷰를 보는데
commit과 코드 추가 삭제가 너무 많으면...
힘들어요 눈에 안 보입니다 ...
팀원분들과 적당한 상의 후에 그 규칙도 정하는게 좋을 것 같아요!
저희도 정확한 기준점은 못 정했지만 너무 많은 양의 작업을 하지 않기로 약속을 했었답니다,,
작업하다보면 많이 늘어나기는 하지만... 꼭 생각하면서 하기 ...~ 우리 약속 😆
📌결론: 코드리뷰 하세요!
쓰다보니 길어져서 ... 1편만 쓰려다가 2편까지 오게 될 것 같네요 !
봐주셔서 감사합니다!