앞으로 이런 일이 또 발생할 수 있기에 스토리에 대한 브랜치를 어떻게 준비할 지 생각해보았다
스토리를 하나의 feature 브랜치로 보고 작업내용에 대한 서브 브랜치를 따로 시작하는건 어떨까
커다란 feature 안에 작은 feature들이 여러개 존재하게 되고 merge 한 후 feature를 다시 develop으로 가는 것
이는 작은 단위 작업에 대해 불필요하게 많은 PR이 생성될 것 같다
커밋과 PR 단위를 작게 하는 것이 좋다라고 하지만 결국 하나의 스토리 개념이 있기에 좀 더 크게 묶어도 되지 않을까?
다른 방안은 예전에 사용했던 방식인데 스토리에 대한 브랜치를 만들고 커밋내용으로 하위 작업 내용을 남기는 것
feature/card-1 브랜치 + card-2 하위 작업 내용에 대한 커밋
당연한 계획은 없었다 -> 언제 어떻게 변경 될 지 모르는 상황 -> 커밋, 브랜치에도 스크럼
11/22 ~ 11/28
스프린트
애자일, 스크럼, 스프린트
애자일: 개발 -> 피드백 -> 개발 -> 피드백 전환을 짧고 빠르게 가져가는 방법론
스프린트: 제품 기획부터 개발, 리뷰까지 한 사이클
스크럼: 애자일 방법 중 하나로 팀을 이룬 팀원들 스스로 역할을 분배하고 책임
칸반
지라보드를 잘 사용해보고 싶은데 에픽, 스토리, 작업, 버그 차이점은 무엇일까
에픽: 스토리의 집합
스토리: 사용자의 행동, 기능
작업: 스토리를 완성하기 위한 작업물
버그: 오류 사항 발생
에픽 > 스토리 > 작업 그리고 버그
하나의 에픽을 스프린트로 가져가면서 릴리즈 처리가 가능해 보이는데 막상 사용이 어렵다
네트워크
공부한다고 했는데 여전히 아는게 무엇인지 찾을 수 없다
게이트웨이, 서브넷 분명 들어보았고 알듯하지만 확실하지 않다 === 모른다
나만을 위한
하루를 4시30분에 시작한다라는 책을 보았다
새벽에 일찍 일어나는 것에 의미가 있다기보다 오직 나만을 위한 시간을 보내기 위해 아침에 일찍 일어나 하루를 시작하는 것
저녁에 야근하거나 약속을 잡거나 쉬고 싶다는 이유로 아무것도 하지 않거나 나중에 아쉬운 시간들을 보내는 경우가 많다
작심삼일이지만 루틴을 만들어보겠다고 노력하지만 저녁시간은 내 뜻대로만 되지 않는다
그럼 아침에 나를 위한 시간을 갖는다는 것은 좋은 방법인데!!!?
최근 아무 생각 없이 수학문제를 푼다거나 공부하고 책보는게 재미있다
그러다 시험을 보는게 목적이 아닌 정말 학문을 위해 공부를 한 적이 있었던가? 하는 생각을 해본다
11/15 ~ 11/21
runtime error
타입스크립트 리팩터링을 진행했다
1차 오류를 여기서 심어버렸다
타입스크립트로 바꾸면서 이제 에러는 런타임이 아닌 컴파일에서 알 수 있겠지라는 생각으로 바꾼 코드의 결과값만 테스트하였다
사이드이펙트로 발생하는 것들이 있으리라고 생각치 못하고 기능 테스트를 하지 않았다
2차 오류는 혹시나 하며 지나친 것들이 역시나 하며 다가왔다
useEffect dependency가 빠져있는 것들을 추가하면서 의도치 않은 변경이 발생하였다
두가지 오류 모두 미리 확인 할 수 있었고 예방 할 수 있었다
그러나 나의 오판과 오만이 오히려 화가 되었다
커밋 히스토리 마저도 지키지 못했다
쉽게 보고 바로 release 브랜치를 열었는데 결국 다시 QA로 돌아왔으며 현재 히스토리는 갈 곳 잃은 거미줄이다
testing-library
유틸리티 함수만 테스트 코드를 작성했었다
컴포넌트 테스트를 어떻게 하는건지 몰라서라는 핑계
feconf, deview 여러 발표를 듣다보면 할 수 있을것만 같다
coverage 측정
개발자
모름을 알고 있는 개발자
주도적으로 시도해보고 생각해보는 개발자
11/8 ~ 11/14
RN android
지난번부터 이상하게 나를 괴롭힌 이것
java.lang.RuntimeException: Unable to load script. Make sure you're either running a Metro server (run 'react-native start') or that your bundle 'index.android.bundle' is packaged correctly for release.