발표 자료 | Notion

기획 과정

프로젝트 설정	이름, 목적 정하기
기능 구현	어떤 기능을 구현할 지 정하기
와이어프레임	정한 기능을 바탕으로 와이어 프레임 구현
담당 분할	각 팀원이 어떤 기능을 맡아 개발할 지 정하기
컨벤션	깃, 코드 컨벤션을 정하여 코드를 일관성있게 작성할 목적 가지기

개발 진행

MVC	Custom View를 활용한 Massive View Controller문제 해소 시도
객체지향	객체지향 원칙을 적극적으로 활용하여 유지보수성 높은 코드를 작성하려고 노력했습니다.
SRP: UI 속성 설정, 업데이트, 데이터 할당등으로 메서드 역할을 분류하여 srp를 준수하려 노력했습니다.
캡슐화: Custom View 안의 모든 UIComponent를 private 접근 제어자를 사용하여 캡슐화하였습니다.
Delegate pattern	Delegate객체에 해당 이벤트처리 역할을 전담함으로 의존성 감소

경험한 이슈

병합 충돌 해결	상단 카테고리와 메뉴 목록 부분 연결을 위해 작업을 하던 중 동일한 부분을 수정하며 충돌이 발생했습니다. 기존 브랜치에 영향을 주지 않고 개별적으로 작업하기 위해서 새로운 브랜치인 dev를 만들어서 해결했습니다.
HeaderView <-> MenuView 메뉴 선택	CollectionViewCell의 UIComponent 들을 캡슐화 하는 과정에서 private 접근제한자 때문에 view에서 직접 접근이 되지 않아 에러가 발생했습니다. HeaderView와 OrderView에서 cell 컴포넌트에 데이터를 할당해주는 이벤트를 cell 클래스에서 메소드화하여 해결 하였습니다.
MenuView <-> OrderListView 데이터 이동	MenuView 에서 인스턴스를 새로 생성하여 데이터 일관성에 이슈가 발생하였습니다. View 간 효과적인 데이터 이동과 의존성 감소를 위해 Delegate Pattern 을 활용하여 해결하였습니다.
	데이터 일관성 → 인스턴스를 새로 생성하면 새로운 객체가 만들어지기 때문에 기존의 데이터와 별개의 데이터가 생성됩니다.. 아무리 업데이트를 해도 계속해서 새로운 인스턴스를 생성하여 업데이트 하기 때문에 데이터 이동에 문제가 생깁니다.
	메모리 관리 이슈 → 인스턴스를 계속해서 새로 생성하다보면 메모리 사용량이 증가합니다. 따라서 아마 98퍼센트 확률(농담)로 메모리 누수&성능 저하가 발생합니다

강점?장점? 둘다인듯..

| 폴더링 | | 전역에서 쓰이는 Global 폴더와 UI에 직접 관여하는 Presentation 두가지 폴더로 프로젝트 내 디렉토리 구조화 각 모듈의 책임을 분명히 하여 가독성 상승 코드의 유지보수성 향상 기능 변경 시에도 빠르게 대응 가능 | | --- | --- | --- | | 깃허브 | Git Flow | 깃 브랜치 전략 사용 | | | 브랜치 보호 | Merge Rule을 정하여 브랜치를 보호

Require approvals(2): 2명 이상의 승인이 있어야 병합 가능
Require conversation resolution before merging: pr 내 모든 conversation이 해결되어야 병합을 가능 → 꼼꼼한 코드리뷰 및 소통 지향 | | 협업 | 코드리뷰 | i. 활발한 코드 리뷰를 통해 일관성 있는 코드 유지, 피드백을 통해 팀원간 지식 공유 ii. Pn룰을 사용하여 리뷰어가 코멘트를 강조 하고 싶은 정도를 설정, 둥글지만 명확한 소통 분위기 조성 | | | 회의 | 매일 아침 스크럼을 통해 진행 상황 공유하여 일정 관리 저녁 회의를 통해 문제에 대한 토론 진행하여 해결책 강구 | | | 노션 페이지 활용 | 프로젝트 일정, 작업 내용, 레퍼런스, 결정사항 등 효율적 공유 프로젝트 이해도를 높임 | | 컨벤션 | 코딩 컨벤션 | i. 코드 스니펫을 활용하여 통일된 MARK: 주석 사용 ii. Class 내부는 property, lifeCycle 메소드 제외 모든 구현은 익스텐션에서 함으로 코드 구조화 | | | 깃 컨벤션 | i. 이슈 템플릿, pr템플릿활용 → 간편하고, 누락 될 수 있는 사항 최소화 ii. 브랜치명, 커밋 메시지, pr 컨벤션을 정하여 일관성 있게 작업 iii. 기능별 이슈 발행으로 작은 pr 지향, 충돌 최소화 |

후기?

ㅊㅇㅇ	스토리보드를 사용하지 않고 Code base로 UI를 구현하며 UIComponent와 AutoLayout에 대한 많은 공부를 할 수 있었습니다. 코드 스니펫같은 기능도 새롭게 알게 되어 유용하게 사용했습니다. Delegate Pattern 에 대한 이해도도 높일 수 있는 기회였던 것 같습니다. 깃허브 코드 리뷰 기능을 사용해 본 건 처음이었는데 팀원들과 의견을 모으고 정보를 공유하며 큰 성장을 경험할 수 있어 재밌었습니다.
양준현	기획단계에서 코드베이스로 구현함으로써 충돌을 줄일 수 있는 방법을 경험하였고, 한 개의 ViewController에 폴더링으로 글로벌 - 익스텐션 - 컴포넌트 - 프리젠테이션(뷰, 셀, 모델 등)으로 구성함으로써 체계적인 기능구현 경험을 할 수 있었고, 협업 간 개인의 뷰와의 연결, 데이터를 주고받는 기능을 구현해볼 수 있었음 그리고, 깃허브를 통해 커핏-푸시-풀-이슈-PR-Review를 통해 협업의 업무관계에 대해 이해할 수 있는 좋은 기회였음 추가적으로 다른 팀원들의 기능구현을 통해 내가 생각하지 못하고 발견해내지 못한 swift의 기능에 대해 알아 볼 수 있었음
최유리	스토리보드를 사용하지 않고 코드로만 구현해본 건 처음인데 어렵지만 배운 점이 많았다. 특히 깃허브를 많이 사용해볼 수 있어서 좋았다.
백준	라이브러리 없이 nsLayout을 사용하여 오토레이아웃을 잡는 방법에 더 익숙해 졌습니다.
매번 큰 생각 없이 사용하던 lazy 키워드와 sceneDelegate에 대해서 더 이해하는 시간을 가졌습니다.
좋은 팀원들과 편안하고 둥근 분위기 속에서 즐겁게 개발했습니다.
개인적으로 이번 프로젝트 때 rebase를 사용해보고 싶었는데 못해서 아쉬웠습니다.