第五章 编写优雅代码.pdfVIP

编写优雅代码 原⽂出处：http://weibo .com/p/ 100 1643877361430 185536 作者：秦迪，@蛋疼的AXB 课程⼤纲 什么是好代码 如何编写可读的代码 如何编写可发布的代码 如何编写可维护的代码 如何做出优 的设计 如何规划合理的架构 如何处理遗留代码 总结 什么是好代码 对于代码质量的定义需要于从两个维度分析：主观的，被⼈类理解的部分；还有客观 的，在计算机⾥运⾏的状况。 我把代码质量分为五个层次，依次为： 完成功能的代码 ⾼性能的代码 易读的代码 可测试的代码 可扩展的代码 如何编写可读的代码 在很多跟代码质量有关的书⾥都强调了⼀个观点：程序⾸先是给⼈看的，其次才是能 被机器执⾏。 逐字翻译 在评价⼀段代码能不能让⼈看懂的时候，可以⾃⼰把这段代码逐字翻译成中⽂，试着 组成句⼦，之后把中⽂句⼦读给另⼀个⼈没有看过这段代码的⼈听，如果另⼀个⼈能 听懂，那么这段代码的可读性基本就合格了。 ⽽实际阅读代码时，读者也会⼀个词⼀个词的阅读，推断这句话的意思，如果仅靠句 ⼦⽆法理解，那么就需要联系上下⽂理解这句代码，如果简单的联系上下⽂也理解不 了，可能还要掌握更多其它部分的细节来帮助推断。⼤部分情况下，理解⼀句代码在 做什么需要联系的上下⽂越多，意味着代码的质量越差。 逐字翻译的好处是能让作者能轻易的发现那些只有⾃⼰知道的、没有体现在代码⾥的 假设和可读性陷阱。⽆法从字⾯意义上翻译出原本意思的代码⼤多都是烂代码，⽐ 如“ms代表messageSer ice“ ，或者“c()是发消息“ ，或者“tmp代表当前的⽂件” 。 遵循约定 约定包括代码和⽂档如何组织，注释如何编写，编码风格的约定等等，这对于代码未 来的维护很重要。 ⼤家刚开始⼯作时，⼀般需要与部门的约定保持⼀致，包括⼀些强制的规定，如代码 的格式化设置⽂件；或者⼀些⾮强制的约定，如⼯程的命名等。 从更⼤的范围考虑，整个⾏业的约定和规则也在不断的更新。所以在⼯作中也要对⾏ 业动向和开源项⽬保持关注，如果发现部门中哪⼀项约定已经过时了，那么可以随时 提出来，由平台的架构师⼩组re iew之后推进平台更新这些规则。 ⽂档 注释 对于⽂档的标准很简单，能找到、能读懂就可以了，⼀般⼀个⼯程⾄少要包含以下⼏ 类⽂档： 1. 对于项⽬的介绍，包括项⽬功能、作者、⽬录结构等，读者应该能3分钟内⼤致 理解这个⼯程是做什么的。 2. 针对新⼈的QuickStart ，读者按照⽂档说明应该能在1⼩时内完成代码构建和简 单使⽤。 3. 针对使⽤者的详细说明⽂档，⽐如接⼜定义、参数含义、设计等，读者能通过 ⽂档了解这些功能 （或接⼜）的使⽤⽅法。 有⼀部分注释实际是⽂档，⽐如j a adoc 。这样能把源码和注释放在⼀起，对于读者更 清晰，也能简化不少⽂档的维护的⼯作。 还有⼀类注释并不作为⽂档的⼀部分，⽐如函数内部的注释，这类注释的职责是说明 ⼀些代码本⾝⽆法表达的作者在编码时的思考，⽐如“为什么这⾥没有做XX” ，或 者“这⾥要注意XX 问题” 。 ⼀般来说函数内部注释的数量应该不会有很多，也不会完全没有，⼀般滚动⼏屏幕看 到⼀两处左右⽐较正常。过多的话可能意味着代码本⾝的可读性有问题，⽽如果⼀点 都没有可能意味着有些隐藏的逻辑没有说明，需要考虑适当的增加⼀点注释了。 其次也需要考虑注释的质量：在代码可读性合格的基础上，注释应该提供⽐代码更多 的信息。⽂档和注释并不是越多越好，它们可能会导致维护成本增加。 如何编写可发布的代码 刚开始接触⾼并发线上系统的新同学经常容易出现⼀个问题：写的代码在发布之后才 发现很多考虑不到的地⽅，⽐如说测试的时候没问题，项⽬发布之后发现有很多意料 之外的状况；或者出了问题之后不知道从哪下⼿排查，等等。 这⾥介绍⼀下从代码编写完成到发布前需要注意的⼀些地⽅。 处理异常 新⼿程序员普遍没有处理异常的意识，但代码的实际运⾏环境中充满了异常：服务器 会死机，⽹络会超时，⽤户会胡乱操作，不怀好意的⼈会恶意攻击你的系统。 对⼀段代码异常处理能⼒的第⼀印象应该来⾃于单元测试的覆盖率。⼤部分异常难以 在开发或者测试环境⾥复现，依靠测试团队也很难在集