[AsyncSwift Korea Seminar 002] Review

 

 

AsyncSwift Seminar 02

---

타다 : Core를 잘 다루는 타다의 상태 관리 기술

김남현 님
VCNC | Facebook, LinkedIn

9월 16일자 기술 블로그에 잘 정리되어있었다.

타다 TECH BLOG

발표가 군더더기 없이 필요한 내용으로만 구성되어있어서

Redux를 모르는 나조차도 이해할 수 있을정도의 큰 그림을 차근차근 설명해주셨다.

이런 CTO님 밑에서 배우면 진짜 좋을 것 같다는 생각에 궁금해서 iOS 개발직군 채용 정보를 살펴봤다.

신입도 모집을 한다...! 😳

---

쿠팡 : Why? MVVM

권문범 님
Coupang | Blog, Medium, LinkedIn

왜 사용하는지에 대한 본인만의 생각이 있는게 중요한 것 같다.

1. 각 코드의 역할과 책임을 분명히 한다.

2. 선언적 코드를 활용하여 동적인 코드를 통제한다.

3. 비지니스 로직의 방향성을 가시화하여 파악을 쉽게 한다.

4. 동시성 프로그래밍에서 생기는 Side-effect를 최소화 한다.

 

이 세션에서는 주로 듣기만 했다.

MVP와 MVVM에 대한 차이를 잘 설명해주셔서 좋았고,

가장 궁금했던 왜 필요한지를 알게됐다! (이건 차차 정리해서 글을 따로 쓰는걸로)

---

코드리뷰 - 같이 성장하기 위한, 그리고 성공하기 위한 팀이 되기 위한 도구

김우성 님
29CM Mobile Unit Lead / iOS Lead | Facebook LinkedIn Blog

개인적으로 가장 열심히 들었던 세션!

협업 경험도 부족하고, PR를 제대로 해본 경험이 없어서 전혀 모르던 부분을 콕콕 짚어주셨다.

---

7가지 발표 주제

1. 팀에 Pull Request가 필요한 이유

2. 팀의 생산성을 낮추는 PR

3. 좋은 Pull Request 이란?

4. PR 중심으로 협업하는 팀이 되기 위한 기술들

5. 좋은 PR을 작성하는 방법

6. PR 리뷰하기, 리뷰를 통해 어떻게 서로 성장할 것인가

7. 실제 사례들 (Good & Back)

---

내용을 요약해보자면

Pull Request는 전산 처리 작업 요청서와 같은 문서다.

그런데 커곧내(커밋이 곧 내용), 본인만 아는 맥락이 담긴 PR,

이 작업에 대한 당위성에 대해 이해하기 어려운 PR, 너무 큰 단위의 PR 등을 PR 해버리면 팀의 생산성을 낮추게 된다.

리뷰어 입장에서 코드 리뷰를 하기 어려운 경우가 잦게되기 때문인데, 이를 개선하기 위해 몇 가지 개선한 경험을 공유해주셨다.

 

잘 작성된 PR은 지식 아카이브(Knowledge Archives) 와 같다.

여러 시행착오를 거쳐 현재는 대략 아래와 같은 내용으로 나름의 PR 규칙을 세웠다고 한다.

• PR 작성 단위는 하나의 컨텍스트만을 가진 최소 의미 단위 PR을 지향
• `diff`를 최소화
• 리뷰에 방해가 되지 않은 선에서의 리네이밍, 리팩토링은 별도로 PR
• 에픽을 진행하고 있는 경우 한 PR이 하나의 기능을 담도록 작성

이 내용이 모두 포함될 수 있도록 나름의 양식 또한 존재했다.

위 스타일을 적용시킨 결과 오른쪽 이미지와 같이 정리된 문서로 PR을 할 수 있게 됐고,

코드 리뷰하기 수월해졌으며, 릴리즈 주기가 주 1회로 짧아질 수 있었다고 했다.

---

그럼 위 양식을 가지고 어떤식으로 작성하면 될까?

1. RXSwift 레포에 기여하는 느낌으로

2. 스마트폰에서도 리뷰할 수 있는

