暴躁的开发者宣言

我每周有 90% 的时间都花在与人相处上。运营一家软件公司，这自然是理所当然的：培训员工、维护工具、完善 DevOps 工作流程、与开源开发者协调等等。

最近在 dev.to 上看到的一篇题为《如何解决开发者倦怠》的文章，让我回想起了过去的一年。我累坏了。我把所有时间都花在了管理和 DevOps 工作上，几乎没有时间写代码。

现在，无论手头上还有什么事，我都开始腾出更多时间用于编程。我必须这样做，才能保持清醒的头脑。然而，尽管我热爱在工作中编程，但编程这件事仍然有一些棘手之处：

• 我必须遵守公司的标准。是的，对我来说可能更容易一些，因为我参与了这些标准的制定，但这些标准仍然在那里：代码风格、已批准的库、许可政策……

• 我必须确保我们精心打造的构建系统一切正常。我构建了这个系统，所以我比任何人都更了解它，但这并不意味着我总是喜欢使用它。我构建它是为了确保我们编写的代码干净、高效、稳定。

• 我的所有编码决策都必须考虑项目和团队的需求。

• 和其他人一样，大多数情况下我都必须提交代码审查。我要对我的员工负责我编写的代码。

• 性能和便携性始终是我最优先考虑的。它应该能够运行良好，并且能够在我们所有支持的平台上顺利运行。

当所有这些目标和期望都是合理的时候，编码仍然是一种相当愉快的体验，但我仍然在为别人编码。

问题是，我天生就不是那样的。我最快乐的时候，就是待在我的塔迪斯里，做我自己的事，不管别人（或者物理定律）怎么说。

这就是为什么个人项目如此重要！独自一人做事，我可以做任何我想做的事。我可以设定自己的目标，规划自己的道路。我不需要向任何人负责，只需要向自己负责。

如果我想写糟糕的代码，那是我的选择！是的，我知道这听起来很糟糕，但这都是为了逃避期望。程序员通常能从错误中学到更多，而坦白地说，拥有完全搞砸某件事而不影响他人的自由，真是太棒了。

因此，为了实现这一目标，我为我的个人项目——一个名为 Elements 的音乐库应用程序设定了一些规则。

需要注意的是，这些规则绝不应该在严肃的生产级项目或公司内部使用。

规则一：这是我的项目

永远不要忘记，这是你自己的个人项目。如果有人知道它——尤其是在 Github 上——人们通常不会羞于与你分享他们的想法。

在某种程度上，这没问题。有人可能会提出一个你绝对喜欢的想法。但是，重要的是要记住，你是这个项目中唯一重要的最终用户。

我知道这听起来真的 很自私，但实际上却很有治愈作用。我们花了太多时间为别人设计软件，为了满足他们的需求而牺牲自己的想法，以至于我们实际上很少考虑自己。个人项目是弥补这一点的好方法：只有你的想法、你的偏好、你的设计感和你的工作流程才能最终决定最终结果。

你必须为自己设定这个界限。如果你想构建一个文本编辑器，并将你最喜欢的字体和配色方案硬编码进去，那就去做吧。如果你只想支持你选择的操作系统，而忽略所有其他操作系统，那也没问题！如果你想让整个界面只能通过一套只有你才知道的深奥键盘快捷键来工作，那就别管设计标准了，祝你一切顺利！

现在，您很可能想让其他人也能使用您的个人项目，但这是您刻意选择的功能，而且成本很高！最好将用户群限制为特定个人，而不是整个群组。例如，Elements 是为两个人打造的：我和我的母亲。现在甚至没有其他人参与，这让它变得有趣！

然而，有一个重要的推论，它能让你脚踏实地：你需要成为你自己的最终用户。构建一个你会用到的东西。无论是否接受治疗，你都不想养成以牺牲设计为代价来编写便捷代码的习惯。你是为自己设计，但你仍然是在设计。

规则二：该做就做

在这样的个人项目中，你应该让大家知道，除了你自己设定的截止日期或日程安排外，你不需要承担任何责任。慢慢来，享受生活！

这条规则也应该适用于你自己。我们已经花费了太多时间试图按计划完成代码，目标是在截止日期前交付生产。没有什么比紧迫感更能扼杀项目带来的乐趣了。所以，除非为任务设定目标日期真的能增加你的乐趣，否则就不要设定任何目标日期。随遇而安吧。在这个领域，这已经是难得的奢侈了。

这条规则也很重要，因为它使得下一个规则成为可能……

规则3：过度

避免“潜移默化”功能主义（或“费普式创造主义”）是有时间和场合的，但这里不是！鉴于我们花费大量时间自我审查项目功能，使其符合实用性和现实性，我们需要一个机会让想象力自由驰骋。

这意味着，如果你想让你的自定义代码编辑器拥有一个可以远程启动咖啡机的键盘快捷键，你绝对应该把它列入你的待开发功能清单。没错，考虑到你用的是树莓派和一些自定义代码来实现，这个功能对其他人来说可能完全没用，但谁在乎呢？你可以享受按下 Ctrl+Alt+J 的便利，冲泡一杯新鲜的咖啡。

然而，要做到这一点，你需要为自己设定一个简单的规则：你应该使用问题跟踪器，并确定构建代码的顺序。如果你花了三个月的时间让文本编辑器与咖啡机对话，却无法在编辑器中运行代码，那么你很可能会对编写的程序感到非常不满。更糟糕的是，如果你先开发了咖啡功能，然后又决定连接烤面包机，那么你可能会因为一时兴起而忽略了代码编辑器最基本的功能。

