好代码的三个基础

　　是什么使代码对您，您的团队和项目更有利？

　　最好的软件工程师（程序员，编码员，开发人员，无论您偏爱什么术语）的真相并不是他们编写的代码更加优化，也不是他们解决的难题非常艰巨。 他们除了编写代码之外，还考虑其他所有事情。 他们了解协作和知识共享的重要性，知道自己会犯错误，并且意识到使自己和同事的生活变得更加轻松的好处。 以下是围绕这些方面编写更好的代码的三个基础知识。

　　可读代码优于完全优化的代码

　　首先，我并不是说您不应该优化代码或寻求更有效的实施。我的意思是，您不应为此牺牲代码的可读性。在软件工程的某些领域，效率是基本的驱动要求，必须不惜一切代价优先考虑，但这是1％。大多数代码在具有足够资源且有足够执行时间的机器上运行。但是，所有生产代码都需要维护。它将在编写6个月后由某人读取，并且可能由最初不是编写该文件的人读取。即使您确实编写了代码，也有可能在6个月后代码看起来像是别人编写的代码，而您对它的工作方式没有足够的记忆。这就是为什么人类可读的代码是头等大事。可读的含义很多，但应包括：描述性变量，类和方法的名称；数据处理步骤的逻辑进程；和注释（但请在代码更改的同时保持注释为最新）。通过使代码简洁明了，您可以降低将来维护和扩展代码的门槛。相信我，将来的你，以及你的接班人，将感谢你。

　　单元可测试代码是可扩展代码

　　如果您无法测试代码，则无法有效地扩展代码，在代码之上构建新功能或修复其中的错误。 如果由于相互依存的关系而编写单元测试很困难，那么出于相同的原因，将来修改该代码将很困难。 此外，如果您没有单元测试，您将无法确定所做的任何更改都可以实际起作用。 而且更重要的是没有破坏现有的预期功能。 单元测试在这里至关重要的原因是，尽管您可能会在较大的功能或集成测试中发现错误，但是您将拥有更大的表面积可调试以发现问题。 从根本上调试单元测试失败，您甚至可以在开始之前就发现存在问题的几行。

　　单元测试是基本要求，除此之外，可能的和合适的测试级别会因项目和环境而异。 有时进行全面的端到端功能测试是可行的，但有时为此所需的模拟设置的成本要超过它会遇到的新问题。 有时组件级别的集成测试很有意义，有时它们除了单独的单元测试和共享合同之外没有什么价值。 无论您的团队将其称为功能测试，功能测试，集成测试，还是其他可用的不同名称和类型中的一个，单元测试都是重要的第一道防线。

　　隔离尚未投入生产的内置代码

　　这同样适用于整个系统以及代码。 如果它们是由单独的开发人员独立设计和/或构建的，则它们还没有准备好以任何有意义的规模用于生产。 代码/系统可以很好地正常运行，并确保个人项目可以接受。 但是，当您作为团队的一员，在成千上万的人使用的项目上工作时，仅"正常运行"并不能衡量生产就绪。

　　那么，孤立地完成工作时会缺少什么呢？ 至少，不会考虑外部的观点，经验和问题。 所产生的创造力不可能使所有参与其中的人都满意。 无论是最终产品的客户，负责维护和开发最终产品的开发人员，专注于"销售"该产品的业务人员或营销人员，还是任何需要支持，使用， 或"支持"创作。

　　比这更重要的是，单身的开发者将是结果的唯一"所有者"，当出现问题时这是一个真正的问题。 当"彩票因素"为一个时，对构建它的开发人员和其他需要帮助处理它的开发人员都是不利的。 （旁注：相对于公交车因素，我更喜欢彩票因素，因为赢得彩票与被公交车撞到的同事的形象要好得多。两者本质上都代表了不再有多少人会把一个项目置于危险境地。 ）低中奖因素也不利于项目未来改进的速度。 有各种各样的人了解某事物是如何构建的以及如何工作的，这意味着他们都可以帮助推动该事物的发展，以及与他人共享知识。