How to work.
이슈 만들고 리뷰 요청하고 리뷰하고 다시 ... 반복
2017년 추석 이후부터 2018년 추석 이후까지 한 동안 혼자 일을 했었다.
혼자 일하며 조금은 힘들었지만 내가 일하는 방식에 대해서 많이 생각하고 많이 고쳐보는 계기가 된 거 같다.
(직장 생활하면서 정말 하고 싶은데로 마음대로 할 수 있었던 유일한 시간이었다)
나만의 룰을 만들고 나 혼자 쓰는 게시판(비밀은 아니지만 아무도 보지 않는)에 정리해두었다.
- 메인 기능 정리 : 대부분 회사에서 나에게 시키는 일
- 혼자 해야 할 todo 정리 : 대부분 나만 아는 bug, 또는 나 혼자라도 넣었으면 하는 기능들
- 기술적인 feasibility 검토를 위한 정리
그리고 2018년 9월 27일 드디어! 나와 함께 일할 페어 개발자 M 이 왔다.
M 이 오기 2주 전부터 "그분이 오시면 해야 할 일"이라는 제목의 todo list를 만들기 시작했다.
그분이 오시면 해야 할 일들이제 우리의 룰을 만들기 시작했다.
버전 관리
major version 은 1.X.0 단위로 올린다.
minor, hotfix version 은 1.1.X 단위로 올린다.
기획과 협의하여 같은 버전이지만 다른 버전 코드를 업데이트하기도 한다. 즉, 2.2.0_220과 2.2.0_221 이 존재할 수 있다.
coding convension
View Res Id 리소스 네이밍 정의
kotlin extension으로 사용하면서 이전보다 xml에 작성하는 id 값이 더 중요하게 되었다.
액티비티에 있는 resID와 리스트 아이템에 있는 resID가 같을 경우 발생하는 문제
- prefix로 패키지 명을 붙인다. {pakcage_name}_ ex) post_article_title_text
- 리스트 화면에 들어가는 아이템은 xxx_{item}_xxx을 붙인다. ex) post_item_article_title_text
- 아이템 마지막에는 view의 종류를 적는다.
ex) xxx_edit, xxx_text, xxx_button, xxx_layout, xxx_image, xxx_radio, xxx_check_box, xxx_view, xxx_recycler_veiw, xxx_list_view, xxx_scroll_view, xxx_pager, xxx_fragment
스프린트 운영 룰
새로운 스프린트가 시작될 때 M과 회의를 시작한다.
1. 메인 피쳐는 이미 추가되어있다. (프로덕트의 메인 개발 이슈)
2. 쌓여있는 CS or Bug 중 이번 스프린트 기간 내에 해내야 하는 이슈를 추가한다.
3. 평소 코드를 보며 리펙토링이 필요하거나 문제가 의심되는 내용들을 추가한다.
- 업무 중에 언제든지 백로그에 필요한 내용들을 만들어 놓는다.
- //todo 와 //fixme를 통해서 코드 상에도 위치를 자주 표기한다.
자꾸만 쌓여가는 backlog코드 리뷰 방식
- 모든 작업은 jira로 시작한다. 아주 간단한 커밋도 issue를 만든다.
(라이브러리 버전 같은 경우에도 issue를 만든다.)
- 각각의 작업은 각각의 branch에서 작업한다.
feature/{issue_name}에서 작업
- git pull-request를 통해서 리뷰를 하고 승인을 받는다.
- reviewer는 branch를 master branch에 merge 하고 review 한 branch는 삭제한다.
Github barnch Protect 설정
PR 요청
리뷰는 이렇게 이루어진다.
부재 시 어떻게 할까?
2명이 리뷰하고 머지하는 방식을 사용 중이다. 1명이 휴가를 가면... 어떻게 해야 할까?
일단은 release/2.2.0_noah라는 브랜치를 임시로 만들어 각각의 이슈들을 머지하고 배포하여 테스트한다.
각각의 이슈는 release/2.2.0 (진짜 브랜치)에 pull request로 남겨둔다.
여기서 테스트해보자.
https://github.com/babosamo/PullRequest
코드 리뷰 에피소드
- M 은 코드 리뷰에 이런 문구를 자주 남긴다.
개인의 취향이지만 이렇게 작성하는 게 더 좋아 보입니다.
이럴 경우 대부분 수정을 한다. 이유는 나는 이렇게 쓰는 저렇게 쓰나 상관없는데 같이 일하는 사람이 이게 더 편하다면 고치는 게 더 효율적이라고 생각한다.