相反，你应该把你的想法写在问题跟踪器里，然后决定是否以及何时着手处理它们。也许四个月后，你就会意识到自己其实根本不喜欢吐司，于是就把这段时间花在集成你最喜欢的静态代码分析工具上。

简而言之，不要让任何事情阻止您计划在项目中添加您想象到的任何功能，但是为了您自己的理智和乐趣，请努力优先考虑这些功能。

规则四：从欺骗到稳定

我们常常因为bug 而无法自由地编码。专业的项目首先需要稳定；如果程序每隔十分钟崩溃一次，那么它即使能正常工作也无济于事。

另一方面，在个人项目中，稳定性并不是一个必然的因素！你是这个项目中唯一重要的最终用户（规则 1），而且你可能知道如何不破坏软件。

你应该始终跟踪错误，但可以无限期地推迟修复它们。如果它们没有困扰你，而且你不想调试它们，那就别调试！调试有时很有趣，但有时也可能很麻烦。你应该对个人项目充满期待。

规则 5：制定自己的实践

标准对于确保代码整洁和协作顺畅至关重要。在工作中，你几乎肯定会遵循某些惯例。我们还必须考虑“良好实践”，通常情况下，还要考虑“流行实践”。

然而，在你自己的项目中，你应该暂时放下别人强加给你的各种负担。你应该在项目进行过程中制定自己的个人标准，并坚持执行。

一致的代码风格有助于确保代码易于维护。如果您发现自己的代码风格经常不一致，可以考虑使用 AStyle、clang-format或其他一些自动代码风格调整工具来帮您完成繁重的工作。

至于其他所有事情，请反转通常的规则：不要按照“练习 > 偏好”的顺序，而是“偏好 > 练习”。我对此非常认真！在特定情况下，使用生成器代替 for 循环是否被认为是更好的做法并不重要；重要的是你更愿意写哪种！如果你愿意，你随时可以回头重构，但这并不意味着要写成生产代码；这只是为了写出有趣的代码！

规则 6：随意许可

我个人并不喜欢 GPL，出于道德原因，这里就不多说了。在工作中，我们必须非常谨慎地对待它。然而，在 Elements 中，我遇到了一个独特的问题：那些能让我编程体验最有趣的库都是 GPL。在几个月的犹豫之后，我最终决定，许可证根本不重要！我仍然可以把我的代码写成 BSD-3，将整个项目都按照 GPL 许可证授权，并满足所有法律要求。

无论您是否认同 GPL 许可证的宗旨，您都可能从中获得最佳的开源编程体验。根据您所使用的库和工具，找到最合适的许可证，然后继续下一步。

还有另一种更激进的做法。如果您不打算共享或发布代码或软件，您可以完全放弃许可证。这样一来，您实际上就只是在学习而已。您可以使用完全不兼容的许可证的部分内容，甚至不用费心为自己的作品设置许可证。但请记住，永远不要让该项目公开。不要把它放在 Github 上，不要把它发布到您的网站上，什么都不要做。建立一个本地仓库，并将其私下托管。

关键在于找到阻力最小的路径，无论是技术上还是法律上。让自己处于一个可以使用所有所需库和代码的位置。

规则七：你不是外交官

这不是一个大型的公开项目，而是一个属于你自己的项目。如果你把它发布到 Github 或类似的网站上，你可能会收到来自外部贡献者的 Issue、Pull Request 等等。因此，虽然你不应该表现得粗鲁无礼，但你应该为你的互动方式设定一些明确的界限。

所以，在我的 Github 项目中，我会提醒大家我的期望。简而言之，我并不想阻止任何人做出贡献……

• 功能请求可能会因任何原因（或无原因）被拒绝，

• 如果我不想修复错误报告，它们可能会被忽略，

• 拉取请求可能会被无限期忽略或因任何原因被拒绝，我无需做出任何解释。这并非针对我个人。

结论和警告

我认为，为了乐趣而进行项目对开发者的健康至关重要。它能让我们保持技能敏锐，让我们有机会探索和实验，最重要的是，它能提醒我们最初热爱编程的初衷！为了达到最佳效果，这些个人项目应该与生产代码有所区别，这就是上述规则的意义所在。

但是，正如我之前提到的，您永远不应该将 Cranky Developer's Manifesto 应用于生产级软件项目。

如果您确实想将 Cranky Developer's Manifesto 应用到您的项目中，请考虑在您的存储库中包含以下文件CRANKY.md：

# THE CRANKY DEVELOPER'S MANIFESTO

I am developing this project for the sole purpose of my own enjoyment.
I make no promises about release date, features, usability, stability,
practicality, or compliance with any normal standards of software
development.

In pursuit of my unhindered enjoyment of this project, the only end-user
I choose to care about in this project is myself, and maybe a few select
friends. The timeline, the features, and the implementation are all
solely at my discretion. I reserve the right to make arbitrary decisions, 
and change them at a moment's notice, without owing anyone an explanation.

If you see something here you like, you're welcome to fork the code under
the terms of the LICENSE and do as you wish with it.

If you're still intent on treating this as a viable project, you're welcome
to submit issues and pull requests. I may respond, or I may leave it sitting
indefinitely. If I ignore your bug report or brilliant contribution until
doomsday, don't take it personally.

If you decide to try and *use* this software, you're taking your sanity
into your own hands. As long as it runs on my machine, that is all I care
about. It may be unstable, or not support your system. I offer neither
warranty nor technical support.

Long story short, I'm just coding for the love of coding!