代码共享_什么音乐可以教我们共享代码的方式-CSDN博客

代码共享

by Jonathan Saring

乔纳森·萨林(Jonathan Saring)

Not that long ago, many of us were carrying a suspicious-looking suitcase in the back of our cars, or had one hidden under our beds. Some of us had Ikea-made towers with multiple storage spaces standing proud in our living rooms. In both cases, this was the result of our impressive music CD-Roms collection. Today, chances are they are nostalgically stored in our garage.

不久前，我们中的许多人都在车后背上抬着一个看起来可疑的手提箱，或者把一个藏在床底下的手提箱。我们中的一些人拥有宜家制造的塔楼，其多个储物空间引以为傲。在这两种情况下，这都是我们令人印象深刻的音乐CD-Roms收藏的结果。今天，它们很可能怀旧地存放在我们的车库中。

After a short reign, music CD-Roms were replaced by iTunes and YouTube, with MP3 players in between. This revolution happened mainly because of 5 major disadvantages CDs had from day one:

短暂统治之后，音乐CD-ROM被iTunes和YouTube取代，而MP3播放器介于两者之间。这场革命的发生主要是因为CD从一开始就具有5个主要缺点：

They were cumbersome to use, carry and handle.
它们笨重地使用，携带和处理。
They took too much effort to purchase/create.
他们花了太多精力去购买/创建。
They were very hard to change and modify. Nobody really wanted to burn a new CD whenever a new Bieber song came out (don’t judge me).
它们很难更改和修改。每当有新的Bieber歌曲问世时，没人真正想刻录新CD(不要判断我)。
They forced us to carry a bunch of songs we don’t listen to and zap through them just to listen to a single song we really wanted to listen to.
他们强迫我们携带一堆我们不听的歌曲，然后在它们之间跳动，只是听我们真正想听的一首歌。
Who remembered which songs were on which CD? 90% of my burned CDs contained the same 10 songs anyways.
谁记得哪首歌在哪张CD上？无论如何，我刻录的CD中有90％包含相同的10首歌曲。

Surprisingly, this isn’t all that different from the way we share code today, between projects and between people. Let’s see how.

令人惊讶的是，这与我们今天在项目之间以及人与人之间共享代码的方式并没有什么不同。让我们看看如何。

Modularity has always been the holy grail of software development, and the key to better reusability, maintainability and testability.

模块化一直是软件开发的圣杯，也是提高可重用性，可维护性和可测试性的关键。

Every day, more of the applications we build are designed with greater modularity through smaller components of code. Reusable functionalities, UI and Web components (such as React, Vue and Angular), Node.js modules, GraphQL APIs and even serverless functions are our building blocks.

每天，通过较小的代码组件，我们构建的更多应用程序都具有更高的模块化设计。可重用的功能，UI和Web组件(例如React，Vue和Angular)，Node.js模块，GraphQL API甚至无服务器功能都是我们的基础。

Now let’s be honest — who knows exactly which reusable components were written in their codebase, organizes them, and shares them between their projects at scale? I know I didn’t. Then, I started asking myself why not.

现在说实话–谁确切知道在他们的代码库中编写了哪些可重用组件，对其进行了组织并在规模较大的项目之间共享它们？我知道我没有然后，我开始问自己为什么不这样做。

Let me show you. Here is a React movie application hosted on GitHub. As you can see, it contains a total of 49 files and 14 directories. One of these directories is the components sub-directory. Inside that sub-directory there are 8 reusable React components (such as hero and navigation).

让我给你演示。这是托管在GitHub上的React电影应用程序。如您所见，它总共包含49个文件和14个目录。这些目录之一是components子目录。在该子目录中，有8个可重用的React组件(例如hero和navigation )。

├── src

│   ├── App.js

│   ├── App.scss

│   ├── App.test.js

│   ├── components

│   │   ├── hero

│   │   ├── hero-button

│   │   ├── item

│   │   ├── list-toggle

│   │   ├── logo

│   │   ├── navigation

│   │   ├── title-list

│   │   └── user-profile

│   ├── favicon.ico

│   ├── global.css

│   └── index.js

└── yarn.lock

Let’s say I have another React application, and I want to use my hero component in that different app as well, and also make it discoverable for my team to use in their projects and easily change it to suit their needs.

假设我有另一个React应用程序，我也想在那个不同的应用程序中使用我的hero组件，并使我的团队可以在他们的项目中发现它，并轻松地对其进行更改以满足他们的需求。

Copy-pasting code is a very bad idea. This might seem like the quick way to go about it, but it’s really not. Don’t do it.

复制粘贴代码是一个好主意。这似乎是解决问题的快速方法，但实际上并非如此。不要这样

As of today, I really have three options:

截至今天，我确实有三个选择：

