2주차 회고

미팅 질문

(시간나면)

키보드 뭐 쓰세요 저 요즘 키보드 알아보는 중인데 ㅎ
네이버에 오래 계셨는데 원래 이직 생각이 없으신지

<도메인에 관한 질문>

마인드맵 트리 저장 및 렌더링 방식?

통째로 스냅샷은 아름답지 못 해서, diff를 사용하기로 하였다.

서버에 레디스를 사용해서 일정 갯수마다 스냅샷 찍고, 이 스냅샷과 diff로 클라이언트에서 랜더링할 계획
전체 노드 정보는 따로 데이터베이스에 저장할 계획

메세지만 날려서 클라이언트 생성,삭제,수정 메세지 보냄 => 서버에서 ok (이벤트 로그 "a를 누가 업뎃함") => 클라이언트에서 반영시킴 => 비동기(서버에서 노드 db 테이블에 CRUD "수정된 a row 업뎃") => 노드 테이블 스냅샷

트리 그리는 방식과 노드 이동의 문제

상향식 방식이 => db에 한 번만 접근해도 돼서 => 노드 이동 하지 말자 => 노드가 한 군데에서 바뀌고, diff가 atomic하기 위해서

하향식 -> 이동이면 기존 부모의 children list에서 삭제 후 변경된 부모의 children list에 추가해주기 -> 삭제면 부모의 children list에서 없애주고 delete 처리

2 프로젝트id:123456, 타입:노드 부모 변경, 행위자:김유석, 시간:211110_071912, 타임스탬프:13(idx), 사이드 이펙트:[ { type:change, oldNode:ParentNodeObj1, newNode:ParentNodeObj1, }, { type:change, oldNode:ParentNodeObj2, newNode:ParentNodeObj2, }, ]

=> atomic + 순수 하게

https://kciter.so/posts/effective-atomic-design#modal-tooltip%EA%B3%BC-%EA%B0%99%EC%9D%80-ui-%EC%B2%98%EB%A6%AC

11/05 회고

결과

예상: 71시간
실제: 80.5시간
못한 시간 : 23시간
실제 - 예상: 32.5시간
데모영상

긍정적인 점

데모까지 무사히 마쳤다.
git이 안정적으로 관리되고 있다.
협업 방식에 익숙해지고 있다.
적극적인 리뷰 및 반영

부정적인 점

아토믹 패턴 보완 필요
백로그에 반영하지 못한 부가적인 기능이 많아 시간이 초과된다.
배포 설정을 못 끝냈다.
DB설계의 미완성

원인과 해결책

왜 아토믹 패턴 보완이 필요한가

첫 시도다 보니 미숙했던 점이 있다.
합의된 원칙이 필요하다.
styled-component와 접목에서 최선의 방법을 아직 찾지 못했다.
atom은 Type과 Interface로 style이 정의된다.
상위에서 atom의 Type을 통해 사용할 수 있게 한다.

// 사용 부분
import TAtom from './'

<button type={TAtom.large} />

// 선언 부분
type TAtom {
    large
}

const styleOptions = {
    large : 'width: 100 px'
}
    
const button = styled<Tatom>{
    ${ ({type}) => styleOptions[type] }
    color: black;
    }

// theme 사용시
${({theme}) => theme.color.bgWhite}

molecules은 한 가지 기능을 수행
organisms은 여러 기능 수행 덩어리
template은 페이지에서 데이터를 주입했을 때 재사용이 되는 단위
template 데이터는 페이지에서

시간을 왜 초과하였는가

hook이나 state 관리 역시 구현해야하는데 백로그엔 반영되지 않음.
헤더와 같이 당연히 있어야하는 것을 실수로 백로그에 반영하지 못했음.
helper 함수나 리팩토링 등 실제 구현에는 순수한 구현 외에도 쓰이는 시간이 많음
기반이 될만한 부분을 짜다보니 고민 시간이 길었다.
차주부터는 어느정도 기반이 마련되었으니 더 빠르지 않을까. 백로그 시간 선정도 더 구체적으로 할 수 있을 듯

배포 설정을 못끝낸 이유가 무엇인가

다른 기능들이 밀리다보니 배포에서 도커를 새로 도입할 때 시간이 오래걸릴 것으로 예상되 다음 기회로 넘기게 되었다.
정해진 시간 외적으로 구현하려 하여 백로그 시간에 포함을 시키지 않았었음
주말에 도커 공부하기

DB 설계를 다 하지 못한 이유는 무엇인가

고민이 많았다.
작업하면서 바뀌게 되는 설계도 있었다.
아직도 데이터 플로우 시나리오를 완벽하게 정의하지 못함
주말에 고민하고 담주 내로 fix를 합시다!

느낀점

백로그 미리 계획을 짜놓고 스프린트 회고 때 피드백을 세세히 하자

유석 : 팀원들이 다들 잘해서 좋았지만 정작 나는 기능 하나마다 시간을 너무 많이 써서 슬펐다. 접근 방법을 다양하게 생각해 볼 필요가 있을 것 같고, 디테일보다는 큼직한 기능부터 만들고 세세하게 잡아가는 과정으로 개발해보도록 해야겠다.

주영 : 아토믹하게 짜느라 시간이 오래 걸렸지만 이제 기본적인건 좀 있으니 다음주는 편하지 않을까. 목표한 바에서 살짝 부족하게 완료되었지만 첫주에 이만하면 만족한다.

성현 : 이번 주 기반이 되는 코드를 짜다보니 고민이 길었고, 팀원들간의 조율이 필요하다는 것을 느꼈다. 덕분에 원칙을 정할 수 있었으니, 점점 속도가 붙을 것 같다. 뒤에 기획들을 모두 완성시킬수 있을 것만 같은 희망이 드는데, 다음주 소켓과 히스토리 부분이 관건이 될 것 같다.

승현: 타입스크립트 진짜 너무 번거롭다. 배포 끝나고 리액트를 공부하고 싶었는데 타입스크립트부터 공부해야겠다. 백로그를 다 수행하지 못했는데 부가적인 일보다 배정된 일을 확실히 먼저 끝내놓는 습관을 들여야겠다.