역할 나누기

프론트 엔드와 React

프론트 엔드

사실 이번 프로젝트에서는 백엔드 역할을 맡고 싶었다.
가장 희망하는 직군이 백엔드 개발자이기도 하고, 아직 실전 경험을 해보지 못했기 때문이다.

하지만 우리 조에서는 프론트엔드 경험이 있는 팀원이 없었고, 그나마 내가 바닐라 JS 인강이라도 들어본 경험이 있기 때문에 프론트 엔드를 맡기로 하였다.

다른 조를 보면 AI 담당이 제일 많고, 프론트와 백은 많아 봐야 2명 정도인 것 같은데, 우리 조는 프론트가 3명이 되었다.
AI 담당하는 팀원들이 듬직하기도 하고, 앞서 말했듯 프론트 경험자가 전무하기 때문에 프론트 엔드가 난관일 것이라 생각했기 때문이다.

React

모바일 앱을 개발하기로 했는데, React+Django를 이용한 모바일 웹앱을 만들기로 하였다.

React Native, Flutter는 정말 아예 미지의 영역이기 때문에 그나마 익숙한 JS를 쓰는 React로 개발하는 것이 나을 것이라 생각했고, 또 네이티브 기능을 그다지 많이 활용하지 않는 서비스기 때문에 웹앱으로 개발해도 문제가 없을 것이라 생각했다.

하지만... 다들 리액트 네이티브나 플러터 쓰는 건 다 이유가 있었다... React로 만드는거 너무 힘들다...

그라운드 룰 & 컨벤션

그라운드 룰 전문

그라운드 룰

일반

• 시작 후 15분, 끝나기 전 15분 - 짧게 스프린트 회의
  • 시작 전 : 오늘 할 일에 대해 협의
  • 끝나기 전 : 하루동안 어떤 것을 했는지 얘기하기
  • 월 시작 전/금 끝나기 전은 스프린트 주간 계획/회고 진행(탄력근무 계획) - 15분이 아니라 되는대로 진행
    • 월 시작 전 : 일주일 간 계획 및 대략적인 시간 이야기
    • 금 끝난 후 : 진도 체크, 추가 근무 필요하면 결정
• 조별 코칭, 그룹 코칭이 있는 날 (화, 목) 대면 진행
• 칼퇴 준수

코드 관련

• 주석 많이 달아주세요

GitHub 관련

• 모든 작업은 본인 이름의 branch에서 진행 (main X)
• push가 완료되면 담당자에게 알려주고 PR(Pull Request) 생성하기
• 담당자가 코드 확인 후 merge
• 프로그램에 불필요한 테스트 코드(파일), 로그 등은 .gitignore 에 등록해서 main에 올라가지 않도록
  • 어떤 파일을 등록해야하는 지는 각자 검색해보기

commit 규칙

git commit -m “[Feat] commit messages”

• Feat : 새로운 기능 추가, 기존의 기능을 요구 사항에 맞추어 수정
  • 어지간하면 다 feat 쓰시면 될듯 ㅎㅎ
• Fix : 기능에 대한 버그 수정
• Build : 빌드 관련 수정
• Chore : 패키지 매니저 수정, 그 외 기타 수정 ex) .gitignore
• Docs : 문서(주석) 수정
• Style : 코드 스타일, 포맷팅에 대한 수정
• Refactor : 기능의 변화가 아닌 코드 리팩터링 ex) 변수 이름 변경
• Release : 버전 릴리즈
• Merge : 병합
• [Feat] ← 이런식으로 맨 앞에 붙이고 뒤에 메세지는 자유롭게 작성

PR

• 뭔가 복잡하다 싶으면 설명 작성해주세요!

코딩컨벤션

Django

01. Code lay-out

• 인덴트(Indent): 공백으로 4칸 들여쓰기

• Blank Lines

  • 함수 및 클래스 정의 위에는 빈 2줄
  • 클래스 내의 메소드 정의에는 1줄씩 빈 줄

02. Whitespace in Expressions and Statements

• 불필요한 공백 넣지 않기
  • 대괄호[], 소괄호() 안
  • 쉼표(,), 쌍점(:)과 쌍반점(;) 앞

