代码编写小常识
节选自 <走出软件作坊> , 其中有一部分是我结合了目前自己的感受而写.
代码
1. 代码风格统一,从命名含义,到大小写,到缩进,尽量做到每个人的源代码文件风格一致.
许多程序员,光自己的代码就有好几种风格,有时心情好,有时心情不好,有时头
脑清醒,有时没有休息好,有时敷衍,有时画蛇添足,有时急躁,从代码就能看出来.而我的
代码就像稳定运行每天如一日的机器,好似每个源代码都是在同一天敲的.这就叫发挥稳
定.这几天要开奥运会了,运动员天天重复练同一个动作,把每个环节都练的精益求精,其
目的就是为了在大赛紧张的压力下也能发挥稳定.人在压力下,非常容易发挥失常.如果
人老处于这种压力下训练,那么大赛就像平常一样了.
2. 在业务逻辑复杂的方法或类,需要加入必要的注释,描述主要业务逻辑和容易出错的地方,
每个类要标注 初始作者,创建日期.
3. 保证简单,直观的反应主业务流程走向,避免大的流水代码.可以将一个比较大的业务逻辑
拆分为若干小的逻辑函数.既方便理解也便于测试.
我的代码居然能看出业务流程.函数数量均衡,不像他的代码函数太多,跟踪跳转的很累,也
乱了头绪.函数长度也正好在可理解阅读范围内.而且有一个流程控制函数,把流程处理环节
串了起来.细深入跟踪某一环节,又发现了更细的流程.每个函数都看起来简单,但整体来看,
却实现了复杂的功能.他问我是怎么做到的？我说,我的心中只有业务,业务和代码,我认为只
是英语和汉语的区别,表达的是同一个思路.而在你心中,业务是DOC上的文字,代码是你的技术
表现,你老需要把业务和代码映射拧在一起,我则不需要.业务流程如何,我的代码流程就是如何.
4. 一定要对主要的业务流程代码进行单元测试,在写代码的时候也要考虑是否方便进行单元测试,
这样可以直接提高代码质量,并方便后续修改人员进行 修改 <-> 测试 的工作.
5. 交叉代码复查工作.小组内开发人员之间发现有人的代码出现坏迹象(要提出坏的理由和解决建议)
,这就需要他整改重构自己的代码.
否则,定了规范,光喊口号让大家遵守规范又不检查又不惩罚,谁爱遵守规范?
6. 修改遗留代码,对于原有的大流水代码或有明显错误的地方要勇于进行重构,但一定要小心,谨慎并
做足充分的测试,重构的结果一定要符合 上述的 1 - 4.
7. 对日常的一些比较有功用性的代码进行积累,避免不必要的重发开发.
8. 如果需要应用新的框架和技术,要对此工具或技术进行比较多的了解,要满足 简单 高效的要求,
并对相关开发人员进行简单培训.