2018 M03 26

코드를 공유하는 5가지 실용적인 방법: NPM 부터 Lerna 그리고 Bit (5 Practical Ways To Share Code: From NPM To Lerna And Bit)

다양한 저장소, mororepos 및 마이크로-서비스(micro-services) 까지 프로젝트(projects) 간 공통 코드(common code) 공유에 관한 토론은 점점 더 어려워 지고 있습니다.
프로젝트(projects) 와 저장소(repositories) 간에 공통 코드를 공유하는 것은 모듈성(modularity) 개선 및 개발 속도를 높이기 위한 핵심 요소이나 이는 참 복잡 합니다. 이에 관해 저는 우리 팀이 경험한 것을 작성한 적이 있습니다.
다음은 프로젝트(projects) 와 repos 간 코드(code) 공유를 위한 5가지 실용적인 방법입니다. 꼭 알아두세요. 아래는 사용자, 문화 그리고 모듈화를 염두한 커뮤니케이션의 모든 것입니다.

1. Lerna를 포함 그리고 포함하지 않을때 NPM (NPM with and without Lerna)

마이크로 팩키지(micro-packages)의 가장 큰 장점은 중복 방지 와 재사용 및 모듈성 향상에 도움이 된다는 것 입니다. 일례로 Sindre Sorhus 와 같은 오픈 소스 저자들은 1000개가 넘는 모듈을 NPM 에 등록 했습니다.


presentation
1000개의 NPM 패키지를 등록한 Sindre Sorhus

presentation
Dan Abramov는 다양한 모듈을 선호합니다.

마이크로 팩키지(micro-packages)는 모듈성이 뛰어나지만 치명적인 단점도 있습니다: 오버헤드(overhead).
패키지를 위한 새로운 repo를 만든 뒤 환경 설정 및 등록 후 유지 관리, 관련 프로젝트 소스 코드를 변경해야 해야하는 등 실로 오버헤드(overhead)가 엄청납니다. 또한 소규모 팀이 500 또는 100 개의 패키지를 만드는 것은 몇개월이 걸릴지 장담할 수 없습니다.
또한, 어떤 패키지(packages)가 자유롭게 사용 가능한지 장담 할수 있나요? 누군가 패키지 사용을 위해 어떻게 검색하고 결정할 지 알 수 있을까요? 롤업(Rollup’s)의 저자 Richup Harris는 기고 를 통해 스몰 패키지(small package) 발견 가능성은 중요한 문제(major issue)라 이야기하고 있습니다:
“많은 블로그 게시물 아니, 모든 웹사이트들(websites) — 은 당신이 npm 에서 필요한 패키지를 찾는 수고를 덜어주고 있습니다...
설령 스몰 패키지를 찾았다해도 이를 반영하는게 현명한 선택인지 판단하는것 역시 큰 문제(big of an issue) 입니다:
“라이브러리(library)에 대한 평가는 전적으로 당신에게 달렸습니다: 테스트(tests)가 가능합니까? 코드(code) 를 이해했습니까? 관련 문서(documentation)를 찾고 참조(consult)하기 쉽나요?”
수 백개의 repos를 관리하는 오버헤드 및 패키지를 업데이트하는 번거로움 (및 소유권 문제)이 공존하는 솔루션은 대다수 팀에서 비 효율적일 수 있습니다. 마지막으로 left-pad 역시 잊지 마세요.

Lerna


presentation
Lerna의 히드라(Hydra): 꼬리를 보니 넘어질 것 같은데요

Lerna 는 단일 저장소(repository)에서 다양한 패키지(packages)를 구성하도록 도와줍니다. 이는 다수의 패키지(packges)가 서로 다른 repos를 참조하는 번거로움을 완화하는데 도움이 될 수 있으며 또한 프로젝트 전체를 빌드하고 테스트하는데 큰 이점이 있습니다. 이로 인해 패키지마다 별도의 repos를 유지하고 관리할 필요가 없습니다.
그럼에도 불구하고, 여전히 다수의 pakages.json 포함한 단일 repo에 여러 패키지(packges)를 효과적 유지 및 다양한 빌드/테스트 환경을 구성해야하며 필요한 경우 의존성 트리(dependency tree)를 추가해야하는 번거로움이 존재합니다. 또한 이러한 패키지(pakages)를 업데이트를 하려면 반드시 메인 repo를 거쳐야 하므로 여러 프로젝트(projects)에서 패키지(packges)를 변경하는 일은 더욱 복잡하기만 합니다.

