【51CTO.com快译】在金融行业，可理解性指这个概念：应该以一种使读者能够快速轻松地理解的方式呈现信息。要做到可理解性，财务系统必须完整、简洁、清晰且有条理。
需要将可理解性概念引入到软件世界。
我们已看到，微服务、云和分布式系统的兴起都增添了现代系统的复杂性。这意味着我们的开发团队必须更努力地工作，才能高效构建可以由越来越多的开发人员轻松维护的应用程序。
我们如何编写代码?
可理解性始于我们编写代码的方式。作为开发人员，有必要花时间进行重构，以确保我们编写的代码易于被同事理解，还要易于被最终在下个月、下一年甚至十年后调试我们代码的程序员理解。除此之外，只有内联注释和外部文档完整、简洁、清晰且有条理，才应批准变更请求。
- 完整：含有开发人员理解某个组件的预期行为所需要的所有信息。
- 简洁：以一种易于扫描以查找重点内容，且不太麻烦或重复的方式来加以编写;以一种含有相关信息，没有太多其他信息的方式来加以编写。
- 清晰：格式和介质易于扫描。在软件开发界，这通常转化为内联注释和维基页面。
- 有条理：以一种使读者易于相互对照信息的方式呈现信息。精心维护的维基页面或者与IntelliSense工具或源代码控制管理工具集成通常在这方面很有效。
文档和注释上花点时间似乎会减慢某项功能的开发。但正如有人曾说过，如果您有六小时的时间来砍树，花前四个时间来磨斧头是明智的。前期工作将使我们的应用程序将来调试和维护起来要容易得多。因为如果应用程序变得错误过多，太难支持，交接过程变得太耗时、效率低下，我们到头来会把整个迭代开发周期(sprint)耗费在改进文档、单元测试和日志记录等方面上。
在微服务和分布式系统这个复杂的世界，开发人员花在阅读代码上的时间要比花在编写代码上的时间多10倍，因此我们编写的代码干净、很容易展示给他人来得无比重要。
部署代码后
即使您编写了干净、文档完备的代码，在云和分布式系统世界，仍然很难预测该代码在部署后会有怎样的行为。干净的代码好比详细的烹饪食谱：它清晰地阐明了应该发生的事情，您在准备饭菜过程中会常常查阅食谱，但是食谱可能无法知道烤箱的当前温度或您如何混合了配料。
为了使我们的应用程序真正易于理解，我们必须能够实时观察代码。日志记录、跟踪、监测、错误跟踪和性能分析之类的工具可以告诉我们代码在运行时应用程序的实际行为。这与一开始编写干净的代码一样重要，因为虽然阅读静态代码对于理解应用程序至关重要，但我们也知道，它永远无法完全代表应用程序在生产环境中的实际行为。
这方面的一个典例就是配置。如果您的代码存在基于配置的大规模切换情形，那么仅仅阅读代码可以表明可能出现什么情况。想了解实际情况，您必须了解运行时在使用的配置。
还要记住，到头来目的是不仅限于观察系统，而是进入到我们真正了解系统的阶段。这意味着我们需要集成到开发环境中的工具、在所编写代码的上下文中检索数据的工具以及深入动态地查看代码在实际环境下如何运行的工具。
大多数公司还没有抵达成功彼岸。如果您具备了可观察性，已经领先于大多数公司。但是观察到问题后，仍需要进行额外的工作才能真正深入了解应用程序中发生的情况。生产级调试器就是一个典例，这种工具解决了可理解性问题;我预计在接下来几个月，这一类工具的讨论会越来越多。
原文标题：The Importance of Writing Clean Code，作者：Liran Haimovitch
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
