PLOVER에서의 팀장, 첫번째 이야기

서론

PLOVER의 프로젝트의 팀장역할을 진행하면서 가장 중요하게 생각했던 몇가지를 적어보려고 한다. 

1. Business Rule - 프로젝트를 진행하면서 정한 Rule로 블로그에서도 첫번째로 다뤄보려고 한다.
2. JIRA - 이슈를 관리하며 진행중인 각 팀원들이 진행중인 프로젝트를 확인하고 기한내에 목표를 설정하고 밀도있는 진행을 위한 필수적인 요소였다.
3. README - 프로젝트의 현재 상황을 가장 쉽게 공유할 수 있는 곳으로 다양한 방법으로 README를 관리했었다. 프로젝트 관리면에서 다룬 README의 관리내용을 다뤄볼라고 한다.
4. 협업툴 관리 - 프로젝트를 진행하다보면 다양한 프로그램들을 이용하고 그 프로그램들을 연동하여 사용하는 내용들이 얼마나 생산성을 높일 수 있는지로 직결된다. 특히나 코로나-19로 인해 온라인으로 프로젝트를 진행하는 우리팀의 경우 더더욱 신경을 썼어야 하는 내용이었다.
5. 팀원간의 소통 - 어쩌면 가장 어려웠고 가장 힘들었던 부분이었지만 가장 많이 배운 내용이라 카테고리를 따로 빼서 느꼈던 부분에 있어서 적어보려 한다.

---

Business Rule

 

구조

개발 규칙은 아래와 같이 세가지로 크게 나눠서 진행했다.

• 개발 규칙
• Git 규칙
• JIRA 규칙

---

개발규칙

📌개발규칙

공통

• 특수문자는 _ 만 허용한다.
• ex) Is_Select(클래스), get_Value(함수), is_Select(변수)

클래스명

• 클래스명은 대문자의 명사로 시작한다.
• ex) MemberDto

함수명

• 소문자의 동사로 시작한다.
• ex) getValue

변수명

• 소문자로 시작하며 여러 단어로 이루어진 경우 카멜표기법으로 작성한다.
• ex) selectProblemList

---

개발 규칙은 공통, 클래스명, 함수명, 변수명 4 부분에 있어서 규칙을 정했다. 이후 BE(BackEnd), FE(FrontEnd) 단위로 나눠서 세부 규칙은 파트별로 진행했다. 

 

• 공통

공통 사항에서는 전체적으로 특수문자를 사용하는 규칙에 있어서 통일을 시켰다. 다양한 특수문자가 있겠지만 ' _ ' 만 사용하며 다양한 특수문자를 미연에 방지하고자 정했다.

• 클래스명

클래스명은 너무나 당연하지만 대문자로 시작하는 규칙을 정했다. 또한 동사나 형용사가 클래스 명이 아닌 명사 상태를 클래스명으로 정하면서 명확한 명명을 하기 위한 규칙으로 정했다.

• 함수명

함수명은 특정 성격과 역할을 띄는 경우가 대부분이다. 또한 이러한 내용때문에 동사로 시작하여 명명된 이름만으로도 그 역할과 성격을 파악할 수 있도록 규칙을 정했다. 또한 카멜표기법으로 진행했다.

• 변수명

변수명은 다양한 변수가 있기 때문에 카멜표기법으로 다양한 단어로 이뤄질 경우 가독성을 높이기 위해 정했다. 또한 이부분에서 변수명 규칙을 정하며 가장 신경 쓴 부분은 간단하면서 핵심단어로 이뤄지도록 하는것을 핵심으로 생각했다.

 

---

✨Git 규칙

branch

branch name기능

 

master	배포 상태로 오류 없는 상태를 유지한다. Tag를 이용하여 버전을 관리한다.
release	master로 merge하기전에 점검하는 단계로 back과 front를 합쳐 진행한다.
develop-front	frontend develop branch
develop-back	backend develop branch
feature	이슈별로 관리한다. 현재 프로젝트의 이슈번호는 S04P12B104-4 이다. 뒤의 -4 부분은 이슈 고유 번호를 뜻한다. ex) feature-4

 

merge

