选择公理_编码者公理

选择公理

如果有一种方法可以消除方程式中的观点和个人喜好，并且明确地确定在两种竞争解决方案下哪种代码更好，该怎么办？

• 开发人员唯一需要同意的是公理本身。 在这一点上达成一致后，成群的主观讨论突然变得无关紧要，并浪费了宝贵的时间。
• 当我们向分散的世界迈进时，就不必屈从不必要的权威。
• 开发人员可以使用扶手来帮助他们一整天做出无数的决定。 充满不确定性的困扰感被值得欢迎的信心所取代。

大约5年前，我想到了这个想法，从那时起，它就经受了来自各个公司的开发人员和建筑师的严格审查。 当我编写原始代码时，我整天无数次思考它，因此很难批评。

并且没有进一步的延迟，这就是…

除非有任何与目标相抵触的方法，否则最小的文件大小后编译胜过任何其他选择。

该语句有两个相反的方面。

1. 目标 ：当然，这可能意味着很多不同的事情。 也许您需要添加更多代码，因为目标需要一定水平的性能，安全性，功能，否则项目必须在截止日期之前完成。
2. 编译后 ：由于公理集中于编译后（或最小化）的代码，因此它绕开了有关代码注释，变量命名或语法糖的任何讨论。 编译器可以保持理论状态，这提供了很多余地。

如何判断预编译代码？

如何确定哪种代码更好的“预编译”需要不同的讨论，这是在考虑“后编译”解决方案之后做出的判断。 话虽这么说，很难说遵循优先级不是最重要的考虑因素。

依赖关系又如何呢？

不用说，依赖关系会增加编译后代码库的大小。 作为生活的总负责人，谁愿意争辩说依赖比独立更好？ 还记得左垫的崩溃吗？ 在没有截止日期的完美世界中，代码库应独立存在……简约，优雅且一致。

当然，目标会在某个时候出现，并在项目上施加时间限制。 在这种情况下，有必要到达架子并引入依赖关系，这种依赖关系不可避免地会在其中包含更多您需要的代码。

在平台与其代码库之间划清界限

实际上，开发人员/团队必须站在其他人的肩膀上。 但是，要在代码库及其基础结构之间放置分界线还有余地。 如果我在AWS上构建项目，这并不意味着在评估某个后编译解决方案与另一个解决方案时就不必考虑任何Amazon代码。

关于软件堆栈（即React，Node，Java，Linux等）呢？ 可能是辩论的问题，什么是基础架构/平台与依存关系。 但是总的来说，我会考虑像React和Typescript这样的依赖项，它涉及一个转译例程，并导致最终的构建文件（后编译）。 Java和Node.js不会显示在构建文件中（忽略诸如Docker之类的东西），所以我不会认为这些平台/语言对利用Coder公理的辩论有任何影响。

在许多情况下，当评估两个相互竞争的解决方案时，它们无论如何都在同一堆栈上运行，因此考虑到平台/基础架构的大小变得无关紧要。

表现如何？

我听到的一个普遍论点是，一个代码版本可能更大，但是由于它效率更高，因此“更好”。 好吧，只有目标实现了！ 您是否听说过过早优化是万恶之源的口号？ 换句话说，如果更小/更简单的选择被证明是足够的，则不要花时间（或代码）使事情更有效率。

要抽象还是不抽象

这是Coder公理真正有用的地方。 我经常看到设计过度的系统，其中在需要出现之前就对结构进行了抽象。 显然，这会在编译后不必要地增大大小。

是否在需要时不寻找重复和抽象的迹象？ 与过度设计系统相反，设计不足涉及复制模式/例程，这会增加编译后的文件大小。

除非您完全确定在不久的将来需要多次使用功能，否则请选择整体。 当您需要随着系统的发展而将某些东西分开时，不要懒惰。 这样一来，您将始终拥有适合您的瞬时上下文的最佳（我的意思是错误最少的）代码。

巨石

亚马逊和Netflix都是从整体上开始的，因为这就是您刚开始时要做的。 随着流量的增加和功能的添加，目标随时间变化。

这是亚马逊AWS产品管理高级经理Rob Brigham在2015年会议上必须说的话。

现在，不要误会我的意思。 它是在多层结构中构建的，这些层中包含许多组件。 但是它们都紧密地耦合在一起，它们的行为就像一个整体。 现在，许多创业公司，甚至是大公司内部的项目，都是以这种方式开始的。 他们采取整体优先的方法，因为它很快就可以快速移动。 但是随着时间的流逝，随着项目的成熟，随着项目的增加，代码的增长和体系结构的复杂性的增加，单块式的开发将为您的流程增加开销，并且软件开发生命周期将不断增加。将开始放缓。

少即是多

想要反对Occam的Razor？

如果我有一个满足目标的可行解决方案， 那么谁愿意站在“添加更多”的角度来满足一些公义的原则或遥远的预测？ “保持简单愚蠢”，并选择优雅。 毕竟，由于没有人能完美地完成任何事情 ，因此“做得越少”，我们的状况就会越好。

翻译自: https://hackernoon.com/the-coders-axiom-7881e88d495d

选择公理