• Jan
  • Feb
  • Mar
  • Apr
  • May
  • Jun
  • Jul
  • Aug
  • Sep
  • Oct
  • Nov
  • Dec
  • Sun
  • Mon
  • Tue
  • Wed
  • Thu
  • Fri
  • Sat
  • 27
  • 28
  • 29
  • 30
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

비어있다 프로젝트 초기 세팅하기

마일스톤, 버저닝 규칙 설정하기

MOMO할 때 찾아봤던 마일스톤 확실히 사용해보기! 버저닝 규칙은 여기를 참고
어떤 기능들이 완성되어야 하는지를 기준으로 간단하게 !!

1차 배포(1순위)를 1.0.0 으로 두고,
0.1.0 - 1순위 뷰 끝
0.2.0 - 1순위 뷰 통신 끝
요렇게만 하면 너무 광범위 한 느낌이기도 하고, 마일스톤 달성하는 맛을 보면서 동기부여를 하기 위해
figma에 있는 카테고리(메인, 검색하기, 마이페이지) 대로 더 세분화 시켜보면

0.0.1 - 뷰 레이아웃 짜기 (현재 와이어 프레임만 나와있는 뷰가 대부분이라)
0.0.2 - 메인에 필요한 뷰 끝
0.0.3 - 검색하기에 필요한 뷰 끝
0.0.4 - 마이페이지에 필요한 뷰 끝
0.1.0 - 1순위 뷰 끝

0.1.1 ~ 0.1.n 뷰 별 통신 붙이기
0.2.0 - 1순위 뷰 통신 끝
( 아직 서버 API문서를 자세히 정리해놓지 않아서 어떤 통신들이 나와있는지 모르는 상태..!)

image

그림으로 정리해보면 이런 식!
위 그림처럼 각 마일스톤의 변경점은 해당 task가 끝난 후로 일단 설정을 해 두긴 했는데…
이게 맞는지는 잘 모르겠다 ( ◠‿◠ )
암튼 해당 task들을하면서 그 마일스톤을 향해 달려가는 느낌이라고 이해했다!

배포 후의 버저닝은 안드로이드 개발자 분들이 노션에 릴리즈 노트를 기록하고 계셔서,
안드가 올리는 것과 맞춰서 올리면 될 것 같다.

Issue와 Pull Request

iOS 개발을 나 혼자 하는거라… 필요할까? 하는게 맞나?라는 생각이 자꾸 들었지만
계속 하는게 낫겠다는 생각을 하던 와중에 이 글을 읽게 되고 확신이 생겼다
MOMO를 진행할 때에도 이슈나 PR로 나눠둔 작업들을 다시 본 적도 많았다!

MOMO에서 했던 것 처럼,
커밋메시지에 이슈 번호를 기록하고 PR Fixes 키워드를 사용해서 닫는 과정을 혼자서 진행한다.
참고한 글에서 참고한(;) 책에 나오는 이슈 기반 버전 관리 워크플로우는 다음과 같은데,

① 새로운 이슈를 열고 번호를 확인한다.
② 로컬 저장소에 새로운 브랜치를 생성한다. 형식은 “이슈 번호-설명”.
③ 이슈에 적어둔 목표를 해결한다. (오직 이슈에 적힌 내용만 작업한다)
④ 작업을 테스트하여 제대로 완료됐는지 확인한다.
⑤ 수정 사항을 커밋하고 푸시한다. (github이 커밋을 추적할 수 있도록 커밋 메시지 안에 이슈 번호를 적어야 한다)
⑥ 작업이 잘 완료됐다면 작업 브랜치를 메인 브랜치에 병합(merge)한다.
⑦ 이슈에 모든 내용이 잘 기록됐는지 확인하고 이슈를 닫는다.

내가 하던 방식과 비슷해서 그대로 진행하면 될 것 같다!

Convention

Issue label(Commit Type)

Type Description
feat 새로운 기능 추가 (new feature)
fix 버그 수정 (bug fix)
docs 문서 작성, 수정 (documentation)
style 코드 포맷팅, 세미콜론 누락 등 코드 변경이 없는 경우
refactor 코드 리팩토링 (refactoring)
chore 빌드 업무 수정, 패키지 매니저 수정 등 (production code 변경이 없는 경우)

MOMO에서 원래는 test(테스트 코드 작성), perf(성능 개선) 을 포함한 8개의
issue label을 사용하자고 했었는데, perf에 해당하는 내용은 refactor를 쓰게 되고..,
test는 사용하지 않아서(테스트 코드를 안 썼기 때문에,,) 우선 지웠다.
테스트코드를 쓰게 되면 test도 추가할 예정!

이슈 제목

[Commit Type] 이슈 제목

그리고 Commit Type 라벨 추가. 1인 개발이라 이름 라벨을 붙일 이유가 사라졌다!

커밋 메세지

[#이슈번호] 커밋 내용 요약

원~래는 [#이슈번호] 대신 [Commit Type]을 쓰기로 했었는데…
쓰다 보니 [#이슈번호]가 더 직관적이고 좋은 것 같다. 바로 해당 이슈로 이동할 수도 있고! 아래 새로 도입해 볼 것에 더 자세한 내용이 있다!

PR 제목

[#이슈번호] 커밋 내용 요약

그리고 Commit Type 라벨 추가

PR 양식

### Description
캡쳐 첨부, 한글 설명
### Related Issues
Fixes #이슈번호

새로 도입해 볼 것

커밋 메세지 Description

HunnitLog를 진행할 때 알게 된 것,,!

[#이슈번호] 해당 커밋 요약

[관련 링크이름](https://www.github.com)

## Description 
- 커밋 상세내용 1 
- 커밋 상세내용2

커밋 메세지를 위와 같이 작성하면

image

이렇게 ... 버튼을 눌렀을 때 해당 commit의 description을 볼 수 있다….!!!!
너무 멋있어서 이번에 잘 써먹어 볼 예정 ^___^b

링크 이름은 딱히 달 일이 없을 것 같아서 빼고
최종적으로

[#이슈번호] 해당 커밋 요약

## Description 
- 커밋 상세내용 1 
- 커밋 상세내용2

요렇게!

기타 등등

branch

피쳐별로 딸 건데 네이밍 컨벤션을 정해두고 싶다.

String, Color Asset

String이랑 Color 값들 Asset에 잘 정리해두기!

SwiftLint 좀 더 잘 써먹기

저번 프로젝트에서는 그냥 도입에 의의를 뒀다면 이번에는 진짜 알차게 써보기!

짤커밋

커밋당 파일은 1-2개 이상 넘어가지 않게! 짧게 끊어서 커밋
에셋 추가가 아닌 코드변경은 파일 체인지 한자리수가 되도록 노력 (한 PR 당)

Enum

얼마나 좋길래 해찌가 그렇게 썼는지 나도 함 써보자!