마이그레이션과 소통

[yoonminsang]

어쩌다보니 지속적으로 여러 대규모 마이그레이션을 진행하고 있다.

오늘은 20개가 넘게 흩어져있는 패키지를 하나로 합치는 작업을 했다.
import 경로, 변수명 등이 변경되기 때문에 마이그레이션 스크립트도 만들었다.

마이그레이션 프로세스에 대한 약간의 고민이 있었고 나는 다음과 같이 생각했다.

1. 신규 패키지 생성
2. 마이그레이션 스크립트를 돌려서 기존의 모든 코드 마이그레이션
3. 기존 패키지 제거(코드이원화 방지, 빌드 용량 최적화)
4. 내 작업이 합쳐진 이후에 이전 패키지에 접근하는 경우를 대응해 스크립트 및 가이드 문서 남겨두기

나는 기존 패키지의 제거 여부에 대해 얘기를 하려고 했는데 내가 너무 간단히 설명한 탓에 다른 얘기가 오고 갔다. 내가 조금 더 자세히 설명을 한 이후에야 모두가 이해했다. 그러다보니 3,4 과정에 대한 논의는 제대로 이루어지지 못했다. 팀원들의 피로도를 더 늘리고 싶지 않았기 때문에 기존 코드는 그대로 살려놓고 이후에 추가 가이드를 안내하던가 내가 직접 챙긴다고 메세지를 남겼다.

그 이외에 vanilla extract 관련 문제가 발생했다. vanilla extract이 zerto css in js라는건 들어봤는데 생각보다 좀 귀찮은 처리들이 있는 것 같다. 특히 번들러나 package의 깊은 의존관계가 있는 경우 추가 처리가 필요한 것 같다. 다음주에 조금 제대로 찾아봐야겠다.

최근 며칠간 커뮤니케이션 관련해서 아쉬운점들이 보인다. 당분간은 조금 더 신경써야겠다.

[al-bur]

오늘은 20개가 넘게 흩어져있는 패키지를 하나로 합치는 작업을 했다.

흩어져있는 패키지의 기능들이 한 가지 카테고리로 설정가능했던걸까요?!? 뭔가 어떤 단점이 있으셔서 마이그레이션했는지 궁금합니다

[yoonminsang]

음.. 조금 가볍게만 얘기해보면
특정 기능을 여러 라이브러리로 나눠서 관리하고 있었어요.
근데 이걸 모노레포로 이전했습니다.
번들러 설정이나 빌드 문제도 있고 그 이외에도 이런저런 이슈가 있어서 합치기로 결정했어요.
모노레포 내부로 이전하면서 각각의 패키지에 대한 버전관리를 하나로 합치기도 했구요.

[yoonminsang]

이렇게만 얘기하면 이해가 어려울 것 같아서 조금만 더 설명해보면...

보통 이런 기능은 package 하나로 관리해요. 간혹 세밀한 버전 관리가 필요한 경우엔 여러 package로 나누어 관리하기도 하는데, 현재는 그럴 필요성이 사라진 상태예요.

[al-bur]

현재는 그럴 필요성이 사라진 상태예요.

아하 이전에는 각각 세밀한 버전관리가 필요했다가 이제는 사라진 경우이군용