3월 한달동안

• 아쉬운점
  • 주말에 시간을 투자하지 못했다
  • 시간이 있어서가 아니라 만들어 낼 수 있지 않았을까 싶다
  • 그렇다면 평일을 생각 해보지 않은 것도 아쉬운 점
• 잘한점
  • 어느정도 커다란 루틴이 잡혀간다
  • 1분기 계획으로 잡았던 것을 아슬아슬 하지만 성공했다(고 생각중)
• 개선할점
  • 좀 더 상세하게 잡아보는게 어떨까
  • 지난달과 마찬가지로 시간을 돌아보며 쪼개보는 것이 좋겠다
  • 지난일 내려놓기

쏙쏙 함수형

• 쏙쏙 들어오는 함수형 코딩 으로 쉽게 읽어보았던
• 액션/계산/데이터
• 액션과 계산을 분리하여 순수함수인 계산만 테스트 할 수 있도록
  • 필요한 모든건 파라미터로 (=외부주입)
• 계산이였으나 내부에 데이터나 액션이 생기면 그것은 액션이 되어버리는 것
  • 항상 같은 입력에 대해서는 같은 출력이 되어야한다
• 액션과 계산을 최대한 분리하는 것을 시도해본다
• 근데 불변성을 유지하기가 조금 까다롭겠다 느껴지는 예시들을 보았는데 🤔
  • immer가 떠오르는 것은 무엇
• 같은 책에 대한 내용의 글이 많다

RN PR

• 그냥 pull to refresh를 구현하고 싶었는데
  • 그랬을뿐인데...
• RN에서 네이티브로 거슬러 올라가다가 우연히 오타를 발견했다
  • 자꾸 검색이 안되는데 무언가 이상함을 감지
  • control 아니고 contol
• 단순한 오류 메세지 수정은 해본 적이 있지만
• 이번에 수정하려는 내용들을 보니 코어 로직에 해당했다
• 그럼에도 자신있게 PR을 올렸는데
• 아주 빠르게 코멘트를 받을 수 있었다..!
  • 이건 안댕~
• 그 이유는 코어 로직인데 하위 버전에서 이미 오타난 프로토콜을 사용중인 사용자들이 있을 것이고
• 이를 수정하고 버전을 올렸을때 오류가 발생할 수 있으니
• deprecated 된걸 충분히 안내하고 나서야 제거하는 방향이 안전한 것
  • 프로토콜인데 왜 영향을 받을까? 하는 생각을 해보았는데
  • 예를 들면 아주 간단하게 최근에 적용했던 Swizzle+Protocol 자체로도 충분히 오류 가능성이 높았다
    • Swizzle 구현할때 참고했던 참고: Swizzling!
  • 내부 로직을 확장 구현해서 쓰고 있는데 있던게 없어져버릴테니....
• 그래서 의도치 않게 단순 오타 수정에서 프로토콜 자체를 수정해야한다는 것을 깨닫고
  • 그냥 PR 닫을까 싶었지만 한순간의 오타 수정에 취해 올려버린 PR 어디 한번 끝까지 해보자는 마음으로...
  • 왜하필 iOS.. 왜하필... 헬게이트라고 생각했다
• 하지만 이런 나를 알아봐주는 아주 친절한 코멘트
  • 스텝바이스텝 친절하게도 요렇게저렇게 PR을 수정해주세요~~
  • 알려준대로 따라하기만 했을뿐
  • 잘 마무리 되었다
• (중간에 생긴 궁금한 점)
• deprecated 프로토콜을 안내하기 위해 message를 남기고 있는데 (__attribute__ ((deprecated)))
• 이게 빌드할때 안내하리라 기대했는데, 빌드/런타임 모두 확인하지 못했다
• 그럼 이게 언제 확인되는거람?
• 참고

제품 테스트

• 참고: 나도 내 코드의 문제를 찾고 싶다구요
• 코드 테스트라고 생각했지만 제품 테스트에 대한 이야기
• 테스트를 하려면 요구사항이 무엇인지 먼저 정확하게 알아야한다
  • 요구사항 > 테스트 케이스 > 인터페이스
  • 이 순서가 TDD로 보인다!
• 언제 제품을 처음 만날까?
  • 요구사항 > 분석 > 구현 > 테스트 > 배포
  • 제품이란 실제로 눈으로 볼 수 있는 테스트 단계에서 만나게 된다
  • 이때 요구사항을 기준으로 테스트 하는데
