220903 Meeting Note
일시 : 22.09.03 14:00~
장소 : 선릉 저스트코타워 (오프라인) + 온라인
참석자 : 문기님, 바울님, 채정님, 민정님(온라인), 예진님
<문제 상황>
PR을 올려서 type 파일을 어떻게 제공할 수 있을까. 즉, 타입 제공 방식에 대한 선택이 필요하다.
현재는 접근 방식이 @githru/${package}로 접근 가능
- 우려되는 부분
interface 정의에 대한 PR 머지 -> 해당 type파일을 사용하는 view repo에서 PR 머지 -> interface 정의 변경 PR 머지 -> 언제나 에러남
- 우려되는 부분
배포 단위를 어떻게 가져갈 것인가에 대한 의문
@바울: 취향은 monorepo
@민정: monorepo를 써보고 싶긴 하다.
@예진: 어떤 것이 좋을지 잘 모르겠습니다.
=> 우선은 상황만 인지를 하고 현재 mono repo 방식을 유지하는 것으로 결정
장점: index.ts에서 타입 파일에 대한 제어 가능 단점: index.ts에 대해 관리가 필요하다
장점: 추가 작업이 필요없고, 명확하다. 단점: import 문이 길어진다.
@바울: SOL 2)가 파일 분리를 해서 명확할 것이다, 그러나 줄줄이 길어질 것
@예진: view팀이 접근하는 것을 생각하더라도, 경로 관리에 수월하려면 SOL 1이 낫다.
@바울: 얼마나 타입이 소비될 지 모르기 때문에 예진님 의견에 동의한다.
=> 귀찮더라도 index.ts에 모으는 것으로 결정
기능 PR에서 에러가 났을 때 테스트 코드가 문제인지, 기능이 문제인지 파악할 수 없다.
기능이 문제라면 해당 PR에서 코드를 수정하면 되는데,
테스트 코드가 문제라면 복잡해진다.
위의 방식과 순서의 차이
그리고 TDD에 맞지 않다!
@바울: 원래는 test 작성 뒤 해당 test를 통과하는 흐름이 일반적인데(TDD) 하지만 현재 githru 작업 방식은 비동기적이기 때문에 해당 방식은 맞지 않음. 코드를 쓰고 테스트를 붙이므로써 엣지 케이스를 걸러내는 정도로 테스트 코드를 활용하면 좋겠다.
@채정: PR을 하나로만 구성하자. 나머지 한 명이 fork된 repo를 clone해서 페어로 작업하는 것.
@문기: 위 방식대로라면 해당 PR이 문제가 없어야 한다는 가정이 필요하다.
@예진: DAG 작업 중 구현 결과물이 제대로 나오지 않은 상황에서 테스트를 먼저 작성하는 것은 엎어질 가능성이 있어 위험하다.
@바울: feature를 만든 사람이 테스트까지 담당해서 가는 것이 일반적이긴 함.
@문기: 각자 진행하는 팀끼리 자유롭게 방식을 채택한 뒤 각각에서 발생하는 케이스에서 문제점을 공유하자.
=> 각 팀마다(채정&민정, 예진&바울)마다 상의해서 의사결정을 하길 바랍니다.