The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
几周前有人建议我尝试将IntelliJ IDEA的静态分析规则整合到我们的聚合器Qulice中，Qulice是我们的Checkstyle、PMD、FindBugs以及其他一些分析器的聚合器。我确实喜欢IDEA的规则，其中一些是独特且非常有用的。我询问是否可以在Maven Central中找到它们（它们是用Java编写的），答案是“你必须自己弄清楚如何使用它们，但它们是开源的。”现在我对这种情况发表一下我的意见：我认为开源不仅仅意味着代码可以在未经授权的情况下阅读，它意味着更多的东西。
仅仅将一段代码公开访问并不足以称之为开源软件。实际上，如果软件开源但不准备好重用（这是开源世界的核心），它只会损害产品和作者的声誉。正如Eric Raymond在他著名的文章大教堂与集市中所说：“好的程序员知道该写什么，而伟大的程序员知道该重写（和重用）什么。”
软件产品的作者有责任帮助那些“好”的程序员重用代码。编码、测试、调试以及确保“在我的笔记本上可以工作”是一回事。使其可读和可重用则是完全不同的工作，可能需要更多时间。
正如Karl Fogel在开源软件的生产一书中所说：“大多数自由软件项目都会失败。”它们失败（除了其他许多因素外）是因为没有足够关注以下基本事项（无特定顺序）：
我相信你将你的产品托管在GitHub上。（如果不是，那你怎么了？）在根目录下一定有一个名为README的文件，它解释了产品的内容以及我们应该如何使用它。以下是一些好的例子：leejarvis/slop, mongobee/mongobee ronmamo/reflections和yegor256/takes（这个是我自己的）。以下是一些不好的例子：qos-ch/slf4j, rzwitserloot/lombok,和junit4/blob（不要像这些人一样）。
无论你的网站、Javadoc、Wiki、邮件列表和Twitter有多丰富，README都是我们期望看到一切的地方。只有在我们感兴趣时，我们才会进一步深入调查。阅读其他项目中的README文件，并复制他们最好的想法。README是你的展示窗口，它必须闪耀夺目。
大多数人都不注意这个官僚主义。直到最近，我也没有注意。我以为只要我的代码是开放的，我就可以忘记任何权利和版税。他们只会使用我的代码，而我不会看到任何利润。我附加给它的许可证无关紧要——反正没人会读。在大多数情况下，情况确实如此。但只有在用户规模较小的情况下。
几年前，我是一个软件项目的架构师，我们必须创建一个硬件组件的分析器，比如CPU、内存、硬盘等。我们必须确保在运行相当复杂和定制的测试之后，它们都能正常工作。我显而易见的建议是使用开源工具，这些工具可以为我们完成艰巨的工作。我们只需要集成它们。这是一个很棒的主意，直到我们中的一些人决定检查这些工具的许可证。
那时我意识到，我没有注意许可证的内容是多么错误。例如，我们在一些工具中发现的GPL不允许我们在我们的产品不是开源的情况下重用代码。由于我们正在创建专有软件，我们理解我们无法使用copyleft模块，只能使用MIT、BSD或类似的许可证。
我建议在发布产品之前考虑许可证问题。自2016年以来，我在所有的产品中都使用MIT许可证。
一个简单的 .rb 文件集合并不能算作可重用的 Ruby 代码。对于那些我非常鄙视的黑客来说，或许可以。但对于那些太懒得看自己的代码，更别说别人的代码的专业开发人员来说，绝对不行。
“从GitHub上下载”不再是一种礼貌的对待我们这些同行程序员的方式了。二十年前可能还可以，但现在我们有了代码仓库。你必须通过其中一个公共代码仓库将你的产品作为“构件”分发出去，让我们能够从那里获取它，跳过测试和打包过程，直接将其用作产品（例如 Ruby gem 或 Java JAR）。
我所说的代码仓库类似于 Maven Central、npmjs 或 RubyGems。你必须找到一种方法将你的产品部署到这些仓库中。虽然这些仓库尽力简化了这个过程，但这并不是一项容易的任务。我们在所有项目中都使用 Rultor，它帮助我们简化了部署流程：
“yegor256/xcop 到 RubyGems（详情）；”
yegor256/tacit to npmjs.
“yegor256/tacit” 迁移到 npmjs。
软件包管理器，如Maven、NPM、Rake、Grunt、Gradle和其他，是重用开源软件（也包括专有软件）的标准和传统方式。如果您的产品不在公共仓库中，它就不是一个产品；它只是一个代码库。
我们都讨厌编写文档。我们也讨厌没有文档的库。我通常觉得为我的类编写 Javadoc 块很无聊，但我知道如果没有它们，我在这些类中编写的代码将不会引起任何人的兴趣。
对于这些 Javadoc 块来说，最好的格式是“通过示例”。我建议您展示如何使用该类，特别是与其邻居结合使用。此外，我建议您不要在除了这些 Javadoc 块之外的任何地方编写文档。（它们也存在于其他语言中，但是有不同的名称。）
Javadoc 的问题在于很难使文本格式看起来视觉上吸引人。也许这就是为什么许多程序员仍然依赖 Wiki 或项目网站的原因。我建议您留在 Javadoc 块内并学习它们的格式语法。
正如你可以看到的，我喜欢徽章。首先，它们使得一个仓库看起来像是“正在积极维护”，尤其是那些绿色的徽章。它们实际上并没有提供任何有价值的信息。它们更多地表达的是：“我们的作者品味很好，看看我们的颜色多么完美匹配！”
开个玩笑，但是添加所有这些徽章并不容易。每个徽章都需要花费一些时间，整合第三方系统，确保数字足够好以值得骄傲，并且保持其可控性。如果仓库没有受到监督，这些徽章最终将会开始失效。
为了使用你的代码，我们必须信任它，也就是说我们必须确保它能正常工作，或至少通过自动化测试。（我需要说你必须有测试吗？）我们如何确信它能正常工作？持续集成（CI）是答案。我们必须能够查看最近的CI构建日志，并确保其干净。
这是一个信任的问题。你可能从不使用那些特拉维斯构建，也可以忽略它们的红色和绿色信号，但对于我们——你的客户来说，它们很重要。我在创建新的代码库后，会为所有项目添加特拉维斯徽章。
对于一个经常使用GitHub的人来说，找出如何给你发送一个pull request并不是一个问题。然而，大多数人，至少起初，都是活跃用户，而不是贡献者。我们会试着使用你的产品，并尝试根据我们的需求来定制它。如果我们迷失了方向，我们会感到沮丧并离开。
为了防止这种情况发生，你需要解释一个守纪律的贡献者需要如何对你的代码库进行更改。以下是我建议你在你的CONTRIBUTING.md中回答的问题：
一个合并请求需要多大/小才能被接受？
你们的风格指南是什么？
如何报告、标记、解释错误？
什么会让一个错误报告变得优秀？
这是我在所有项目中使用的文本：ISSUE_TEMPLATE.md 和 PULL_REQUEST_TEMPLATE.md。
最后，如果你很幸运，我们将使用你的产品并有兴趣做出贡献。你将开始收到我们的拉取请求。问题是我们将以多快的速度破坏你的代码基础。如果你不保护自己的话，我们就会这样做。
如果你严格审查每个拉取请求，并拒绝任何看起来不像“优秀”代码的东西，你将失去我们，你的贡献者。我们不想写出优秀的代码，我们想要对你的产品做出改变，使其更适合我们的需求。代码的优秀程度是你的关注点，而不是我们的。
另一方面，如果你接受任何东西，架构将失去其健壮性（如果曾经有的话），你将再次失去我们，你的贡献者。这次你将失去我们，因为产品将变得糟糕且难以维护和贡献。
保持平衡的最佳方法是“雇”一个工具来帮助你：构建自动化、静态分析、自动化测试和覆盖控制。你必须配置产品，当有人的更改违反其内部质量期望时，它会失败。我也使用Rultor来实现这一点。
我有什么遗漏吗？
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-28 at 15:02
