代码精进之路

开篇词

作为一个程序猿(媛), 我们大多数和别人交流的方式不是说话而是,用代码来表达我们所知所想及所感;每一行代码，都体现着程序员的修为，思考问题的深度，甚至是处理问题的习惯和态度。代码，是我们交流的语言和处世的名片。
越写代码就越能感受到好的代码对于一个编程人的重要性. 反过头来,看下自己以前写的代码, 我想大家和我的感受应该是大同小异的,就如大家说的,写代码的时候,我和上帝知道代码的意思, 而现在, 知道这些代码的目的的恐怕只有上帝了。下面我们就来学习一下本文的主题，也让上帝不再那么孤单。

代码规范篇

1、条件运算符的使用

学习这篇文章之前，我非常喜欢使用条件运算符。因为条件运算符的这种压缩方式，使代码看起来简短、整洁、干净。 而且，如果能把代码以最少的行数、最简短的方式表达出来，心里也颇有成就感。
后来，我的一位同事告诉我，对于我使用的条件运算符的部分代码，他要仔细分析才知道这一小行代码想要表达的逻辑，甚至有时候还要翻翻书、查查操作符的优先级和运算顺序，拿笔画一画逻辑关系，才能搞清楚这一小行代码有没有疏漏。更为恐怖的是，时间久了后，我自己也不能一眼看出这一行代码是否合理了。
个人建议：不使用嵌套的条件运算符，单个简单一眼可以看出的可以用。
好的代码应该是：

1. 容易理解
2. 没有明显的安全问题
3. 能够满足最关键的需求
4. 有充分的注释
5. 使用规范的命名
6. 经过充分的测试
   …

坏的代码包括：
7. 难以阅读的代码
8. 浪费大量计算机资源的代码
9. 代码风格混乱的代码
10. 复杂、不直观的代码
11. 没有经过适当测试的代码
…

2、阻挡错误的五道关卡

开始之前，我先给你讲个曾经发生过的真实案例。2014 年 2 月，苹果公司的 iOS 和 OS X 操作系统爆出严重的安全漏洞，聪明的黑客们可以利用这一漏洞，伪装成可信网站或者服务，来拦截用户数据。而造成这一漏洞的原因，也让业界专家大跌眼镜。

    if ((error = doSomething()) != 0)
        goto fail;         
        goto fail;    
    if ((error= doMore()) != 0)        
        goto fail;
fail:    
    return error;

没有人是完美的，人人都会犯错误。这应该是一个共识。这里面既有技术层面的因素，也有人类的行为模式的因素，也有现实环境的影响。我们在此不讨论人类进化和心智模式这样的严肃研究成果。但是，有两三个有意思的话题，大家可以一起看看。

1. 第一个比较普遍的观点是好的程序员不会写坏的代码，要不然，就是他还不足够优秀。我尊重这个观点背后代表的美好愿望，但是这个观点本身我很难认同。它一定程度上忽视了人类犯错误的复杂性，和影响因素的多样性
2. 第二个更加普遍的观点是同样的错误不能犯第二次。作为一名程序员，我同样尊重这个观点背后代表的美好期望。但是，我想给这个观点加一点点限制。这个观点应该是我们对自身的期望和要求；对于他人，我们可以更宽容；对于一个团队，我们首先要思考如何提供一种机制，以减少此类错误的发生。 如果强制要求他人错不过三，现实中，我们虽然发泄了怨气，但是往往错失了工作机制提升的机会。
3. 第三个深入人心的观点是一个人犯了错误并不可怕，怕的是不承认错误。同样的，我理解这个观点背后代表的美好诉求。这是一个深入人心的观点，具有深厚的群众基础，我万万不敢造次。在软件工程领域，我想，在犯错这件事情上，我们还是要再多一点对自己的谅解，以及对他人的宽容。错误并不可怕，你不必为此深深自责，更不应该责备他人。要不然，一旦陷入自责和指责的漩涡，很多有建设意义的事情，我们可能没有意识去做；或者即使意识到了，也没法做，做不好。

那么问题来了，人人都会犯错误，还容易重复犯，还又不能批评，这怎么能编写出优秀的程序呢？这个时候我们就需要该部分提及的五个关卡了

第一道关：程序员本身

程序员自我修养的提升是个永不过时的课题。从失败中学习、积累、提高，是我们成长的必修课。这也是我们一直在努力做的事情。
魔鬼藏于细节，很多时候，都是由于我们的代码风格造成的，但是我们依旧会有没注意到的问题，所以也就有了第二道工序：IDE

第二道关：IDE

在现如今，大多数编码问题都可以通过IDE直接反馈给我们，对于IDE给我们的警告，一定要消除，就算不消除，也一定要搞清楚警告产生的原因，并确认不消除它，对于我们程序的运行是不是有影响。

第三道关：回归测试

一般情况下，无论是开发人员，还是测试人员，都要写很多测试代码，来测试软件是否达到预期的要求。这些测试代码的一个关键用途就是做回归测试。只要有一个代码的改动，我们可以用回归测试来检查这个变动有没有对以前的代码造成问题。
软件测试没有办法覆盖所有的使用场景。但是，我们千万要覆盖关键逻辑和负面清单。一个没有良好回归测试的软件，很难保证代码变更的质量；也会使得代码变更充满不确定性，从而大幅地提高代码维护的成本。