正如传说中的作家儒勒·凡尔纳（Jules Verne）正确地说的那样：“充分利用最低限度就足够了。” 在我们这个时代，合理使用最低限度的概念适用于代码。 令人遗憾，但事实是：在现代代码世界中，太多了。 更准确地说，有太多不必要的代码，其中有用的代码简直令人窒息。
鉴于以上所述，默认情况下，不必要的代码是有害的。 随着时间的流逝，它会恶化。 它需要持续的支持。 它包含您需要查找的错误。 当出现新功能时，旧代码必须适应它们。 您拥有的代码越多，其中可能出现的错误也就越多。 验证或编译花费的时间越多，新员工就越会理解您的系统。
在所有这些跨越之上，代码是由程序员编写的。 它越多，就需要更多的程序员。 随着程序员数量的增加，它们之间的通信成本也增加了，这进一步增加了开发和维护代码的资金。
对于所有这些问题，有一个解决方案：编写更少的代码。 这种方法有很多优点：
- 开发更少的代码=更少的开发成本
- 开发中更少的代码=更少的维护成本
- 开发中更少的代码=更少的错误
- 开发更少的代码=更有效的测试
最重要的是：您强迫人们阅读的代码越少，某人完全阅读它的可能性就越大。
您可以通过以下方式减少代码。
YAGNI原则（“您不需要它”）
“您不需要它”（通常称为YAGNI-您不会需要它）原则意味着以下极端编程规则：“仅在真正需要时才意识到这个机会，而在您假设时才意识到很快就会需要她。” 即使您百分百确定将来不能完成此功能，也不要立即开始实施它。
这种做法有两个原因：
- 通过拒绝编写当前不需要的代码来节省时间。
- 代码的质量提高了-即使未确认这些猜测，也不会使用基于或多或少正确猜测的片段污染代码，并将其保留在代码库中。
无论您采用哪种项目管理方法，YAGNI的概念都非常合理。 好的架构需要平衡各种可能性。 不良的体系结构由许多草图函数组成，这些草图函数会生成您苦苦支持的代码库。
这里的基本规则是：专注于明显需要的东西，而不考虑可能发生的事情。
不要编写无懈可击的代码
无懈可击的代码是理想的代码，它可以在任何输入数据和任何条件下运行。 创建类似内容的想法有其自身的吸引力，特别是对于那些雄心勃勃的开发人员，他们在某些情况下将失败视为个人侮辱。 但是，编写（或尝试编写）无懈可击的代码是一个空洞的想法，因为世界上的所有事物都有其自身的局限性，并且代码也不例外。
尝试实现理想的模块时，您将规定其他条件，从而增加了代码库的复杂性，这与代码的实际目的背道而驰。 随着时间的推移，该模块将变得越来越广泛，消耗更多的资源，并成为不小心维护的候选对象。
这就是为什么如果您打算编写更少的代码，则应该从“如果可行”类别中争取最简单的实现。
《极限编程指南》提到了编写简单代码的两个黄金法则：
- 首先，以只能使用的最原始方式实现新功能。 不要竖立令人叹为观止的上层建筑，不要完善自己-仅确保一切开始。 确保代码通过了单元测试，以测试新功能（和以往一样，也测试了旧功能）。
- 然后-这是规则的关键部分-重构系统并尽可能简化产品中当前包含的所有功能的代码。 遵循DRY原则和其他有助于使系统整洁的原则。
不要忘记：我们不是为最短的路径而努力，而是为最简单的结果而努力。
因此，我们首先将现有方法分为几部分。 在这种情况下，测试选项将正常运行。 然后，我们着眼于下一个测试选项，改变（朝着简化的方向）其中一种小型方法，以此类推。
请记住，简约是优雅的核心。 控制和消除不必要的复杂性的能力是熟练的编程。
不要使代码更糟
该规则可以被视为对开发人员的希波克拉底誓言。 那些参与编程的人经常听到提示，不要偷工减料，不要寻找会损坏代码并导致其性能下降的变通办法。
像医疗程序一样，软件开发程序通常涉及重大干扰和破坏性行为。 此外，我们使用的工具和技术通常是新的且未经验证（或验证不足）。 最重要的是，我们没有类似的医疗许可委员会或产品控制办公室来管理我们选择的实践和开发工具。 因此，我们有时使患者（即软件）接触与不必要风险相关的程序，甚至不完全了解这些风险是什么。
有时，在解决问题的过程中，弊大于利。 史蒂夫·麦康奈尔（Steve McConnell）在他的《完美的代码》一书中，该书是程序员的黄金文献之一，他写道，如果您不是针对问题的根源，而是针对其症状，那么只会使情况变得更糟-您在自欺欺人，产生了问题已解决的幻想。
但是有时遵守此规则可能非常困难。 有时过时的代码处于这样的状态，即实际上不可能在不损害新功能的情况下正确实现新功能。 因此，为了更加现实，您需要稍微改写一下规则：从“不要使代码更糟”到“如果降低了代码的质量，您必须知道自己在做什么”。
没错 如果您看不到实现必要功能且不破坏代码的方法，请在进行更改之前警告其他团队成员。 最重要的是，在这种情况下，您有意降低代码质量。
当然，这不会使错误的代码变得更好，但是那样一来，您将有时间考虑这种情况。 经验表明，人们往往不能仅仅因为准备好接受他们想到的第一个想法而就无法获得最佳解决方案。 请注意，我们不要求您寻求许可或帮助找到最佳解决方案。
这种方法的另一个优点是，它减少了在困难时期出现意外惊喜的可能性-整个团队都知道应该预见到哪些问题。 因此，您可以全面了解团队工作，并及时处理这种情况。
避免过多的并发
并发是一把双刃剑。 只有在没有它的情况下才应诉诸于此。
当代码按顺序执行时，更易于理解和查找错误。 使用并发时，操作将同时执行或以扭曲的顺序执行。 这种特定的实现方式在识别和修复错误方面产生了很多问题。 显然，它使功能的体系结构和实现一次在多个级别上复杂化。 以下是并发执行不当可能导致的一些问题：
- 竞争条件：操作开始意外地发生
- 相互阻止：涉及的对象在等待同时完成操作时交叉阻止
- 缺乏资源：该操作无法稳定地访问其期望的必要资源
与软件开发相关的最引人注目的灾难之一正是由错误规定的相互依存条件造成的。 放射治疗设备Therac-25发生编程错误，导致四人死亡。
应当指出，大多数现代编程语言和框架都提供了用于调试并发性的特殊工具。 但是，最终，这完全取决于开发人员-由他来决定何时，在何处以及如何应用它们以达到最佳效果。
不要bump积ho
病理性ho积是一种行为，其特征是聚集了大量不必要的东西，并且不愿摆脱它们。 但是，东西占据了大部分生活空间，这可能导致受伤和压力。
当积累的症状出现在开发人员中间时，他们开始坚持使用任何代码，即使该代码已经过时或存在错误。 这样的开发人员从不自己删除代码，并且通常反对这种做法。 如果您直接告诉他们有关此问题的信息，请本着精神：“也许有一天需要他”或“没有这个，我将无法执行操作X”，依此类推。
普鲁什金综合症曾经袭击过您吗？ 也许是因为您了解自己根本没有足够的时间弄清所有这些混乱情况而放弃了整理事物的想法？ 如果是这样，那么您仍然会遭受ho积和工作中完全混乱的局面。
储蓄是不合理的。 如果在您看来某些代码的存在是合理的，但您不确定是否完全正确，请对其进行相应标记，以便稍后返回。 因此它不会掉出您的记忆。 至于那些没有实现特定目的并且不是至关重要的代码，必须删除它并指出重点。
一个好的程序员正在每天改进代码，并且随着时间的推移，代码的质量正在稳定增长。 优秀的程序员编写的过时的代码始终以其准确性而著称-专业人士不会把自己弄得一团糟。 毕竟，代码是我们的声誉，将由他们来判断我们。 正如罗伯特·马丁（Robert Martin）正确地说的那样：“真理只能在代码中找到。”