Jason van Gumster

我实际上使用 Redmine 管理创意项目。定义自定义工作流程和设置计划（加上 SCM 集成）的能力使其非常适合代码和非代码项目。

我并不一定 100% 确信这始终适用，可以被认为是好事（TM）。我可能会将以下内容视为例外

* 固有的复杂应用程序。本着 Atom（和 Emacs，以及各种其他程序）的精神，是的，你*可以*将文本编辑器扩展为完整的 IDE。但是，如果你的主要重点是开发完整的 IDE（NIHS，等等）或功能齐全的文字处理器，那么简单的核心概念就会开始退化。

* 当你开发高度可扩展的应用程序时，你还会创建另一类需要支持的用户（扩展开发人员）。如果你已经在努力提供常规用户文档，那么添加额外的用户层是一项不可忽视的维护成本，需要加以考虑。它还会增加代码的复杂性……使其*不那么*简单。

* 我在这里有点杞人忧天了，但可扩展性也为商业劫持打开了大门。有一类应用程序致力于为用户提供完成任务（或一组相关任务）所需的所有工具。但是，当用户被迫依赖第三方扩展来完成工作时，原始应用程序就未能完成其使命（尤其是在这些扩展最终成为闭源的情况下）。有时你需要决定你是编写用户应用程序还是编写库/框架。你不可能总是两者兼顾。

* 但即使一切都保持开放，这种可扩展性也会带来用户层面的复杂性。你会遇到支持问题，开头是“为什么我不能做_____？”答案最终是，“如果你使用这些扩展，你就可以做到。”而且，不可避免地，后续问题是，“我到底应该怎么知道这一点？”如果没有某种发现引擎，可扩展性就行不通。打包系统有所帮助，但这又是另一层复杂性（此外，这可能会引入与正在使用的操作系统或发行版的原生打包系统竞争的概念）。

OK... 所以我在这个回复中写了很多（比格式可能舒适支持的要多），但对我来说，我想你可以将其归结为“不，并非*总是*更好。” 如果你围绕这个概念构建你的项目并完成所有脚手架以支持它，那么它*可以*变得更好……但我会警惕（例如）建议大多数现有项目开始朝着这个方向转变。