START
ToDoList Refectoring
점진적 성장을 위해서 지난주 Weekly Mission(feat. 페어프로그래밍)이었던 TOVA ToDoList 를 리팩토링하기로 했다.
앞으로 수정할 이슈
- 폴더 정리
- 컴포넌트명 / jsx & css
- parseObejctToList.js 삭제 (서버 생기면서 사용안하는 깊은 복사 함수)
- is_done checkout이 서버로 put 요청이 안되는 이슈
- 수정하기 눌럿을 때 input 박스에 원래내용이 담겨있어야하는데 없음.
- checkbox 크기가 지멋대로 작아지고 커지는 이슈
- 리팩토링 - useHttp setter 쓴거 안쓰고 하는 걸로 바꾸기
- TodoItem
- let { id, is_done, content } = item;
- item.id 나 item.content 처럼 사용하는 것과, 그냥 구조분해 할당으로 가져온 id, content를 사용하는 경우를 정리해서 통일 시켜야 함
- Swiper과 Drag&Drop 구분
- Done 클릭 시 가장 아래로 가도록 하는 기능 구현
- 해당 날짜의 todo가 다 완료될 시 dot이 check로 변하는 기능 구현
- 공유하기 버튼 옆에 남은 할일 표시 기능
- User Info 페이지 UI 구현
Temp 컴포넌트 리팩토링 - 추후- 벚꽃 관련
- 공유하기 기능
- 링크가 복사됨
- 미리보기로 사진과 버튼이 공유됨
- 사진이 불가능 하면 해당 페이지로 이동 가능한 버튼만 생성
- codoit 로고 눌렀을 때 새로고침 or
/경로로 이동 가능하도록 하기
현재 만든 이슈 리스트를 github Issue로 만들었고, 이는 github의 project에서 관리되도록 설정했다. (milestone은 추후 설정할 예정이다)
Close #num처럼 PR에 이슈 번호를 포함해서 생성하고, close를 하게 되면 연결된 project에서 done으로 바뀐다.
- commit 단위로 close할지, PR 단위로 close할지는 아직 결정하지 않았다. 아마 PR 단위로 할 듯하다.
CryptoMeter 1차 프로젝트 시작!
프로젝트에 대한 내용은 새로운 시리즈로 포스팅할 예정이다.
협업 툴과 컨벤션을 정하는 것에 많은 시간을 쏟았다.
STOP
TIL과 WIL을 굉장히 미루고 있다..
꾸준함이 강점이었던 예전의 나와 다르게 프로젝트에 들어가니 틈틈히 정리하는 것이 어렵고, 삽질을 많이 해서 시간 분배를 잘 하지 못했다.
특히 ToDoList 페어프로그래밍을 하면서 미루기 시작한 TIL과 WIL이 점점 부담으로 다가오고 있다.
역시 강의를 들을때와는 방식이 달라져야한다.
문서화 습관들 들여야한다.
이슈가 발생했을 때 빠르게 캐싱해놓을 수 있는 툴을 찾아봐야 할 것 같다. 노션은 생각보다 많이 느려서 매번 정리해야지 하다가도 로드가 느려 정리하지 않고 이슈를 해결하게 된다.
Continue
청계천 드래곤 면접 스터디는 순항 중..
매일 30분씩 돌아가며 면접 질문을 내고, 답변하는 스터디는 매일 잘 진행되고 있다. 다만, 멘토링, 프로젝트 회의 등으로 시간이 겹칠 경우 미리 양해를 구하고 있다. 평상시의 실력을 향상 시키기 위한 스터디이기 때문에 부담이 없어서 좋다.
클로바로 녹음을 하자는 의견이 나왔지만, 즉각적인 피드백을 해주는 것이 더 좋고 기록을 상세하게 하게 되면 부담이 커질 것 같아서 보류 중이다.
한사람이 답변을 할 때 다른 사람들이 노션에 피드백을 노트하고, 답변이 끝난 후 돌아가면서 구두로 피드백을 주고 있다.
What I Learned
리액트 라우터에 대해
리액트 라우터가 리액트에 종속되어있는 기능이 아니라, 또 다른 라이브러리인 것을 처음 알았다. 약간 디폴트로 사용하는 기능이라 당연히 내장 기능이라고 생각했는데 신기하다.
라우터의 다양한 커스텀 훅을 사용하는 법에 대해 익혔고, SPA에 대한 라우팅을 자유자재로 할 수 있게 되었다.
Agile 특강
프로젝트에 앞서 product team의 님께서 특강을 진행해주셨다.
변화하는 고객의 요구 사항에 대응하는 민첩한 (Agile) 개발 방식
애자일에도 다양한 방법론이 있지만 그 중, Scrum이 가장 대표적이다.
- 칸반, Lean, XP, FDD 등..
워터풀 vs 애자일
- 워터풀은 상품을 제작 한 후, 고객을 설득하는 방식이라면, 애자일은 고객과 소통하면서 유연하게 제작을 하는 것
- 애자일 소프트웨어 개발 선언
- 즉, 공정과 도구보다는 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를, 계약 협상보다 고객과의 협력을, 계획을 따르기보다 변화에 대응하기를 가치있게 여긴다.
Kanvan vs Scrum
Kanvan
- 간판처럼 작업 티켓을 Todo, Testing, In progress, done 섹션으로 나눠서 둠
- 작업 시각화를 통해 모든 작업을 다함께 공유하여 업무의 가시성을 확보 → 업무 효율화
- Work In Process(In Progress) 수에 제한을 둠’
- 보통 작업 단위가 작을 때 용이함
Scrum
- 고객 피드백을 빠르게 수집하고 통합할 수 있는 학습 루프를 만들어 지속적으로 해결
- 스프린트 간격을 통해 제공 가능한 작업을 완료함 (보통 1~2주 단위로 스프린트를 함)
- 각 스프린트 별 공동의 목표를 끝맞치도록 함. 따라서 스프린트의 시간적인 목표를 달성하는 것도 중요함.
- 경험 기반
- 학습 비용이 들고 관리 비용도 더 들지만 매 스프린트의 공동의 목표를 정하고 완수하면서 더 목적 지향적이기 때문에 높은 퀄리티를 보장할 수 있어 인기기 많다.
왜 스크럼을 하나?
스타트업에서는 칸반보다 스크럼이 더 인기가 많다. why?
스크럼의 5가지 가치
- COURAGE - 팀원 간 갈등 도전을 통해 작업하는 용기
- FOCUS - 확약한 것의 실천에 전념하는 것
- COMMITMENT - 약속한 것을 확실히 실현
- RESPECT - 자신과 다른 사람에게 경의를 표하는 것
- OPENNESS - 어떤 것이 자신에게 불리해도 숨기지 않는 것
스크럼의 3가지 기둥
TRUST의 기반이 되는 3가지 기둥
- 투명성
- 점검
- 조정 - 인수할 수준이 안될 경우 적용되는 공정 또는 작업의 산출물을 조정하는 것
스크럼은 역할이 있다.
- Product Owner
- 요구사항을 백로그에 작성하고 우선순위를 조정함
- Scrum Master
- 개발 팀원들의 원활한 업무를 위한 가이드 역할
- 데일리 스크럼 회의를 주관
- Adhoc 공론화 하고 해결하도록 돕는 역할
- Scrum Team / Scrum Developer
- PO와 Scrum Master를 제외한 모든 스크럼 팀의 구성원
프로덕트 백로그 작성(PO가 작성) > 스프린트 플래닝 미팅 > 스프린트 백로그 작성 > 스프린트 운영 > 스프린트 데모 > 스프린트 데모 및 리뷰(산출물에 대한 리뷰) > 스프린트 회고(프로세스에 대한 회고)
- 프로덕트 백로그는 User Story의 형태로 작성되는 경우가 일반적이다.
스크럼 주의사항
프로세스에 매몰되지 말고 항상 애자일의 목표를 생각할 것
- Doing Agile이 Being Agile이 아니다. Agile하게 하되 항상 목적을 생각할 것!(프로덕트 목표 지향성)
가장 주의해야할 점이 Be Agile 하되 Do Agile만 하지 말 것!! 항상 명심하면서, 스프린트를 잘 기획해야겠다고 다짐했다.
So what next?
CryptoMeter 프로젝트 시작!
실제 서비스를 개발한다는 생각으로 의사 결정, 최적화, 테스트 등을 결정할 때 근거를 기반으로 결정할 예정이다. 가장 어려운 협업 툴, 규칙 정하기와 인터페이스 분석인데, 주말동안 다 결정했기 때문에 다음주에는 개발에 몰두할 듯하다.