03. Comments

• 코드와 맞지 않는 주석 없도록 하기(항상 최신의 코드내용 상태로 유지)

• 불필요한 주석 달지 않기

• 명령문과 같은줄에 있는 인라인 주석은 많지 않도록 하기

04. Naming Conventions

• 피해야 하는 이름 : 'l'(소문자), 'O'(대문자) 또는 'I'(대문자) 단일 변수
  • 숫자 1, 0과 구별하기가 어렵기 때문
• 이름 정하기
  • 모듈 명은 짧은 소문자로
  • 클래스 명은 카멜케이스(CamelCase)로 작성
  • 함수명은 스네이크 케이스(snake_case)로
  • 인스턴스 메소드의 첫 번째 인수는 항상 self
  • 클래스 메소드의 첫 번째 인수는 항상 cls
  • 상수(Constant)는 모듈 단위에서만 정의, 모두 대문자

React

네이밍 컨벤션

1. Components(클래스, 모듈 등) : PascalCase
2. Non-Components(함수 등) : camelCase
   • 일반 JavaScript 코드 또는 비-React UI 요소
     • Javascript 함수
     • Javascript 객체
     • HTML 요소
3. 속성명 : camelCase
4. inline style : camelCase -> 되도록 지양해주세요

코드 작성 규칙

1. spread 연산자 사용 (...)
   • 어짜피 이거 저희 쓸 일 없을듯?
2. let과 const만 사용 (var X)
3. 되도록 화살표 함수 사용
   • const myFunction() => {};
4. null check는 option chaning 연산자 (?.)를 사용

그라운드 룰

• 다들 컨벤션 적용이 익숙하지 않아서 React 컨벤션, Git Flow 등등 다양한 자료를 검색하면서 컨벤션을 만들었다.

참고자료들
[react] react 코딩 컨벤션
Two Scoops of Django - 1. 코딩 스타일
[Git] 깃 커밋 메시지 작성법(git commit message) - 1

• 애초에 지키면서 하기 어려울 것이라 생각해서 최대한 적용하기 쉬운 것을 가져왔는데 아직까지는 그럭저럭 지켜지고 있다.

Git Flow

• Git 사용에 최대한 익숙해지고자 Git Flow를 적용하게 되었다.

출처 : 우아한 기술블로그 - 우린 Git-flow를 사용하고 있어요

• master, develop, feature, release, hotfixs 크게 5가지 종류의 브랜치로 소스 코드를 관리하는 방법이다.

  • Master : 배포 시 사용하는 최종 branch
  • Release : 배포할 버전을 관리하는 branch, 버그 수정 정도만 이루어진다.
  • Develop : 실재 개발이 이루어지는 branch, 개발이 완료된 branch는 모두 develop에 merge된다.
  • Feature : 각 기능별로 나누어진 branch
    • feature/login, feature/blog 등으로 기능 별 구분
    • 새로운 기능 구현 시 develop의 코드를 기반으로 생성
  • Hotfix : master에서 에러가 발생했을 때 긴급 수정을 위해 사용 하는 branch

• 이번 프로젝트에서는 다들 git 사용이 익숙하지 않기도 하고, 실무에 비하면 작은 프로젝트가 진행되므로 release를 제외하고, feature를 조금 큼직큼직하게 나누어 간소화한 버전으로 사용하였다.

• 들리는 소문에 의하면 몇 시간 작업한 것을 날려먹거나 하는 일이 종종 발생하는 것 같은데, 아직 우리조는 다행히 각종 버그는 넘쳐도 코드 자체가 날아가는 일이 없었다.

• 또한 기능별로만 개발이 이루어지니 어지간한 에러는 feature branch에서 잡히기 때문에 develop에서 conflict가 발생하거나 에러 폭탄이 발생하는 일이 비교적 적었던 것 같다.

컨벤션은 점점 잊혀지는 것 같다 ㅠㅠ

• 다들 git이 익숙치 않아 크고작은 이슈들이 발생하고 있지만.. 그래도 아직까지는 git flow가 잘 지켜지고 있는 것 같아 다행이다.