很多人都会忽略但又极其重要的一点——代码质量

工作了的人都知道，每个公司都有自己的代码规范，尤其是bat这样的大公司更是严格要求代码规范的，所以编写出高质量的代码非常重要，最直接的影响就是决定了你的薪资。

下面是对于编写高质量代码的一点思考。

信息隐藏原则

信息隐藏是面向对象设计的一个原则，是对封装和模块化的一个更高维度的概括。从Java的整个访问限制设计就体现了信息隐藏的原则，各种访问修饰符：

public,protect,private

，在类设计的时候，我们就要决定什么暴露给外部，什么隐藏起来。

举一个例子下面的代码表示一个有自增ID的

Person

类。

上面的类设计有什么问题呢？它违反了信息隐藏的原则，直接将ID分配的方式暴露了，这会给后面的维护带来很多问题：当你想给id的范围做出限制的时候怎么办？当你在所有代码中使用

++G_MAX_ID

分配ID时突然需要修改ID分配的算法怎么办？是不是需要去改所有

++G_MAX_ID

出现的地方？更好的设计是将ID的分配算法隐藏起来。

咋一看只是将

++G_MAX_ID

写到一个方法里面而已，但是它隐藏了ID分配的算法，让调用者不需要关心里面的实现，同时控制了变化，不管ID分配算法怎么变，都不会影响其他的代码。调用者了解的信息越多，受到的影响就越大，信息隐藏可以降低复杂度，控制变化的范围。

上面的例子只是信息隐藏的一个简单应用，下面我们来举几个其他的应用例子：

为什么不推荐使用魔法值（即未经定义的常量）？：这个明显违反了信息隐藏的原则，当你将字面量直接写在代码里面时，就将信息直接暴露了，后面需要修改的时候，一旦少改了某个地方的字面量，bug就出现了。

循环依赖（即A调用B，B调用A的情况）：类或方法之间的循环依赖会破坏信息隐藏，一个很直接的影响就是在测试的时候，A，B都需要同时准备好才能进行测试，而无法mock任意一方。

使用全局变量：这个就不用说了，所有人都可以访问你的时候信息就暴露无疑了，全局变量能不用就不用。

考虑性能损失：有时候我们为了一些性能上的考虑就破坏信息隐藏原则，将一些变量全局化，这样性能提高得不多，维护成本却上升不少，完全是得不偿失。

最后总结一下信息隐藏的好处：

隐藏信息即隐藏了复杂度，降低了编程的负担。

隐藏信息即隐藏了底层变化，以便于在局部控制变化。

一些不太常见的编程技巧

函数(function)与过程(procedure)的选择

我们先来看看函数与过程区别：

Function：有返回值的方法

Procedure：没有返回值的方法

平时我们编程其实没有太区别函数与过程，什么时候用函数，什么时候用过程其实没有过多的考虑，感觉都可以用。一个选择的规则就是当你的方法的目的是想返回跟你方法名称相符的值的时候用函数，否则用过程

举个例子，我看过很多

XXProcessor

接口里面的方法都是

XX process()

，严格来讲，这样的命名是不符合上面的规则的，

process

是一个没有含义的命名，但是却有返回值，如果没有返回值那它的命名才是合理的。

当然了，上面的规则仅供参考，世事无绝对，具体情况具体分析，当你不清楚用函数还是用过程的时候，可以参考这个规则。

使用boolean值来给程序做注释

相信大家看到一个if语句有很多条件的时候都会特别头痛，因为很难理解。例如下面的例子：

但如果换成下面的写法，用boolean值的名字来给if语句注释，看起来就很好理解了。

下面就如何提高代码质量给出几个建议，从现在做起，很重要！！！

1. 打好基础

写出高质量代码，并不是搭建空中楼阁，需要有一定的基础，这里我重点强调与代码质量密切相关的几点：

掌握好开发语言，比如做Android就必须对Java足够熟悉，《Effective Java》一书就是教授大家如何更好得掌握Java, 写出高质量Java代码。

