我最近在一首诗提及，技师应该怎样避免采用大量的库、包以及其它倚赖亲密关系。我建议的另一种方案是，如果你没有达到宠信服务器端标识符的共振频率时，所以你就可以他们撰写标识符。

在责任编辑中，我将探讨两个在宠信和Cubzac撰写之间的取舍。这些掌控技术能为你提供良好的综合优势。你将会听到我提及的许多在相同C语言/自然环境下的范例。但，这首诗的层级足够多高，而且虽说，你在什么自然环境下组织工作，并不重要。

我们屡次要求她把字写得小一点。她节约了所以多油墨。

三种代码掌控技术

构想你所在的情况是这样的，你希望你的应用软件能够顺利完成当前无法顺利完成的任务。比如，你也许想这份 PDF 文件格式的报告，方便快捷列印。但你的应用软件并不会输入 PDF。作为一名技师，你要做的组织工作是解决那个问题。

右图展现了三种相同的掌控技术来加进那个功能。我并没有提及这三种掌控技术。当然，我肯定还有更多的掌控技术，包括镖靶和兔子。

为什么这么多下定决心都要先对呢？这真的很让人恼怒。

宠信：根据你的自然环境，你可能会在 lib 中建立镜像，或是在 pom.xml 或 package.json 中加进两个词条。不管你怎么做，宠信是截取自己的标识符，透过它的USB来采用，而不去重视它的在结构上。那段标识符还可能会入境者到一大群纵向的倚赖亲密关系东齐县，这会给你增添麻烦事。最多的不懈努力，增添的是最多的掌控。拷贝：从 Github repo、标识符短片集或是其它地方，选择你所需要的标识符。然后把它直接黏贴到你的项目中。那段标识符已经存在于你的标识符复本，而不再是两个倚赖亲密关系。改写：采用许多适宜你的服务器端标识符，透过改写，使其成为你他们的标识符。撰写：你他们撰写所有的标识符，用他们的脑袋，不转作其他人的东西。Ayn Rand 和 Casey Muratori 将认同你的下定决心。最大的不懈努力，将得到最大限度的掌控。

为了保证我上面的图象给人留下恰当的第一印象，我给了它两枝斧头——两枝是不懈努力，两枝是掌控。

另一方面，这家伙的两枝斧头也让人第一印象深刻。

所有这三种掌控技术都是在不懈努力和掌控之间的权衡。

你可以透过宠信快速地获取大量的功能，然后以应用软件膨胀、黑盒调试、安全修补和耦合升级的形式遭受缺乏掌控的痛苦。在宠信的情况下，你不一定会面临这些问题，但这样做的风险会增大。在你的项目中加进的每一行标识符就好像是一张彩票，会赢得两个非常糟糕的问题。

或是在这张图的另一端，你Cubzac撰写所有的标识符，你将会对进入项目的新标识符进行完全的掌控。不过，你可以花些无聊的时间去把所有的东西都按你的想法去撰写，而你却成了编程的天后。

在我以前的一首诗《多撰写，少宠信》（Write More, Reuse Less）中，我已经详细地阐述了宠信和撰写之间的权衡。

我将会深入探讨两种中间掌控技术（拷贝和改写）。

拷贝

有许多可以拷贝标识符的好地方。如果你要顺利完成的任务可以用一句话来顺利完成，而且标识符不超过 100 行即可实现，所以，你只需把问题输入到搜索引擎，就能轻松地找到。

与 DuckDuckGo 相比，谷歌最大的优势在于：DuckDuckGo作为动词，在会话中会让人感到难堪。

用这种方式来搜索许多简单的标识符任务的问题，你将很快就能找到标识符的天堂。

我从 StackOverflow、W3Schools、MDN、Unity Answers 和各种我懒得记住的地方拷贝了很多标识符。我总是先从搜索引擎开始，在那里提出问题。通常情况下，我会先从我组织工作的语言/平台开始，然后再提问。在我敲标识符的时候，看一下自动顺利完成的内容往往很有帮助。

GitHub Copilot

从拷贝人类答案的机器人那里拷贝你的答案。

如果你更愿意相信由复杂的人工智能为你撰写的标识符短片，可以试试 GitHub Copilot。这是两个集成到 IDE 中的插件。基本上，你并不需要在搜索引擎中输入你想的东西，而是将该文本输入两个略微详细的源码注释即可。然后，实现的源标识符就会自动填充在下面。

是真的！我不是在开玩笑。请看许多关于它的视频。

视频：https://youtu.be/FHwnrYm0mNc

超越标识符短片

如果你想为更大的功能部分拷贝标识符，所以只要：

寻找包含这些功能的开源项目；将所需的文件拷贝过来。

