day.02가 회고가 될 줄이야. 그것도 새로운 주차가 시작되는 월요일에 지난주 금요일에 끝난 프로젝트의 회고를 작성하고 있다. 지난주에는 TIL을 쓸 여유가 하나도 없었다. "팀" 프로젝트라는 면에서 팀원들과의 협업은 만족스러웠지만 "프로젝트" 면에서는 만족감보다는 답답함과 박탈감을 많이 느꼈던 한 주였다. 결과물은 꽤 마음에 들게 나왔지만 그 안의 코드가 날 힘들게 했다고 보는 게 맞을 것이다.
Keep
Git 협업 경험
팀 프로젝트를 통해 가장 만족스러웠던 것을 꼽으라면 팀원들과 함께 깃 저장소를 꾸려나가며 깃 협업을 몸소 체험한 것이다. 나는 브랜치 전략과 룰이 뭔지도 몰랐는데, git-flow라는 전략을 알게 되었고(내용은 day.01에 정리함) 기능(feature) 별로 브랜치를 만드는 것도 알게 되었다.(브랜치 작명에도 컨벤션을 정했는데 재밌었다.)
혼자 실습한 걸 깃에 올릴 때는 되는대로 코딩한 걸 한꺼번에 커밋-푸시하곤 했는데, (그래서 커밋과 푸시의 기능이 거의 하나처럼 느껴졌었다.) 하나의 작업을 했을 때 하나의 커밋을 하는 습관을 들이는 연습을 하게 되었다. 그리고 커밋할 때도 그냥 하는 게 아니라, 팀원들과 정한 커밋 메시지 형식을 지켜서 작성했다. (커밋 컨벤션)
기능 별로 브랜치를 분리했기 때문에 하나의 기능이 완성될 때마다 Pull Request를 열게 되었다. 리퀘스트를 할 때도 커밋 컨벤션을 지켜서 메시지를 작성하고, comment에는 내가 작업한 내용을 소개하는 markdown을 작성했다.
PR에 대한 신기한 내용을 배웠는데 PR을 보낸 후에도 계속해서 commit 내역이 반영되어 merge 시점에 브랜치가 가장 최신 상태라는 점이다. 이건 base(머지 대상) 브랜치에도 마찬가지로 적용되는 내용인데, 내가 dev를 대상으로 PR을 올린 시점 이후에 dev 브랜치가 다른 feature 브랜치와 합쳐졌더라도, 내 PR이 승인되어 머지되는 시점에 dev는 최신 상태이므로 PR이 여러 개 쌓이고 다른 PR을 먼저 merge하게 되어도 코드 충돌이 더 발생하거나 하지는 않는다.
우리 팀은 초반에 PR과 merge에 대해 여러가지 이야기를 나누었는데, pull을 먼저 하고 PR을 올려야 되냐 아니냐가 화두에 올랐었다.
Pull Request를 올리기 전dev를pull하여 로컬에서 코드 충돌을 미리 해결한 뒤merge는 한번에 되도록 함Pull Request이후에 코드 충돌을 해결하고merge함
둘 중 어느 하나가 코드 충돌이 적게 나는 것이 아니라, 어차피 똑같이 나는 코드 충돌을 어느 시점에 해결하냐의 차이다. 이걸 정하는 건 코드 충돌을 해결하는 주체에 따라 다르지 않을까 싶다. 단일 기능을 작업하는 담당자 개인이 dev의 코드와 본인 코드 중에서 무엇을 살릴지 결정해도 괜찮다면,(경험 상 두 코드 모두를 살려야 하는 경우가 대부분이긴 했다.) 1번 방법도 쓸 수 있을 것이다. 우리 팀은 2번을 채택하여 깃과 코딩에 제일 능숙한 팀장님이 화면 공유를 통해 코드 충돌을 해결하는 것을 보여주며 merge를 진행하였다. 정말 충돌인 경우는 거의 없었고, 양 쪽 코드 모두가 새로운 코드여서 둘 다 살리되 코드 순서 정도만 조정했다. 1, 2번 중 뭘 쓰냐도 컨벤션일까? 1번의 경우 충돌을 스스로 해결한 뒤 PR을 올리는 점이 개인의 재량처럼 느껴진다. 만약 충돌 상황을 모두가 볼 수 있게 하고 살릴 코드를 정하는 것도 팀에 고지가 되어야 한다면 2번이 적절한 것 같다.
merge 방식도 이것저것 해보며 차이를 느껴봤다. (rebase 빼고)
Create a merge commit:merge를 했다는 사실이 새로운commit으로 남는다.merge이후feature의commit내역이 모두dev에 남는다.Squash and merge:feature의 모든 커밋 내역을(없애고)merge commit하나로 통합한다.Rebase and merge:feature의commit들이dev의commit으로 이어붙여진다.merge commit도 남지 않는다.
2번의 경우 내 커밋 내역이 다 사라지는 게 내 작업 기여도가 사라지는 것처럼 보여 별로라고 생각했는데,(심지어 커밋 잔디도 남지 않는다.) 프로젝트가 커지면 자잘한 feature 커밋 내역이 지저분하게 느껴지나보다. feature 브랜치와 dev 브랜치를 병합할 때는 squash가 적합하다는 글을 보았다. dev와 main 간의 병합은 rebase가 적합하다고 한다. 그런데 merge 했다는 내용도 추적이 필요한 초보자 단계에서는 1번이 제일 좋지 않을까 싶다. 우리 팀은 1번 머지 방식으로 결정했고, 만족했다.
merge commit도 merge: 하고 컨벤션 지켜진 커밋 내역 편-안.Problem
MVC 패턴 이해
정확히 말하자면
MVC패턴을 이해하는 건Problem이 아니고TIL이지만, 제대로 적용해보거나 적용하지 못한 코드를 고칠시간이 없었다는 게 Problem이다. 나는 이 부분 때문에 꽤나 무력감을 느꼈다. 제대로 된 코딩을 하지 못하고 바보 같은 코딩만 하다가 끝난 기분이기 때문이다.
이렇게 해도 동작을 하고 저렇게 해도 동작을 하는데 왜 패턴이라는 게 생겼을까? 먼저 이렇게저렇게 코딩해 본 사람들이 시행착오를 거쳐 이렇게 했을 때 단점을 줄이고 저렇게 했을 때 단점을 피하다보니 패턴이라는 게 생겼을 것이다.
나는 되는대로 만드는 것만 해봤다. 프로그래밍 방법, 패턴에 대한 지식은 없었다. 그래서 왜 서브 뷰 클래스 내부에는 동작에 관한 코드가 들어가면 안되는지 깨닫는 게 어려웠다. 지금도 나보다 더 잘 아는 사람이 그게 맞다고 해서 받아들이는 거지, 내가 완전히 실감하기 까지는 시간이 계속 걸릴 거 같다.
그래도 확실히 느낀 게 있었다. 서브 뷰가 서로 연관되어 동작할 경우, 정보를 주고 받기 위해서는 뷰 컨트롤러를 통해야 하고 그렇기 때문에 서브 뷰의 액션 코드나 델리게이트 코드는 뷰 컨트롤러에 들어가는 것이 맞다. 그리고 뷰 클래스가 모델이나 컨트롤러가 가져야 할 코드를 많이 갖고 있을수록(또는 그에 대한 정보를 많이 갖고 있을수록) 결합도가 높아진다고 표현을 하는데 이렇게 되면 나중에 유지보수가 어렵다. UI는 유지하면서 동작만 변경이 필요한 상황에도 뷰 클래스의 코드를 수정해야 하기 때문이다.
프로젝트를 하면서 이런 점을 느끼고 배웠다. 알고 적용했다면 제일 좋았겠지만 내가 작성한 코드의 안좋은 점을 깨달을 수 있어서 좋았다. 리팩토링 할 시간이 없었던 게 아쉽다. 그리고 이 패턴을 적용하여 데이터와의 연결 로직을 직접 구현해보지 못한 것이 너무 아쉽다. 팀원들과 각자 만든 뷰를 모아서 연결하고 나니 마감 기한이 코앞에 다가와 있었다. 새로운 주차가 바로 시작되지 않고 내게 일주일의 방학이 주어진다면 좋겠을 정도다. 직접 로직도 짜보고, 꼼꼼하게 리팩토링을 다하고 넘어가고 싶다. 지난 것을 완벽하게 정리하지 못하고 또 새로운 것을 마주해야 하니 마음이 무겁다.
Try
시간은 부족한데 공부할 거리가 너무 많은 건 어떻게 보면 물리적인 문제인데 내 노력으로 해결이 될지 잘 모르겠다. 물론 내가 더 빨리 학습하는 능력을 키우는 방향으로 해결해야 되겠지? 당장은 뭐가 너무 많아 막막한 기분이 드는 건 사실이다.
우선 이번 프로젝트에 지키지 못했지만 추후에라도 (시간이 허락한다면) 마무리 하고 싶었던 점들을 적어보고자 한다.
코딩 컨벤션: 팀원들과 각자 구현한 내용을 합치고 나면 다같이 코드를 쭉 보면서 코드 리뷰를 나누고 코드 스타일과 작명 등의 컨벤션을 논의하고 싶었는데 그러지 못했다. 다같이 모여서 할 수 있다면 좋겠지만, 어려울 것 같으니 나 혼자서라도 리팩토링 하며 코드에 통일성을 부여해보고 싶다.MVC패턴 :MVC패턴을 적용했다고 발표했지만, 사실 불완전하다.MVC패턴을 염두에 두고 코딩했다가 더 맞는 것 같다. 특히 로직 구현할 때는 패턴이 지켜지지 못하고 뷰 클래스와 모델의 결합도가 높아졌었다. 이 부분에 대한 리팩토링을 하고 싶다.- 데이터 연결 로직 직접 구현하기 : 시간이 부족하다보니 코딩에 능숙한 한 팀원이 도맡아 로직을 급하게 구현했는데, 내가 참여한 프로젝트인데 내가 이 프로젝트의 데이터 전달 로직을 완벽히 이해 못한 채로 마감했다는 게 창피하다고 생각한다. 시간을 내어 코드를 천천히 읽어보면서 동작 흐름을 이해하고, 내 스스로도 짜보고 싶다.
UIPageControl고치기 : 컴포넌트를 다 공부하고 구현할 시간이 없어서 코드를 갖다 썼는데 버그가 있어서 급하게 멀쩡해만 보이게 수정했었다. 주말이 되어서야UIPageControl을 제대로 공부했는데, 배운 내용을 토대로 제대로 작동하도록 수정해보고 싶다.- 카테고리 바 고치기 : 우리 팀 발표 때 튜터님께서 카테고리 바가
UIView와UIButton으로만 구성된 부분에 대해 피드백을 주셨는데, (카테고리가 여러 개 생길 경우 유지보수성에 대해) 그 내용대로 카테고리 버튼이 여러 개 생겼을 때도 제대로 만들어지려면 어떻게 해야하는지 고민을 더 해보고 싶다.- 전체 화면을 하나의
UICollectionView로 구성하기 : 이건 프로젝트 초반에 한 팀원이 제안하셨는데, 좋은 방법 같았고 어떻게 하는지 배우고 경험하고 싶었지만 과제의 취지는 각자 구현한 뷰를 컨트롤러에 모아 오토레이아웃을 적용하는(이 경험도 필요했다) 데에 있는 것 같아 무산됐었다. 이걸 발표 때 언급하자 튜터님께서 꼭 따로 적용해보라고 추천하셔서 이것도 해보고 싶다.
내가 구현한 내용을 기록하면서 회고를 마친다.
UICollectionView영역 (치킨 메뉴) :UICollectionViewFlowLayout- 카테고리 바 Button과 CollectionView
연결:addTarget,UICollectionViewDataSource- 페이징 :
UIPageControl,UIScollViewDelegateAlert:UIAlertController
