🌐 中文翻译
Manifesto for Minimalist Software Engineers
帕累托原则说明你的应用所取得的 80% 的结果是由 20% 的特性决定的。在计划下一个任务时，要把这个观点牢记在脑中。
最好的工程师能估算需求所需的付出，他们有足够的信息拒绝在最佳范围内之外的 80% 的工作。
践行这个法则！团队不是军队，公司付钱让你做出决定和承担责任，所以如果你觉得需求是多余的应该大声提出来。
你写过的最糟糕的代码就是你不再使用的代码。这样的代码被称为 YAGNI (You Are Not Gonna Need It).
你写过的最好的代码就是你没有写过的代码，因为它是唯一永不失败的代码。
有一些 bug 的修复方法我称为沉淀（通过积累其他的 bug 来修复当前 bug），还有一些称为侵蚀（客户改变了他的主意）。这些都是利用优先级和等待，来把你从无价值的工作中拯救出来的例子。
极简主义并不是说不做事情，而是聚焦于最重要的事情。
可以寻找完美，但不是现在。迭代才是那位会及时给予你好的建议的朋友。
首先去做，然后做好，接着做得更好。
工程师们喜欢想象世界可以被设计，然而大自然却正相反。任何一个足够复杂的系统都不能由设计构建出来，它必须不断地进化。
想象一些都在有条不紊地进行，然后别因为它工作地不好就惊慌。记住 Mosher 定律：程序有问题时不要担心。如果所有东西都没问题，你就失业了。
扼杀掉它，越快越好。不要因为把你努力了一个月的项目丢进垃圾桶。
当你从头开始，以往的经验会给予你创新的能力。
不断地评估你的工作。这就是精益创业这本书的主要内容，制作你的 MVP（最小化可行原型）然后验证它，如果它不合适，那就扼杀掉，你将会从中学到很多。
失败越快，学到越多。
没有人知道所有事情。
尝试让你自己为你的团队赋能。你的团队最需要什么？哪一位是可扩展性方面的专家？哪一位最了解某种编程语言的细节？哪一位最聚焦于产品？哪一位是团队的协调者？
每一个团队都是不同的，所以你必须去接受并且选择，尝试分析出你自己以及团队优势和劣势。
学着爱上一件特别的事情并掌握好它。尝试像一个品牌一样，去定位你自己。你喜欢满足你需求的产品，而不是那些你已经自己做了很多事情的人。
和有同样爱好的人更容易相处是理所当然的事情，但是真正的力量在于那些能形成互补的人，想想 《A字特攻队》你就明白了。
在我们生命的晚期我们才会意识到基础的重要性。通常是一些老人声称他们已经回归基础。不要愚蠢到更不要那么晚才意识到这一点：首先注重基础知识。
在计算机科学中有很多非常有价值的概念，更好的是你可以将它们应用到每一个新的设计中。你应该总是尝试从他们开始自上而下地思考。
借用一句老话，软件开发中重要的三件事情是：架构、架构和架构。
这有一些基础的例子： Separation of concerns, Systems engineering theory, GOF design patterns, GRASP responsability patterns, SOLID principles, Cleancode smells & heuristics, Agile guidelines, Algorithmia, Data structures, HTTP specification…
在你开始挖掘如何使用特定的测试框架 Jasmine, JUint, Mocha 这些细节前，先开始学习如何编写可测试的代码（例如隔离应用程序的无状态代码并减少组件之间的耦合）。
简单比复杂更困难，极简主义需要大量的创造力，才能找到用更少的钱去做更多的事情的新方法。
科技技能可以征服复杂，但是创造力才是简单的主人。
创造力是充满乐趣的智慧！所以享受这样的机会。
所以不要聚焦于工作得更多，而是如何聪明地降低工作量。多多考虑你的工作！关闭”自动驾驶“，离开你的舒适区并控制好。
以及，不要害羞。改变现状需要勇气。但是记住，你所生存地世界是由那些相信可能性的人创造的，而不是比你聪明的人创造的。
当然，有时候人们会觉得你是一个怪人，因为你在尝试不同的事情。但是如果你不是一个改革者，你就无法称为领导者。
举个例子，我非常确定我们很多人都觉得在公司的会议上浪费了太多的时间。因此，亚马逊的创始人兼首席执行官杰夫贝索斯（Jeff Bezos）在他的公司举办会议时，有一种特别的，显然是奇怪的方式。 当所有服务员到达会议室时，他们有30分钟的时间在严谨的沉默中阅读会议报告。 之后会议才可以开始。
我们必须为人类写代码而不是机器，所以综合就是沟通的关键。
一个很好的例子就是帕斯卡的名言：如果我有更多时间，我就会写一封更短的信。
尽量保持方法简单、类单一原则、更少的参数、避免多余的评论等待。当你没有东西可以删除时，你的工作就结束了。
“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” –Antoine de Saint-Exupery
译者注
在软件编程中，您可以通过添加另一层间接层来解决任何问题，除了间接太多的问题。这是事实，这意味着我们必须在设计的复杂性中找到平衡点。
抽象是很好的特性，它允许我们创建一个新的语义级别，在这个级别上可以绝对精确。然而，在某些情况下，比如重构，我们必须对全局有所理解，抽象就让这件事变得困难。
这就是为什么我们必须寻找一个可以进行划分的自然点，然后尝试理解不同的、可能的权衡之法。
一些例子：领域驱动设计中的根-叶范例， 控制器/工具范例， 高内聚/低耦合原理, 简答的 RESTful APIs…
有一个名为 kipple 的概念来表示那些我们留存但是从未用过的东西。我们的房子里充满了这样的东西，我们的代码库也是如此。例如，那些我们害怕删除的遗留的方法、以防万一我们会再使用的库、过时的评论…
人类的本性是把事情复杂化，所以我们必须强化自己来简化。这是一个必须定期遵循的过程，识别哪些是 kipple 并销毁它。
极简主义者：这一切是为了避免分心，以便我们可以专注于重要的事情。
由于我英语能力不及格（还有专业能力不够格…），所以很多翻译细节都是待商榷的。包括一些口语化的翻译。如果您对本文翻译有任何意见或建议，非常欢迎可以直接在 GitHub 上发起 PR 和 Issues。
以及有可能是我个人阅读能力差的问题，实际上有几条我觉得说得并不是十分严谨。我个人也持保留意见。但是集思广益，见贤思齐才是最好的学习态度，欢迎探讨。
原文载于：http://minifesto.org/，由于没有找到原文的许可，所以如果此文章有侵权嫌疑麻烦立刻通知我，我将会马上处理。