我刚才提出的一种做法，不是很傻是很疯狂。我真心希望你能想到下面那个问题。别让我跟你扯淡。

什么时候从服务器端项目中拷贝会比直接导入更好？

如果你仅仅想将两个倚赖亲密关系的所有未改变的文件拷贝到你的项目中，所以我将会发现这种拷贝方法的缺陷。你拷贝的源码不会轻易地被更新到倚赖亲密关系的新版本。这就意味着你会错过 Bug 修复、新功能和安全补丁。

尽管在许多情况下，对某个特定版本的标识符进行快照非常有价值，但你可以透过构建清单（例如 Java 中的 pom.xml，Node 中的 package.json）采用固定版本来顺利完成同样的事情。而且如果你下定决心要升级的话，所以你可以轻易地更新两个固定版本。

另外两个潜在的拷贝理由是，你可能需要对项目的源码进行修改。如果你要进行增量更改，你可以最好这样做：1. 从原项目中创建两个复刻项目；或是 2. 把你的更改贡献给原项目。这样可以让你在以后更容易从原项目中收到修改。

有三种相同的方式可以让你在你的项目中修改他人的标识符。最上面的一种做法是不好的。

这也许是你大规模、全面地修改你的标识符库。你准备在以后的合并项目中，把一切后路都堵死。那真是太好了。这往往是有正当理由的。但我在责任编辑中所提供的定义是，对源码的大规模结构性的修改属于改写掌控技术，下面我会详细探讨。

我唯一能想到的两个很好的理由是，将服务器端项目的标识符拷贝（而非改写）到你的项目中：你只需在那个项目中得到许多源码即可。

而这种理由出现的频率超出了你的想象。大型 Node 包，如 Lodash 和 TurfJS，都是非常聪明的，它们会提供子集包，这些子集包只是为了你需要的特定功能在函数级颗粒度来导入。不过，在野外中也有很多臃肿的怪物。

Nodelerfish 需要你的爱。但不要让它进入你的项目中。

你也许只需要采用 50 行标识符就可以顺利完成的库 API。但单体导入的库，可能会拉来数十万行标识符，特别是那些具有纵向倚赖亲密关系。在这种情况下，将两个子集拷贝下来，而非将其导入到整个该死的烂摊子中，这完全是很合理的。

开源许可证

我不是两个律师。既然我不是律师，我就会把我在开源许可方面的实践告诉你。你可以咨询顶级律师团队，以达成你他们的决策。

笔者作为非律师，是如何做的：

如果我把源码拷贝到我的项目中，我把它和导入标识符一样对待，并遵循所有的许可条款。在开源应用软件许可的条款中，一般都是指分发源码或是从许可源码中构建的行为。如果拷贝的标识符是我发布版本的一部分，所以它也算作分发。对于我采用的确切的开源许可证，我也非常谨慎，例如，GPL 可能会要求我采用 GPL 许可证来许可我他们的标识符库，而 MIT 许可证几乎不要求我做任何事情。

我还喜欢将拷贝的标识符归入服务器端目录（例如 Github 上的范例），然后在文档的顶部加进注释，这样就可以保证所有的内容都是一致的。

他们不认识我，但 Matt Daly 和 Chris Anderson 是我的标识符兄弟。

改写的优点

你知道你正在拷贝的标识符里有什么吗？它是适宜你的标识符吗？

你能够而且应当对其它人的标识符进行判断。或许不要对那段标识符做出无情的评论。但，请务必为他们的利益，私下评估服务器端标识符。

改写标识符短片

如果是 200 行以内的标识符短片，或是是拷贝的标识符，我一定会逐行改写标识符，这样可以了解到这些标识符是如何组织工作的，并且做许多改动，使之更适宜我的项目。这是为数不多的几次在其它方面进行毫无意义的、风格化的编辑，是有价值的。

我要举两个具体的范例来说明。现在，我要从互联网上某个地方随机找出两个标识符短片，然后进行改写。

左边的标识符是原来的。右边的标识符是我改写的。

我改写的标识符短片是由 StackOverflow 上一位名叫Mark的人发布的。他的标识符透过对每两个点与它的左右邻居进行平均，使折线图中参差不齐的高峰和低谷变得平滑。

概括地说，在改写标识符中，我做了以下的改动：

为变量重新命名，这样更容易显示它们的用途；采用更加具体的方式来声明变量；把某些标识符重构为两个单独的函数，来描述其用途；删除另外两个服务器端库（HighCharts）中的许多数据结构。把空白的地方改了改。

我撰写标识符的风格并不比 Mark 的好。它只不过是碰巧以恰当的方式触动了我的大脑。这并不足以让 Mark 的标识符发生改变。下面是改写他的标识符短片的真实益处：