• 요구사항은 언제 정의될까?
  • 분석 단계에서 요구사항에 대해 질문하게 된다
• 요구사항을 만족하는지 제품을 실제로 보고 확인해보는데
  • 유저 테스트가 고객의 요구사항을 가장 가까이 가는 이유
  • 고객 입장에서 생각하는 것
• 악마의 유혹
  • 너무 간단해서
  • 너무 의존성이 많아서(=귀찮아서)
  • 내 눈이 아니라 컴퓨터가 합격의 목걸이를 걸어주도록

코드리뷰가 잘 진행되기 위해

• 나와 팀을 성장시키는 리뷰들과 비슷한 흐름으로
• 참고: 코드 리뷰의 또 다른 접근 방법
  • PR 사이즈가 작을수록 작업의 목표가 명확해지고 리뷰는 빨라진다
• 내가 PR을 만들게 된 이유
  • A 기능 추가
  • 이 하나의 기능을 추가하는 목적이였는데
  • 엔드포인트 올리고 화면 그리고 잠깐 스쳐지나간 고민의 흔적 수정하고
  • +1000/-200
• 항상 하나의 PR에 하나의 목적으로 최소한으로 하기를 꿈꾸지만
  • 순식간에 불어나버린 나의 PR
    • LGTM 👍
• 눈덩이처럼 불어나버린 PR + PR + PR
• Stacked Changes
  • feature/A 를 base branch로 삼는 feature/B
  • feature/B 를 base branch로 삼는 feature/C
  • base branch를 모두 develop으로 하는 것이 아니라 의존관계에 있는 branch를 base로 가져가는 것
• 의존 관계에 있는 브랜치라고 생각하는 것은
  • 스택에 쌓여있으니 모두 구현이 완료 되려면 스택 친구들이 함께 가야하기 때문에
• 🤔 하나의 피쳐를 스택으로 쪼개는 것은 리뷰를 잘 진행하기 위해서 필요한 것
  • 하지만 하나의 피쳐를 여러명이 동시에 진행하고 있을때
  • A에서 병목 걸리면 조금 난감할 수 있겠지만
  • 크게 바라봤을때 리뷰 자체를 빠르게 진행할 수 있는 방법

주도적으로 일하는 개발자

• 제품에 대해 이해하고, 책임감을 가지고, 주도적으로 일한다는 것
  • 참고: 주도적으로 일하는 개발자 되는 방법
• 제품에 대한 이해
  • 어떤 사용자를 위해
  • 어떤 영향력을 주기 위해
  • 어떤 기능이 필요한지
• 세상에 긍정적인 영향력을 주는 그러한 제품
  • 제품의 방향성
• 제품에 대해 이해하려고 해야 한다
  • 개발자의 일은 코드를 작성하는 것에서 끝나지 않기 때문
  • 개발자이기 이전에 팀의 일원으로서 제품에 대해 함께 고민해야 할 책임
• 요구사항과 문제를 명확히 하여 해결 방법을 구현해내고 테스트를 거쳐 사용자에게 도달하기까지
  • 참고: 나와 팀을 성장시키는 리뷰들
• 리뷰라는 것을 좀 더 큰 의미로 본다면
  • 우리가 올바른 방향으로 가고 있는지 확인하는 것
• 리뷰에 집중하는 이유
  • 일이 제대로 진행되고 있는지 아닌지
  • 나쁜 냄새는 빨리 발견할수록 좋기 때문에
  • 성장을 위해
• 보통은 코드리뷰만을 진행하는데
  • 일을 하는 모든 단계마다 리뷰를 진행한다면?
• 요구사항 분석과 설계, 구현 단계에서도 리뷰는 아주 중요하다
  • 우리가 하고자 하는 것이 무언인지 정의하고 어떤 것을 어떻게 구현할 것인지
• 테스트를 통해 요구사항 구현이 완료되었는지를 확인하는데
  • 이 테스트 또한 리뷰가 필요하다
  • 테스트 코드 자체에 오류는 없는지 시나리오에 문제는 없는지 등
• 각 단계의 리뷰를 통해 공동의 목표를 향해 올바른 방향으로 가고 있는지 확인하고 함께 성장할 수 있다
  • 각 단계의 리뷰, 방향성을 확인하고나니 떠오르는 애자일