Skip to content

Home

Jump to bottom
Byeonghoon Lee edited this page Aug 9, 2022 · 1 revision

협업 관련 규칙 논의

Commit 단위

  • 기능 단위의 커밋에서 "기능"이란 단어가 상황에 따라 다를 수 있다는 문제
    • "기능"의 예시
      • 네트워킹 타입 -> Get 메소드 하나
      • EndPoint 타입
        • EndPointProtocol -> 기능 하나
        • EndPoint -> 기능 하나
        • 메소드 -> 기능 여러개
          => 하나의 "기능"은 하나의 "정의", "동작"과 유사하다.

Commit Convention

  • Commit Type
    • feat = 주로 사용자에게 새로운 기능이 추가되는 경우
    • fix = 사용자가 사용하는 부분에서 bug가 수정되는 경우
    • docs = 문서에 변경 사항이 있는 경우
    • refactor = production code를 수정하는 경우 (변수의 네이밍을 수정하는 경우)
    • test = 테스트 코드를 수정하거나, 추가하는 경우 (코드의 변화가 생산적인 것이 아닌 경우)
    • chore = 별로 중요하지 않은 일을 수정하는 경우 (코드의 변화가 생산적인 것이 아닌 경우)

Commit Message

[#3] feat: EndPoint 타입 구현

* 구현한 이유에 대해 작성
* 버그가 발생하는 커밋이라면, 발생하는 버그와 해결할 이슈 번호에 대해 작성

Coding Convention

Branch 전략

  • Git-flow를 간략화해 사용
    : main, develop, feature로 브랜치를 나누기
  • 브랜치 명명 규칙
    • develop : develop
    • feature : feat/camelCase

프로젝트 운영

Projects와 Issues 사용

  • Projects로 이슈를 시각적으로 관리
    • Projects는 비즈니스 로직과 각 뷰의 구현으로 분리하여 관리
    • Issues를 통해 기능의 세부 구현사항을 체크리스트로 작성

Issue 제목

  • [Feat] 제목
  • Label 종류
    • feat
    • refactor
    • bug
    • docs

구현 방식

  • 전체적인 앱의 설계와 네트워크 로직, 키보드 로직 등 앱의 핵심 로직은 페어프로그래밍을 통해 구현
  • 프로젝트 설정이나 UI 구성은 각자가 구현한 뒤 PR을 통해 코드 리뷰를 거침

프로젝트 설계

UI 구현 방식

  • 코드로 구현

아키텍처

  • 효율적인 구현을 위해 MVC로 구현

Clone this wiki locally