2. Bit (Git 포함 그리고 NPM 포함 또는 불포함) (Bit (with Git and with / without NPM))

Bit는 작은 컴포넌트(components) 및 모듈(modules)을 여러 프로젝트 또는 앱(apps)에서 손쉽게 구성하고 동기화 할 수 있는 빌딩 블록(building blocks)으로 전환하는 데 유용 합니다.
Bit를 사용하면 repos(의존성 포함)에서 코드(code) 선택이 가능하며 리팩토링, 새로운 repos 또는 어떤한 환경설정 없이 — Bit를 완벽하게 분리하여 클라우드(cloud)로 공유 가능합니다.
여기서, 다른 모든 패키지와 처럼 NPM / Yarn 으로 코드를 설치하거나 Bit를 통해 코드를 가져와 양방향(2-way) 코드 변경이 필요한 다른 프로젝트(projects)에서 손쉽게 업데이트 가능하며 이를 통해 분산 개발(distributed dev) 워크플로우를 만들 수 있습니다.
presentation
Bit로 공유된 React UI 컴포넌트

Bit 허브(Bit’s hub)를 이용하면 컴포넌트(components)를 시각적으로 구성 가능하며 라이브예제, 렌더링, 문서 등도 제공 됩니다.
이어서 제공되는 링크는 React 프로젝트 와 이에 해당하는 컴포넌트(components) 컬렉션 예제입니다.
확인한바와 같이 Bit가 코드 쉐어링(sharing)에서 발생되는 오버헤드를 효과적으로 제거함과 동시에 향상된 검색 및 제어 기능을 제공함을 알아볼 수 있었습니다. 아래는 주요 이점(advantages)입니다.
  1. 코드 공유를 위해 repos를 분할하거나 코드베이스(codebase)를 리펙토링 하지 않아도 됩니다.
  2. 소유권(ownership)에 연계되지 않고 전체 코드베이스를 동기화하면서 어떤 프로젝트라도 양방향 코드 변경 및 업데이트를 가능하게 합니다.
  3. 구성된 범위(scope), 시각적인 핵심 정보(빌드 및 테스트 결과, 자동-저장 문서, 렌더링 등) 및 검색 엔진을 통해 검색 성과를 높일 수 있습니다.
Bit의 “단점(downside)”은 NPM / Yarn 을 통해 코드를 설치하려면 오픈 Bit 허브(open bit hub)를 Scoped 레지스트리 처럼 구성해야한다는 것 입니다.

presentation
@WalmartLabs에서 Bit의 Ran Mizrahi가 공유 코드 관련 토론 중입니다

3.공유 및 공용 라이브러리(libraries)

공유-라이브러리(shared-libs) 장점은 모든 공유코드(shared code)를 하나의 repo에 유지하므로 여러 마이크로-패키지(packages)보다 유지 관리 및 배포가 용이합니다. 그러나, 이는 Lerna와 달리 단일 패키지로 관 될 것 입니다.
모든 공유 코드를 하나의 repo에 보관하면 중복 된 코드, 종속성(dependencies), 복잡성(complexity) 및 가중치(weight)가 포함된 전체 라이브러리를 하나의 컴포넌트를 사용해 프로젝트로 추가해야합니다.

presentation
React MaterialUI 버튼 컴포넌트 — 과연 모든 라이브러리가 필요할까요?