Publish nine packages: Create eight new repos, boilerplate, and publish nine packages and change both project’s source code to require them. When I’ll want to modify a component, I’ll have to work very hard to make changes from different repos. Now imagine having 500 of these.
发布九个软件包 ：创建八个新的仓库，样板并发布九个软件包，并更改两个项目的源代码以要求它们。当我想要修改组件时，我将不得不非常努力地从不同的存储库中进行更改。现在想象一下有500个。
I can use Lerna to keep multiple packages in a single repo, but it only works if I really want to go monorepo. Even then, I’ll have to restructure my project, configure each package separately, and define their dependency tress, and every change will still have to go through the original repository.
我可以使用Lerna将多个软件包保存在一个仓库中，但是只有在我真的想使用monorepo时，它才有效。即使那样，我仍然必须重组我的项目，分别配置每个程序包，并定义其依赖关系，并且每项更改仍必须经过原始存储库。
Shared library: Create a new repo, group the components together, create the configurations needed for such a project, publish it as a new library, and change both projects’ source code. Every app using this library will add redundant code, weight, and complexity. Every modification will require republishing the whole library, and go through the owner.
共享库 ：创建一个新的仓库，将组件分组在一起，创建该项目所需的配置，将其发布为新库，并更改两个项目的源代码。使用此库的每个应用程序都会增加冗余代码，重量和复杂性。每次修改都需要重新发布整个库，并经过所有者。

The thing is, packages are great for larger projects. For smaller components and modules, these solutions share some of the same problems as music CD-Roms: Serious overhead, changes are hard, and discoverability is lacking.

问题是，软件包对于大型项目非常有用。对于较小的组件和模块，这些解决方案与音乐CD-ROM共享一些相同的问题：严重的开销，难以更改，缺乏可发现性。

In a way, setting up 500 repos and packages to share smaller components reminds me of using a mini-disc player (not my best-spent $100): you can’t solve this problem by optimizing it. You have to innovate.

在某种程度上，设置500个存储库和程序包以共享较小的组件使我想起了使用迷你光盘播放器(而不是我花了100美元买的最好的光盘播放器)：您无法通过优化来解决此问题。您必须创新。

那么…iTunes是否提供共享代码？ (So… iTunes for shared code?)

Obviously, comparing shared libraries to CD-Roms isn’t very technically accurate. The complexity of sharing functionality between complicated environments and contexts is different from that of listening to Lady Gaga.

显然，将共享库与CD-Roms进行比较在技术上不是很准确。在复杂的环境和上下文之间共享功能的复杂性不同于聆听Lady Gaga的复杂性。

Still, sharing common code between projects really shouldn’t be this hard. What we can really learn from the way we share and consume music today is that effective sharing requires a better experience: reducing overhead, increasing discoverability, and going from static to dynamic.

尽管如此，在项目之间共享通用代码并不难。从当今共享和消费音乐的方式中，我们真正可以学到的是，有效的共享需要更好的 体验：减少开销，增加可发现性以及从静态变为动态。

因此，我们决定建造它 (So, we decided to build it)

Sometime early 2017 we had that exact dream. One of the best things about open source is that having an idea is a perfectly good enough reason to build it.

2017年初的某个时候，我们实现了这个梦想。关于开源的最好的事情之一就是拥有一个想法是建立它的一个足够好的理由。

We decided to go ahead and build Bit — an open source project designed to do for code sharing what iTunes did for music sharing — make it simple, dynamic and easily accessible for everyone. Bit’s idea is simple: Kill the overhead of sharing code.

我们决定继续构建Bit ，这是一个开放源代码项目，旨在进行代码共享，而iTunes则实现了音乐共享，它使每个人都可以简单，动态且易于访问。 Bit的想法很简单：消除共享代码的开销。

这个怎么运作 (How it works)

It was built to provide the fastest experience possible for “managed copy-pasting” and be 100% compatible with Git and NPM.

它旨在为“托管复制粘贴”提供最快的体验，并与Git和NPM 100％兼容。

The key lies in Bit’s ability to separate the representation of shared code from your project’s file system, and its ability to track shared code across repos and projects whether it’s installed or actually sourced in these projects.

关键在于Bit能够从项目文件系统中分离出共享代码的表示形式，以及能够在存储库和项目中跟踪共享代码的能力，无论这些代码是已安装还是实际来自这些项目。

It breaks the overhead of sharing code by eliminating the need to split your repos or having to restructure your project and boilerplate multiple packages inside it.

通过消除拆分存储库或重组项目以及在其中包含多个程序包的需求，它消除了共享代码的开销。

Instead, you can simply point Bit to any part of your repo that you would like to share, let Bit automatically isolate it (including dependencies), and share it to a shared location called Scope from which it can be installed with NPM.

取而代之的是，您可以简单地将Bit指向要共享的仓库的任何部分，让Bit自动隔离它(包括依赖项)，然后将其共享到一个名为Scope的共享位置，该位置可以通过NPM进行安装。

Since Bit is able to track actual source code between projects, you can also use it to import the code itself into any repository, change it, and let Bit sync changes across your projects for you.