코딩하기 전 본인 파트의 develop 가져오기

develop브런치로 이동

git checkout develop

현재 branch에 master의 내용 불러오기

git pull origin master

MR(Merge Request)

 

• merge 하기 전 서로 코드 리뷰하기(파트 별 인원에 모든 리뷰가 있어야 merge 가능.)
• 팀장 혹은 CTO가 확인 후 merge
• merge 후 branch 지우기(feature브랜치만 해당)

 

commit

commit Type

- feat : 새로운 기능 추가

- fix : 버그 수정 - docs : 문서 수정

- style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우

- refactor : 코드 리팩토링

- test : 테스트 코드, 리펙토링 테스트 코드 추가

- chore : 빌드 업무 수정

 

• 제목 : commit type / Jira Issue No / Jira Issue Title or 내용 요약

• 참고사이트_git - 커밋 메시지 컨벤션

• 우수커밋github

• ex) feat / S04P12B104-4 / Business Rules 작성

woowacourse-teams/2020-6rinkers

Git - 커밋 메시지 컨벤션

 

** 문서의 경우 docs: 버전 / 이슈번호 / 내용 으로 커밋해준다.

---

Gitlab 규칙은 branch 전략, commit 전략, merge 전략 부분으로 나눠질 수 있다. 이 부분에서 활용해보면서 괜찮았던 부분과 아쉬웠던 부분을 중심으로 적어보고자 한다.

 

• branch 전략 : 해당 프로젝트는 Git-flow workflow 방식으로 진행했습니다. 해당 부분에서 다른 프로젝트와 비교했을때 차이점은 develop branch 부분에서 front와 back을 나눠서 진행했다. 이유는 아래와 같다.
  • Front-End
    • React를 처음 도입하는 과정에서 개발과 러닝커브를 고려
  • Back-End
    • CI/CD를 우선 적으로 도입하는 과정을 우선적으로 진행
    • JPA를 처음 도입하고 Spring-Security 등과 같은 내용의 러닝커브를 고려 
  • 해당 전략으로 진행하면서 다음 프로젝트에서는 develop에서 합쳐서 Back-End와 Front-End의 더 많은 소통을 진행하는 것을 목표로 할 예정이다. 
  • 런닝 커브를 고려해서 진행하다보니 branch를 나눠서 진행하는 것이 좋았지만 개발 능률적인 측면에서는 develop에서 Back과 Front가 만나 바로 바로 확인하여 소통하는 방식이 좀 더 애자일 방식에 다가가는 방식이라 생각이 들었다. 
• commit 전략 : Commit Message Convention으로 기존에 많이 사용되는 Commit Message Convention을 진행했다.
  • 장점
    • 기존의 Commit Message가 많이 통일화 되고 Message만 보더라도 어떤 의도로 진행이 되었는지 알 수 있어서 좋았다.
    • JIRA와 연동하여 스마트 메세지 방식이 가능해져서 이슈 관리에도 아주 좋았다.
      • 해당 이슈로 바로 연결이 가능하고 연결한 이슈에서 바로 상세내용을 확인하여 Commit Message에서 1차 확인 JIRA에서 2차 확인이 가능했다.
  • 다음 프로젝트에서 진행할 사항
    • 기존의 많이 사용하는 Commit Message Convention과 JIRA와 연동은 아주 좋았다. 이후 프로젝트를 진행하면서는 프로젝트의 특성에 맞추어 Commit Message Convention을 커스터마이징하여 진행해보고 싶다.  
    • 프로젝트 초기 단계에서 Convention을 설정할때 충분한 이야기를 나누어 프로젝트에서 필요한 Convention 을 찾아내어 그 부분을 해속시킬 Convention을 진행해 보고 싶다. 

이후의 내용들은 JIRA 관련 내용이다.

JIRA를 이용하면서 정한 Rule의 경우 Business Rule보다는 JIRA를 처음 사용하는 팀원들을 위한 정리를 진행한 부분이라 다음 블로그 글에서 적어보도록 하겠다. 

 

여기까지가 PLOVER의 Business Rule이었다. 

 

전체 Business Rule 보러가기 upsw-p.tistory.com/12