220903 Meeting Note

---

일시 : 22.09.03 14:00~

장소 : 선릉 저스트코타워 (오프라인) + 온라인

참석자 : 문기님, 바울님, 채정님, 민정님(온라인), 예진님

---

논의 안건

1. type

관련 링크

<문제 상황>

PR을 올려서 type 파일을 어떻게 제공할 수 있을까. 즉, 타입 제공 방식에 대한 선택이 필요하다.

현재는 접근 방식이 @githru/${package}로 접근 가능

타입 제공 방식 SOL 1) monorepo에서 type을 꺼내오는 방식

• 우려되는 부분

  interface 정의에 대한 PR 머지 -> 해당 type파일을 사용하는 view repo에서 PR 머지 -> interface 정의 변경 PR 머지 -> 언제나 에러남

타입 제공 방식 SOL 2) npm publish를 하는 경우

• 우려되는 부분

  배포 단위를 어떻게 가져갈 것인가에 대한 의문

@바울: 취향은 monorepo

@민정: monorepo를 써보고 싶긴 하다.

@예진: 어떤 것이 좋을지 잘 모르겠습니다.

=> 우선은 상황만 인지를 하고 현재 mono repo 방식을 유지하는 것으로 결정

타입 제공 형태 SOL 1) src/types/index 하위에서 전부 관리

장점: index.ts에서 타입 파일에 대한 제어 가능 단점: index.ts에 대해 관리가 필요하다

타입 제공 형태 SOL 2) src/types에 두는데, 각각 export한다, ~~.d.ts

장점: 추가 작업이 필요없고, 명확하다. 단점: import 문이 길어진다.

@바울: SOL 2)가 파일 분리를 해서 명확할 것이다, 그러나 줄줄이 길어질 것

@예진: view팀이 접근하는 것을 생각하더라도, 경로 관리에 수월하려면 SOL 1이 낫다.

@바울: 얼마나 타입이 소비될 지 모르기 때문에 예진님 의견에 동의한다.

=> 귀찮더라도 index.ts에 모으는 것으로 결정

2. 테스트 코드 PR 방식에 대한 논의

SOL 1) 테스트 PR -> 기능 PR

기능 PR에서 에러가 났을 때 테스트 코드가 문제인지, 기능이 문제인지 파악할 수 없다.

기능이 문제라면 해당 PR에서 코드를 수정하면 되는데,

테스트 코드가 문제라면 복잡해진다.

또는 SOL 2) 기능 PR -> 테스트 코드 PR

위의 방식과 순서의 차이

그리고 TDD에 맞지 않다!

@바울: 원래는 test 작성 뒤 해당 test를 통과하는 흐름이 일반적인데(TDD) 하지만 현재 githru 작업 방식은 비동기적이기 때문에 해당 방식은 맞지 않음. 코드를 쓰고 테스트를 붙이므로써 엣지 케이스를 걸러내는 정도로 테스트 코드를 활용하면 좋겠다.

@채정: PR을 하나로만 구성하자. 나머지 한 명이 fork된 repo를 clone해서 페어로 작업하는 것.

@문기: 위 방식대로라면 해당 PR이 문제가 없어야 한다는 가정이 필요하다.

@예진: DAG 작업 중 구현 결과물이 제대로 나오지 않은 상황에서 테스트를 먼저 작성하는 것은 엎어질 가능성이 있어 위험하다.

@바울: feature를 만든 사람이 테스트까지 담당해서 가는 것이 일반적이긴 함.

@문기: 각자 진행하는 팀끼리 자유롭게 방식을 채택한 뒤 각각에서 발생하는 케이스에서 문제점을 공유하자.

=> 각 팀마다(채정&민정, 예진&바울)마다 상의해서 의사결정을 하길 바랍니다.