由于Bit能够跟踪项目之间的实际源代码，因此您也可以使用它将代码本身导入任何存储库中，进行更改，并让Bit为您同步整个项目中的更改。

When sharing, you can even eject the code back to being a package dependency for your project.

共享时，您甚至可以将代码eject ，成为项目的程序包依赖项。

As a result, there is basically no overhead for sharing code and making it available with NPM, discoverability is increased, and maintenance becomes much simpler. Scopes even help building and testing your code so you don’t have to configure these environments for every package.

结果，基本上没有共享代码并使代码可用于NPM的开销，可发现性得到提高，维护变得更加简单。范围甚至有助于构建和测试代码，因此您不必为每个软件包都配置这些环境。

Here is how Bit’s workflow looks:

这是Bit的工作流程的外观：

Install Bit and initialize it for your project.
安装Bit并将其初始化为您的项目。
Choose which components of code to track from your project and which environments to add for build and test processes.
选择要从您的项目中跟踪哪些代码组件，以及为构建和测试过程添加哪些环境。
Share them to a remote Scope were they are hosted, organized, and made available to install using your favorite package manager.
将它们托管，组织并可以使用您喜欢的软件包管理器进行安装，然后将它们共享到远程范围。
Easily import their code into any repo, change it as needed, and update your changes across your codebase.
轻松将其代码导入任何存储库，根据需要进行更改，并在整个代码库中更新您的更改。

Let’s see an example.

让我们来看一个例子。

返回React movie-app (Back to React movie-app)

Let’s go back to the React movie-app.

让我们回到React movie-app 。

Adding Bit to the project enabled me to track and isolate the reusable components inside, without setting up new repositories or changing my project’s code. Then, I shared them to this collection.

将Bit添加到项目中使我能够跟踪和隔离其中的可重用组件，而无需设置新的存储库或更改项目的代码。然后，我将它们共享给该收藏集。

Sharing it took very little time and my project wasn’t changed at all. No new package.json files were created and I didn’t have to configure multiple environments or fight my dependency tree.

共享花了很少的时间，我的项目完全没有改变。没有创建新的package.json文件，我不必配置多个环境或与依赖关系树作斗争。

As you can see, every component is now available to my entire team to install with NPM or to import into their own projects for further modifications.

如您所见，我的整个团队现在都可以使用每个组件来与NPM一起安装或导入到自己的项目中以进行进一步的修改。

They can search for it, and view useful information — from live rendering to build and test results, auto-parsed docs and examples — so they can judge its usefulness.

他们可以搜索它，并查看有用的信息(从实时渲染到生成和测试结果，自动分析的文档和示例)，以便他们判断其有用性。

Our entire team can now organize and share our common code components without having to work hard or reinvent the wheel every day.

现在，我们整个团队可以组织和共享我们的通用代码组件，而无需每天辛苦工作或重新发明轮子。

After using it for over 10 months, and after now being used by additional teams and communities, I welcome you to join and use it for your projects.

在使用了10个月以上之后，现在又被其他团队和社区使用了，我欢迎您加入它并将其用于您的项目。

You can see a video demo of this project here.

您可以在此处查看该项目的视频演示。

回到未来 (Back to the future)

Up until a few years ago, we had to burn a new project for every song we wanted to listen to. We had to store and maintain multiple static CDs and drag along a bunch of stuff just to listen to a single song. We duplicated songs between CDs and had trouble discovering the songs we really wanted.

直到几年前，我们还不得不为每个想听的歌曲刻录一个新项目。我们必须存储和维护多张静态CD，并拖着一堆东西才能听一首歌。我们在CD之间复制了歌曲，却无法找到我们真正想要的歌曲。

iTunes provided us with the dynamic experience that helped us compose and share playlists, easily find the songs we wanted, and quickly update our playlists. When I’m at a party, I can easily play my up-tempo summer playlist, or just as easily play my romantic songs to my cat to get her to go to sleep.

iTunes为我们提供了动态体验，可帮助我们编写和共享播放列表，轻松找到我们想要的歌曲，并快速更新播放列表。在参加聚会时，我可以轻松播放自己的节奏快的夏季播放列表，也可以轻松地向我的猫播放浪漫的歌曲，让她入睡。

We can learn a whole lot from how music moved from CD-Roms to shared playlists. Bit aims to make code sharing and reuse simple and accessible for everyone just like iTunes did for shared music. It’s still a work in progress, and as such it still has a lot of room to grow and evolve. You are welcome to try it out, suggest ideas and feedbacks, and help us take that leap forward.

从音乐如何从CD-ROM转移到共享播放列表，我们可以学到很多东西。 Bit旨在使代码共享和重用变得简单，所有人都可以使用，就像iTunes共享音乐一样。这项工作仍在进行中，因此仍有很大的成长和发展空间。欢迎您尝试一下，提出想法和反馈，并帮助我们实现这一飞跃。

“ The secret to efficiently building ‘large’ things is generally to avoid building them in the first place. Instead, compose your large thing out of smaller, more focused pieces… “