熟悉开发平台, 不同的开发平台，有不同的API, 有不同的工作原理，同样是Java代码，在PC上写与Android上写很多地方不一样，要去熟悉Android编程的一些特性，iOS编程的一些特性，了解清楚这些，才能写出更加地道的代码，充分发挥各自平台的优势。

基础的数据结构与算法，掌握好这些在解决一些特定问题时，可以以更加优雅有效的方式处理。

基础的设计原则，无需完全掌握23种经典设计模式，只需要了解一些常用的设计原则即可，甚至你也可以只了解什么是低耦合，并在你的代码中坚持实践，也能写出很不错的代码。

2. 代码标准

代码标准在团队合作中尤为重要，谁也不希望一个项目中代码风格各异，看得让人糟心，即便是个人开发者，现在也需要跟各种开源项目打交道。标准怎么定是一个老生常谈的话题，我个人职业生涯中经历过很多次的代码标准讨论会议，C++, C#, Java等等，大家有时会坚持自己的习惯不肯退让。可现如今时代不一样了，Google等大厂已经为我们制定好了各种标准，不用争了，就用这些业界标准吧。

3. 想好再写

除非你很清楚你要怎么做，否则我不建议边做边想。

你真的搞清楚你要解决的问题是什么了吗？你的方案是否能有效？有没有更优雅简单的方案？准备怎么设计它，必要的情况下，需要有设计文档，复杂一些的设计需要有同行评审，写代码其实是很简单的事情，前提是你得先想清楚。

4. 代码重构

重构对于代码质量的重要性不言而喻，反正我是很难一次把代码写得让自己满意、无可挑剔，《重构》这本书作为业内经典也理应人人必读，也有其他类似的教授重构技巧的书，有些也非常不错，遗憾的是我发现很多工作多年的同学甚至都没有了解过重构的概念。

5. 代码审查

我曾经听过一些较高级别的技术分享，竟然还不时听到一些呼吁大家要做代码审查的主题，我以为在这个级别的技术会议上，不应再讨论代码审查有什么好，为什么要做代码审查之类的问题。同时我接触过相当多所谓国内一线互联网公司，竟有许多是不做代码审查的，这一度让我颇为意外。

这里也不想多谈如何做好代码审查，只是就代码质量这点，不客气地说：没有过代码审查经历的同学，往往很难写出高质量的代码，尤其是在各种追求速度的糙快猛创业公司。

6. 静态检查

很多代码上的问题，都可以通过一些工具来找到，某些场景下，它比人要靠谱得多，至少不会出现某些细节上的遗漏，同时也能有效帮助大家减少代码审查的工作量。

Android开发中有Lint, Find bugs, PMD等优秀静态检查工具可用，通过改进这些工具找出的问题，就能对语法的细节，规范，编程的技巧有更多直观了解。

建议最好与持续集成(CI)，代码审查环境配套使用， 每次提交的代码都能自动验证是否通过了工具的代码检查，通过才允许提交。

7. 充分自测

有一种说法：程序员最害怕的是他自己写的代码，尤其是准备在众人面前show自己的工作成果时，因此在写完代码后，需要至少跑一遍基本的场景，一些简单的异常流。在把你的工作成果提交给测试或用户前，充分自测是基本的职业素养，不要总想着让测试帮你找问题，随便用几下就Crash的东西，你好意思拿给别人吗？

8. 善用开源

并非开源的东西，质量就高，但至少关注度较高，使用人数较多，口碑较好的开源项目，质量是有一定保证的，这其中的道理很简单。即便存在一些问题，也可以通过提交反馈，不断改进。最重要的是，你自己花时间造的轮子，需要很多精力维护，而充分利用开源项目，能帮助你节省很多时间，把精力专注在最需要你关心的问题上。

从另一个方面来说，开源项目中的一些知名项目，往往是领域内的翘楚所写，学习这些高手的代码，能让你了解到好的代码应该是怎样的，培养出更灵敏的嗅觉，识别代码中的各种味道。