3. 풍부한 맥락

4. 리뷰어가 고민하지 않도록

5. 코드의 양은 적게, 본문의 양은 많게

---

저맥락 PR vs 고맥락 PR

날로 먹을 수 있는 PR 따로, 신중하게 리뷰해야하는 PR 따로

이 두가지 종류를 동시에 PR 하게 되면 5분 내로 승인할 수 있는 것도 승인이 미뤄지게 된다.

---

PR 리뷰를 통해 성장하는 방법은 뭐가 있을까?

• 글로 업무를 정확하게 표현하기
• PR을 리뷰하는 속도 높이기
• PR을 리뷰하는 깊이 더하기
• 도메인/기술 지식 익히기

---

이외에도 여러 팁과 경험을 공유해 주셨는데

테스트 코드로 확인하기 어려운 부분을 이미지 형태로 담아주면 좋다거나,

피쳐 플래그를 통한 빌드 분리를 통해 realese 주기를 1주로 줄일 수 있게 됐다거나,

코멘트 레벨 도입(From 뱅크샐러드)하고 emergency, needs-healing 등의 PR 레이블 활용하여

신입이 모든 코드 리뷰에 대해 반드시 반영해야한다는 부담감을 줄여줄 수 있었고,

코드 리뷰 커뮤니케이션 프로토콜 - 이모지 활용, Resolve 금지 등의 규칙으로 단순한 단방향 커뮤니케이션이 가능해졌다 등등

현업에서 일어나는 일들을 간접적으로 알 수 있어서 개인적으로 가장 흥미로운 주제가 아니였나 싶다.

---

커밋은 항상 유의미 해야한다! 는 점이 이 세션의 키포인트라고 할 수 있겠다.

좋은 PR을 작성할 줄 아는 개발자는 가독성 높은 코드도 잘 작성하는 것 같다는 개인 경험도 공유해주셨다.😌

앞으로 티스토리 글쓰기를 연습 삼아 가독성이 좋은 글을 쓰도록 해야겠다!

---

내일 지구가 멸망하더라도 테스트는 같게 동작해야한다.

김찬우 님
원티드랩 교육사업팀 | LinkedIn, Homepage

테스트 하는 법, 테스트는 왜 필요할까?

불확실한 상황을 예측하여 테스트를 해야하는데 이걸 어떻게 할 수 있을까?에 대한 내용이었다.

 

카페에서 신입을 교육하고 난 후 교육이 잘 되었는지를 어떻게 확인할 수 있는지 2가지 방법을 가정할 때

1. 그냥 손님 받기 - 악으로 깡으로 버텨!

2. 가짜 손님 섭외 - 각 상황 다 시켜보기

의 예시를 들어 이해하기 쉽게 설명해주신 세션이었다.

(글이 너무 길어질 것 같아서 자세한 설명은 생략)

---

회고

하루종일 책만 들여다보다가 세미나 3시간이 넘는 세미나를 들으니 은근 리프레쉬(?)가 됐다.

특히 김우성님과 김남현님의 세션이 상당히 흥미로웠다! ㅎㅎ

현업에서 겪었던 문제들과 그런 문제를 어떤식으로 해결했는지에 대한 해결 과정을 볼 수 있어서 좋았다.

그리고 이전에 강연하셨던 분들의 깃허브도 하나씩 들어가서 PR를 어떻게 하셨는지 보는 것도 재밌었다.

 

오늘 들었던 여러가지 생각을 나열해 보자면,

1️⃣ 익숙하지 않은 도메인/기술에 대한 자세한 기록을 남겨서 공부되는 PR을 지향해야겠다.

2️⃣ (아래와 같이) Interactive Rebase, Fixup commit과 같은 자주 쓰는 Git의 주요 기능을 정리하고 되도록 외워둬야겠다.

3️⃣ 코드리뷰 하는 사람이 궁금해할만한 질문을 미리 풀어주는 방식으로 PR 작성하는 습관을 들이면 좋겠다.

 

---

지난 AsyncSwift 정보

AsyncSwift Seminar 01