“发明于此综合症”

你害怕编写代码吗？你的脑海中是否总是萦绕着“肯定有人已经做过类似的事情”的想法？你是否发现自己陷入了无休止的分析循环，却一事无成？你的产品是否为了兼容第三方组件而不断改变？如果是，那么你可能患上了“我发明综合症”。

我们大多数人都了解“非我发明”综合症，但反过来的问题或许同样棘手。我们很容易陷入一种思维定式，认为一定存在某种产品、库或代码示例，能够满足我们的需求。我们花费大量时间测试各种模块，并试图将它们硬塞进自己的系统中。但最终，我们需要停下来，自己编写代码。

重读这篇文章后，我不禁思考，这个问题有多少是源于冒名顶替综合症。我在我的书中也探讨过这个问题，并且分析了优秀程序员应具备的所有技能。或许，我们很容易看着别人的代码，就想当然地认为他们已经完全掌握了所有知识，而我们自己却并非如此？这种想法会阻碍我们开发自己的解决方案。

质量水平参差不齐

一般来说，我们不应该编写已经存在的代码。很多时候，选择很简单。我们直接使用一个标准产品，把它集成到我们的系统中，它就能按预期运行。这种情况令人欣喜，而且也确实经常发生。

除此之外，还有一些不太理想的选择。也许某个库只能满足 95% 的需求，配置起来可能比较复杂，或者用途需要稍作调整。虽然也能用，但需要付出一些努力，或者重新思考一些需求。

在某种程度上，我们会遇到劣质产品。这些产品广告宣传能满足我们的需求，但实际上却完全无法胜任。或许它们的功能与预期完全不符。也许集成极其麻烦。或许产品漏洞百出，令人无法信任，又或许文档糟糕透顶，让人摸不着头脑。

就我所见，绝大多数的编码产品、代码片段和库都属于这种劣质软件。即便它们出现在包管理器中、下载量达到数千次，或者拥有精美的网页，也并不能说明它们就是好产品。发布编程产品轻而易举。对于任何冷门的需求，很可能已经存在相应的产品。但仅仅因为某个产品存在，并不意味着它就应该被使用。

我需要指出的是，任何项目的绝大部分都是由标准产品构成的。例如操作系统、编译器、文件系统、shell 和构建系统。此外，还有内置库，例如 SSL、HTTP，甚至用于渲染 HTML 的浏览器。因此，担心项目使用的标准组件不够多，通常是一种没有根据的担忧。

当我们搜索合适的产品时，应该很快就能发现根本没有合适的。我们会找到一些模块，但要么不太理想，要么质量很差。当我们添加新的搜索词时，要么一无所获，要么得到相同的结果。那些看似合适的热门产品列表中，也没有真正符合要求的产品。就这样，搜索已经结束了。

我并不是说我们应该立刻着手编写自己的模块。不，现在评估至关重要。时间通常是关键因素。编写一个自定义组件需要多长时间？改造现有产品又需要多长时间？

我认为，使用不太合适的第三方产品所节省的时间必须比自己编写代码节省的时间高出一个数量级，才算值得。第三方代码存在很多未解之谜，无论其评估多么完善。这种不确定性必须纳入我们的考量范围。

陷入分析瘫痪是非常糟糕的。我并不介意在完成分析之前就编写代码。我认为这是一种有效的评估方式。通常，在尝试实现之前，我无法确定自己真正需要什么。项目停滞不前可能会造成灾难性的后果。也许我目前编写的快速代码已经足够，我们可以把最终决定推迟到以后再做。

很容易陷入功能堆砌的陷阱。产品的全部功能看起来确实令人印象深刻，极具吸引力。但谁会关心产品能做的所有事情呢？我们的项目有一份具体的需求清单，而这些需求才是我们应该关注的重点。

很多热门产品都存在这个问题。它们提供完整的解决方案，但我们需要的并非如此。它们拥有我们想要的功能，但却无法高效地提取出来。我们需要单独查看各个功能。这与时间成本息息相关。显然，重新开发产品 Xyz 需要耗费数百万工时，但模块 Q 或许只需几天就能完成。

其次，要考虑某个需求对我们自身产品的重要性。如果牺牲了我们的核心卖点，项目注定会失败。如果节省时间最终无法得到预期的产品，那就毫无意义。我们有时必须面对现实：实现所需的功能集可能需要编写大量代码。但我们是程序员，所以这不应该吓倒我们。

警告！在此抱有幻想毫无益处，而且往往会导致“非我发明”综合症。虽然功能可以通过多种方式实现，但我们真的需要完全按照我们想要的方式实现吗？投入到我们版本开发中的时间必须与该功能的重要性成正比。最好让市场营销或产品管理部门参与到这类决策中来。有时，我们很容易忽略真正重要的东西。

纠结于一系列不尽如人意的产品并无益处。虽然避免“非我发明”综合症完全合理，但过度害怕编写代码可能会让项目陷入生产困境。软件开发涉及编码，这本就不足为奇。

网络上大量的库、模块、代码和其他软件产品要么本身就很糟糕，要么根本不适合我们的项目。强行让它们协同工作可能比我们自己编写所需的代码成本更高。

如果编码最终被证明是错误的选择怎么办？嗯，这是开发过程的一部分。完全有可能，我们尝试自己开发组件的过程中，最终会找到更合适的第三方产品。由于我们遵循了良好的设计实践，因此根据需要替换组件不会造成太大问题。

你想学习如何克服不确定性吗？读读我的书《什么是编程？》。我为你提供了一份成为一名优秀程序员所需技能的路线图，并帮助你增强做出正确决策的信心。