看了很多刚参与开发工作时间不久的同事的代码之后，心情总是很沉重，大家由于缺乏工程化的经验，不知道如何写好代码，更加不知道如何站在软件工程的角度来开发，从而大幅降低开发成本，特别是产品类开发，可以降低多轮迭代以及黑盒测试、后期维护的成本，而且可以直观地降低大家的加班时间，正确的工程方法+需求的准确把握=成功的软件工程。
这里还是想借此机会再重新谈谈软件与程序的区别，所谓程序仅仅是在计算机上可以被编译运行的一段代码而已，程序的设计可以是学术化的，譬如为了验证某些算法，某些学术目标，而软件却是将用户的需求进行完整理解之后，依次按照设计、开发、单元测试、集成测试后带有一定的框架定义以及品质保证的可执行的代码、文档集合，一语中的地说，软件是经过工程化管理出产后的程序与文档集合，二者的差距就是在如下两个方面：
- 软件的需求目标非常鲜明；
- 软件的品质是经过工程化控制的，质量达标的；
很多刚参与工作不久的同事都普遍地认软件开发=程序开发，这个认识是非常有害的，最直观的反应是在时间估算上，往往很多时候估算2周的工作，最后2个月都没做完，明显是对于软件工程的认识上存在非常大的误区。
本篇将重点讲述一下代码开发方面的程序REVIEW观点集合，有关软件工程的论述在后续的文章中再跟大家分享。
代码REVIEW观点集合：
“形”
1.曲线外形美：代码曲线的外形要比较漂亮，好的代码外形表现为比较柔和的钝三角形，而糟糕的代码由于书写方式的不好而表现为外形跨度很大的锐三角形；
好的代码外形：(过度比较平缓)
----
---------
-------------
----------
-------
不好的代码外形：(杂乱无型)
-
-------------------------------------------------------------
-------
--
------------------------------------------------
2.函数型参，优秀的代码风格在函数的型参上拥有严格的控制观点，一般建议函数的参数控制在6个以内，超过6个的参数一般建议考虑通过结构体、指针或者引用对象等多种方式进行传递，而且一般来讲，当单个函数的参数涉及的参数数量超过6个时，你需要考虑是否你的当前函数的处理逻辑设计是否出现了重大问题，这一点也是检验你设计思路的一个指标之一。
3.代码长度限制，一般而言，单个函数的代码长度建议控制在50行以内，最长建议不超过100行，设定这个指标的主要意义其实是为了人类的思维逻辑的分层处理，避免在思维设计时出现重大失误带来实现的诸多问题，对于这个指标，很多初始参与编程开发的同事总是触犯这个规矩，到最后进行代码调整修改排错时我们经常发现这些同事在找某个问题时满头大汗，找到某个函数后修改的时候也是经常出现修改父函数的同时又去修改子函数，导致修复一个BUG引发其他的BUG，可能还会带来严重的DEGRADE问题，这些都是因为违背了一些好的编程开发实践所导致的。
4.行书写长度限制，设定这个指标的主要目的其实是为了控制在目前主流的屏幕宽带范围内不用水平滚动即可实现代码阅读，过去旧的标准是建议控制在80个字符每行，新的推荐规范建议在120个字符每行。
5.命名规则，需要对变量名、函数名、类名、包名、文件名等实施统一的命名管理规范，进一步增强代码的可读性，确保在团队开发的时候代码方便交流。很多开发经验不足的开发人员总认为这个是个很大的约束，其实如果大家做过大项目的维护以及软件逆向工程开发人员都认为这个确实非常重要，可读性强的代码要远远超过去阅读那往往跟代码看似相关而实际上总是跟不上代码更新速度的厚厚的文档集。
6.代码注释，优秀的代码一定是含有非常好的代码注释，由于代码注释在很多的代码编辑器里面都呈现绿色，因此将注释率称为“绿化率”，推荐的绿化率为20-25%左右（行数比率），而且建议整体上分布均衡一点，确保代码阅读在注释的帮助下可以很容易完成，这点跟上面的命名规则一起可以决定增强代码的可读性。
设定“形”的观点主要是为了便于代码阅读，便于其他开发人员为你的代码做设计REVIEW，便于代码沟通与交流，优秀的代码除了执行效率高，可读性强，可测试性好也是一个非常重要的指标，这些都最终直接决定着整体代码的交付质量。
“神”
1.设计观点：重点是高内聚、低耦合，其整体指导思路是模块内部的实现是高度内聚，模块之间的接口交互尽可能少，这样在未来当模块接口发生变化时相关的修改调整工作量不至于再夸张，不过一般还是建议采用兼容性设计来解决新旧代码的迁移问题，这样对于不同模块之前因设计升级而带来的工作量相对较少，这种设计思路对于操作系统级别的软件设计尤其显得重要，大家看看Windows的兼容性设计历程就不难看出这种设计思路的影子，在Windows95的时候大量兼容MS-DOS的设计、Windows98兼容Windows95的设计以及以后的版本兼容前面至少3个版本的Windows的各种应用的运行。
2.算法：优秀的算法可以直接决定问题解决复杂问题的思路的清晰度，大大降低代码编码的工作量，并且能够极大地提升软件的内在技术的含金量，有些极端案例，算法还是决定这个软件生死的决定性因素。
3.代码逻辑分支处理：优秀的逻辑分支其条件以及循环嵌套逻辑最好不要突破三层的限制（受限于常人的脑力思维制限），现代程序的直接跳转逻辑是基本不被允许的，分支逻辑控制在8个以内，对于超出上述标准的部分建议采用子函数分级来实现，这样可以将不同的逻辑进行合理的切块更加方便其他人的理解。
4.异常处理方法：通常对于软件的除界面层以外的各层的异常处理的规则是大多数时候将异常向上抛送，个别时候需要将异常捕获后直接输出到日志或者忽略的情况，而对于UI这层异常处理通常都是提示用户相关的数据处理操作失败，并且将错误的详细信息通过用户易于接受的某种表述方式通知到开发人员以方便开发人员来修复这个缺陷
譬如：对于Windows而言，当底层处理碰到异常后大家都会看到熟悉的BSOD画面，并且通过CPU的陷进门机制来捕获这些错误给出错误代码以及逻辑地址，并且可以DUMP出当时存在于内存中的数据信息；
对于SDK级别的应用开发，特别在远程支持的时候，更多地建议系统开发出x-Ray功能，对产生错误的场景进行全面扫描后完整地保留错误发生时段的全部环境信息方便开发人员进行远端分析提供必要的技术支持；
而对于Application级别的开发，一般都是将错误界面表现（Exception描述详细信息以及UI截屏）以及系统日志来进行全面地异常定位，方便后续的开发人员进行技术支持；
5.程序处理逻辑：简单直接是程序处理逻辑考虑与设计时应该考虑的主流，现代的软件开发特别是应用级别的开发更加突出这个中心思路，而对于框架级别的开发人员更多地是需要从开源代码与社区中吸取设计与实现精化，在各种各样控制流转模型以及设计模式之间寻求最合适的实现方案，从而确保代码在简单、直接、明了的思路基础之上更增加了整体的可扩展性；
6.品质保证观点以及实施，所有的代码都必须通过严格的质量保证流程才能确保最后出来的是合格品，品质保证的观点必须根植于团队每个人的脑海中，在这点上开发人员往往存在以下几种错误思路：
a.品质保证是项目管理人员以及QA应该做的事情，跟自己无关； 这种思路的错误之处在于过于片面地圈定了品质管理的人员范围，正如同制造行业中推行全面质量管理TQM一样，软件开发的品质保证也绝对不是少数几个人的事情，而是整个团队对全生命周期的把握与管控。
b.品质保证仅仅是代码质量的保证； 这种思路也是非常片面，而且这种思路在开发人员尤其是工作时间不长的开发人员队伍当中存在的相当严重，过于忽略了在需求获取、系统设计特别是人机交互界面设计方面的优越经验。
c.品质保证仅仅是制造段(编码+测试)的事情，跟其他阶段无关；根据笔者所在企业对过去数百个不同内容项目的量化数据模型分析，我们发现软件最终的交付满意度的关联因子主要是需求确认而引起，跟代码制造段的关联度并不高，从而从另一个侧面说明了品质是跟随需求走的，品质管控的重心是需求为主、代码开发质量管控为辅的全面质量治理模型。
设定“神”的观点主要是为了提高代码的内在逻辑质量，无论从设计、编写实现的角度来看整体质量确实是以“神”为主、以“形”为辅的开发过程，另外从笔者的经验来看，之前大家推崇的开发管理模型中比较强调瀑布管理产品型管理模型，因此整体的质量上管控相对比较顺利与容易，而最近多年的大量项目经验告诉笔者，即便是产品型开发，为了适应快速开发的市场需求，开发团队越来越推崇基于敏捷开发管理模型，并且迭代的周期也一般控制在2-4周左右，提出了“拥抱变化”的新理念，从而将客户的满意度提升到一个新的高度。
笔者在多年前进行一个知名的SAN存储产品开发时，曾经经历过一个开发配2-3个测试来进行质量保证（全部是黑盒级别的集成测试），可即便是这样高的代价付出，最后整体的产品质量还是不高，在客户处安装运行时间长以后总是有各种各样的疑难问题产生，在调试、测试以及做BUG FIX的时候总是觉得力不从心或者是有力使不上，正是当年的产品开发痛苦的质量管理经历迫使笔者在后续的多年里从软件工程的全域视角来审视工程的质量，同样在对日外包的开发中我们遇到另外一个比较相反的CASE，当时我们承担了一个很CRITICAL的通讯组件开发，为了确保整个项目的质量，按照软件工程的理论，从需求理解、设计、代码REVIEW、单体白盒、集成黑盒等不同的视角站在工程的角度来进行质量保证，却惊奇地发现最后在客户的环境下运行了6个月仅仅发现了一个很小的BUG，更为奇妙的是，在软件工程的质量控制模型驱动下，我们从过去单纯地看重代码开发的视角放在整个软件工程的生命周期的各个环节的控制把握，特别是将需求理解、系统设计等几个源头环节投入了更多的力量以及重视，从而将软件工程质量的控制跟客户的满意度控制可以达到一个新的结合高度，软件工程管理的迷人之处就在于能够将普通的开发测试人员团队在一种统一的思路指引下能够制造出优秀的规模庞大的软件，避免了软件仅仅是由优秀人才才能够生产的圈子，而其将过去的个人英雄式的手工作坊生产变成大团队的工厂生产模式，真正地实现了软件的产业化。