오늘의 주제

chapter 16

각자의 스케줄링 전략이 다른 것 같다!
재영: 무조건 순서대로 하는 편이에요. 조그만 것을 먼저 하다보면, 권태로워지는 경향이 있어요.
- 먼저 온 리뷰를 빠르게 쳐내는 데 집중하는 편이에요. -> 오전에 할 일을 최대한 빨리 해놓고, 오후 3~4시부터 리뷰에 집중하는 편이에요. 리뷰의 품질을 높이려 노력해요. (직접 실행해보기 / 개발 타입같은 것들 다르게 최적화할 수 있는지 등 / 구조도 바꿔서 짜보고 제안하는 편)
- 피로도는 있지만 쪼개는 것이 좋은 것 같다. -> 작업자 1의 피로도에 비해 N명의 이해도를 높이는 효과
보성: 단위 별로 쪼갬. (태스크 - 브랜치) -> PR이 많아짐. -> 전체 속도의 합을 봤을 때 빨라졌던 경험이 있다.
- ex) 옛날 코드 -> 수정하기 힘듦. -> 리팩토링 수반 -> 리팩토링에 집중하게 됨 -> 커질 수록 보기가 힘들어짐 -> 둘을 나누면서 빨라짐.
- D-Day 라벨을 붙이는 컨벤션 -> 날짜에 임박할 수록 긴급도를 자연스럽게 전달.

주인의식이 제일 중요한 것 같다. 아무리 문화를 만들어도, 이 문화를 향유하는 사람이 주인의식이 없다면, 결국 관리하는 것이 제대로 돌아갈 수 없다.
PN룰.
라포(신뢰자본) 형성
- 코드 리뷰를 지적할 때 발생하는 마찰을 줄이기 위한 신뢰감을 서로 형성해야 함.
서로의 지식이 다를 때(내가 당연하게 알고 있는 것을 설득해야 하는 경우)
1. 서로 공부를 같이 하는 문화를 만들어야 함. (스터디)
2. 근거 기반 제시(이런 걸 참조하면 좋아요!)
스프린트, 스쿼드, 데일리 스크럼
작게, 투명하게 모든 태스크가 공유되어야 함
글 쓰고 이야기하기
설계만 PR 미리하기. 테크스펙을 기술 + 리뷰하는 것.
- 추상 컴포넌트 인터페이스 설계

관심사 높은 것끼리 분리해놓으면, 응집도가 높은 코드다.
관심사 높은 것끼리 분리했을 때, 반복되는 코드나 개선할 부분이 더 잘 보이게 되고, 따라서 이러한 파급효과로 코드 정리가 더욱 활발해질 가능성이 높아진다.