사진 한 장으로 하루를 임팩트있게 기억해요! 지도 기반 sns 서비스 Popin 📌
앱스토어 링크: Appstore
- Development Environment
- 📚 Library
라이브러리 | 사용 목적 | Version | Management Tool |
---|---|---|---|
Alamofire | 서버 통신 | 5.9.1 | SwiftPackageManager |
SnapKit | UI Layout | 5.7.1 | SwiftPackageManager |
Kingfisher | 이미지 처리 | 7.11.0 | SwiftPackageManager |
ScalingCarousel | 캐러샐 | 3.2.0 | SwiftPackageManager |
- 🧱 framework
프레임워크 | 사용 이유 |
---|---|
UIKit | UI 구현 |
⭐️ Git Branch Convention
- Branch Naming Rule
- Issue 작성 후 생성되는 번호와 Issue의 간략한 설명 등을 조합하여 Branch 이름 결정
[prefix]/<#IssueNumber>-<Description>
- Commit Message Rule
[Prefix] <#IssueNumber>-<Description>
- Code Review Rule
- 코드 리뷰를 최대한 달고 반영하자!
⭐️ Git Flow
1. 작업 단위별 Issue 생성 : 담당자, 라벨, 프로젝트 연결
2. Fork 받은 로컬 레포에서 develop 브랜치 최신화 : git pull (origin develop)
3. Branch 생성 : git switch -c Prefix/#IssueNumber-description
> 예시) chore/#3-Project-Setting
4. 로컬 환경에서 작업 후 Add -> Commit -> Push -> Pull Request의 과정을 거친다.
Prefix의 의미
> [Feat] : 새로운 기능 구현
> [Chore] : 그 이외의 잡일/ 버전 코드 수정, 패키지 구조 변경, 파일 이동, 파일이름 변경
> [Add] : 코드 변경 없는 단순 파일 추가, 에셋 및 라이브러리 추가
> [Setting] : 프로젝트 세팅
> [Fix] : 버그, 오류 해결, 코드 수정
> [Style] : 코드 포맷팅, 코드 변경이 없는 경우, 주석 수정
> [Docs] : README나 WIKI 등의 문서 개정
> [Refactor] : 전면 수정이 있을 때 사용합니다
> [Test] : 테스트 모드, 리펙토링 테스트 코드 추가
5. Pull Request 작성
- closed : #IssueNumber로 이슈 연결, 리뷰어 지정
6. Code Review 완료 후 Pull Request 작성자가 develop Branch로 merge하기
- PR 최대 일주일 이내로 코드 리뷰 완료
7. 종료된 Issue와 Pull Request의 Label과 Project를 관리
⭐️ Naming & Code Convention
- 함수, 메서드 : lowerCamelCase 사용하고, 동사로 시작한다.
- 변수, 상수 : lowerCamelCase 사용한다.
- 클래스, 구조체, enum, extension 등 : UpperCamelCase 사용한다.
- 기본 MVC 폴더링 구조에 따라 파일을 구분하여 사용한다.
- 파일, 클래스 명 약어 사용. 단, UI 선언 구문과 메소드에서는 약어를 사용하지 않는다.
- 예시) ViewController →
VC
- 예시) CollectionViewCell →
CVC
- 예시) ViewController →
- 이외 기본 명명규칙은 Swift Style Guide, API Design Guidelines , Swift Style Guide를 참고한다.
- 상속받지 않는 클래스는 final 키워드를 붙인다.
- 단일 정의 내에서만 사용되는 특정 기능 구현은 private 접근 제한자를 적극 사용한다.
- 퀵헬프기능을 활용한 마크업 문법을 활용한 주석을 적극 사용한다.
- 이외는 커스텀한 SwiftLint Rule을 적용한다.