我学会了那个算法。我现在完全明白那个折线图平滑的组织工作原理了。我创建的标识符对我而言更易于维护，即使对 Mark 来说并不是这样。我可以把那些和我需求无关的部分标识符删除掉。我确认了标识符没有任何错误，比如，无限循环。我已经确认了没有引入安全漏洞，比如在 DOM 中注入两个 querystring 变量。我已经确认了，这些标识符没有加进任何额外的倚赖亲密关系，比如某些统计库。我了解到另外一位技师很享受撰写标识符的乐趣，并且有机会把他的实践为我他们所用。

所以，这种浅改写是一种很好的方式，可以把自己的标识符导入到你的项目中。有些问题是可以避免的。你可以根据你的用例和其它需求对标识符进行调整。另外，你还可以在学习新的算法和实践中，成长为一名技师。

改写的许可考虑因素

笔者作为非律师，是如何做的：

我想，完全的逐行改写应该可以免除几乎所有开源应用软件许可的法律义务。但我始终坚持着开源的理念，例如，在源码的注释中引用原作，或是为原项目提供帮助。

更深入的改写和修剪

有时候，你希望导入多个文档或数千行的源码，并做大量的改动，以让新标识符适宜你的项目。尤其是，修剪掉你实际上不需要的东西，是很好的做法。

下面是两个简单的拷贝和修剪的方法：

将所有的倚赖源文件拷贝到你的项目中。保证你所需的功能能够在实践中起作用。单元测试一般都是非常有用的。把你不需要的部分删除。重复第 2 和第 3 步，直至剩余的标识符能够符合你的需求。至少对剩余的标识符进行一次浅改写，这样才能保证你能够了解并从中得到其它的益处。

你的 IDE 的选择和配置应该能够很好地支持你顺利完成这项任务，包括提示、语法高亮和通知功能，这些功能可以向你显示：

哪些标识符在调用函数。（修剪它们？)哪些函数从未被调用。（修剪它们！)哪些变化会破坏你的构建。（取消修剪！)

如果你的 IDE 没有为你对这些进行适配，可以花点时间去做更好的设置。

git commit 和 git checkout 可以让你设定两个很好的状态，在你因过度修剪而破坏许多东西的时候，能够恢复到之前的状态。这是一张很好的安全网，可以使你的组织工作速度更快。

我都能听见你想说什么了……

可是，要改写标识符的话，实在是太费事了！

我不是说你一定要改写。只有在许多情况下，如果你这么做，就能得到很好的回报。我来告诉你两个真实的案例，我改写了两个服务器端项目，并且从中获益良多。

我先从倚赖树开始，如下所示：

在花了半天时间顺利完成改写之后，我去掉了 5 个倚赖亲密关系的需求，最后得到了如下结果：

有两个名为microphone-stream的 NPM 包，我在 Web 应用中采用它来发送从麦克风捕获的样本缓冲区到语音识别包（Cieran OReilly 的 vosk-browser，如果你有兴趣的话）中的两个USB。

我最初是在让它组织工作的开发阶段采用 microphone-stream。它包含在两个示例 Web 应用项目中，我已经将其拷贝到我的项目中。microphone-stream 运行得很好，直到我升级了两个构建工具（Webpack），这破坏了 readable-stream 的构建，这是两个更高级别的倚赖包。我研究了对这两个服务器端复本任何两个可能的 PR 修复。不过，向仓库提交两个好的修改需要花费好几天时间。我由于种种理由而拒绝了其它的变通方案。

透过查看 microphone-stream 的标识符，我意识到我并不需要该库的核心功能：两个 Node.js 风格的流USB。因此，我认真地改写了那些我真正需要的那部分标识符，把那些我不想的东西删除掉。

一路走来，我在源码中发现了这样的宝藏：

还有那个：

我很感激地将这些想法合并到我改写的标识符中。

作者 Nathan Friedly 在这样的源码注释中阐述了他的思考过程。也许他拯救了我，可能让我以后不用再找漏洞来修复了。从那个角度来看，改写比Cubzac撰写要好。你可以捕捉到自己来之不易的知识。

因此，对我来说，这是两个明显的案例，改写，而非宠信，可以节约我的时间，并且让我得到更好的结果。改写也比Cubzac撰写要好，因为这样可以让我了解其它技师的真实经验，否则我可能会错过这些经验。

拷贝和改写——试试吧！

这是好东西。这算不上作弊。

只要遵循开源许可的条款，和你的技师伙伴成为好邻居吧。

你不希望拷贝或改写所有的东西。但要学习辨别哪些情况值得你这么做。

并享受与其它人组织工作中的联系。那些数以百万计的项目，都是由伟大的头脑构建的。