또한 모든 변경 작업 마다 프로젝트 소유자(owner)가 패키지를 업데이트해야 하므로 업데이트 및 수정 프로세스가 매우 복잡해 집니다. 이는 조직 내 라이브러리(libraries) 채택을 어렵게 하는 요소임에 분명합니다. 추가로 라이브러리 내 다양한 컴포넌트(conponents) 발견 가능성 역시 문제점 입니다.
이같은 문제로 인해 Lodash 와 같은 커뮤니티는 구성요소를 개별 패키지(individual packages)로 NPM 에 등록하기 위해 오랫동안 많은 노력을 해왔습니다. Google의 Polymer 프로젝트 ( Eric Bidelman 및 기타 OSS wizards) 역시 100개가 넘는 다양한 저장소(repositories)에 100개 이상의 웹 요소(elements)를 저장하고 있습니다.
노트 :
Lerna는 라이브러리 내 컴포넌트(components)를 패키지로 분리할 수 있습니다. Bit는 기존 라이브러리(libraries)에서 컴포넌트(components)를 공유하는 데 사용 가능합니다.

4. Git 서브 모듈 (sub-modules)

Git 은 대부분의 개발팀이 선호하는 SCM 입니다. 이를 통해 하나의 저장소(repository)를 다른 저장소의 서브디렉토리(subdirectory)로 지정하여 전체 프로젝트에 대한 단일 작업 트리(single working-tree)를 생성 할 수 있으며 이를 통해 작업중인 프로젝트 에서 다른 프로젝트 코드 사용이 가능합니다.


presentation
앞서 배운 교훈?

Git 서브 모듈은 여러가지 문제 점이 있습니다. 첫째, 이는 master 브랜치에서만 동작합니다. 둘째, 서브모듈(submodules)은 여러 프로젝트 간 고도로 결합된 코드(highly coupled code)를 생성하여 cross-repo 작업(tasks) 통합 및 공동업무를 어렵게 합니다. 또한 서브 모듈 repo 역시 중첩 및 의존적 repo 를 가질수도 있습니다.
git-subtree, gitslave, braid 그리고 giternal과 같이 서브모듈 기능을 자동화하는 다양한 도구가 있습니다. 이러한 도구를 통해 서브모듈의 적합성 문제(issues) 중 일부를 개선하고 있지만 특정 벤더(vendor) 에서 지원하지 않고 다른 기타 문제점(drawbacks)도 존재합니다

5. 복사-붙여넣기 코드

툭 까놓고 말해, 다가올 미래가 내게 해준게 뭡니까?

presentation
당신의 팀원이 YOLO를 외칠때

솔직히, 이는 지구상에서 가장 보편적으로 사용되는 코드 “재사용” 방법 일 것입니다. 대부분의 경우 다른 “저렴한” 효과적 대안이 없고 다소 혼란스러운 전달 주기(delivery cycles) 때문에 보편적으로 많이 이용한다고 생각합니다.
하지만 전혀 그렇지 않아요. 이 문제로 발생한 코드 중복은 결코 저렴하지 않을 것 이니까요.

presentation
미래의 내게 보내는 클래식한 문제

이는 중복되는 부분을 지속적으로 증가시킬 것입니다. 유지 보수 작업을 더욱 어렵고 더디게할 것이고 제공 주기 또한 길어지는 것은 두말하면 잔소리죠. 많은 문제(problems)들이 배포 후에나 발견될 것 입니다.
최근 연구에 따르면 GitHub 코드 절반이 중복되었다고 합니다. 이중 Javascript 기능인 is-string 은 10k Github repos 중 100개의 서로 다른 구현에서 1,000(10k)개 이상 중복되어 있다고 합니다.
코드를 복사하거나 이를 재작성하기 보다 코드를 공유할 수 있는 새로운 기능을 생각해 보세요. 또한 조직의 유지 관리 비용과 긴 전달 주기에 대해 생각해 보도록 하고요.

사용자를 위한 공유 코드

각 프로젝트의 모든 개발자는 자신 만의 관심사, 도구 및 워크 플로우를 가지고 있습니다. 하지만, 그럼에도 불구하고 코드를 공유하는 것은 진정한 모듈화를 위한 핵심이며 이는 오는날 생태계에서 점점 큰 인기를 얻고 있죠.
우리는 Bit를 만들기로 했습니다. 그 어떤 방법 및 툴을 사용과 관계없이 공유 및 공동 작업 문화를 장려하는 것이 중요합니다.
결국 프로젝트간 공유는 사용자간 공유로부터 시작 됩니다.


이 글은 번역글 입니다.
원문은 아래를 참고 바랍니다.