代码编写小常识

节选自  <走出软件作坊> , 其中有一部分是我结合了目前自己的感受而写.
 
 
 
代码

 1. 代码风格统一,从命名含义,到大小写,到缩进,尽量做到每个人的源代码文件风格一致.
 
    许多程序员,光自己的代码就有好几种风格,有时心情好,有时心情不好,有时头
    脑清醒,有时没有休息好,有时敷衍,有时画蛇添足,有时急躁,从代码就能看出来.而我的
    代码就像稳定运行每天如一日的机器,好似每个源代码都是在同一天敲的.这就叫发挥稳
    定.这几天要开奥运会了,运动员天天重复练同一个动作,把每个环节都练的精益求精,其
    目的就是为了在大赛紧张的压力下也能发挥稳定.人在压力下,非常容易发挥失常.如果
    人老处于这种压力下训练,那么大赛就像平常一样了.

 

 2. 在业务逻辑复杂的方法或类,需要加入必要的注释,描述主要业务逻辑和容易出错的地方,
     每个类要标注 初始作者,创建日期.
 
 3. 保证简单,直观的反应主业务流程走向,避免大的流水代码.可以将一个比较大的业务逻辑
   拆分为若干小的逻辑函数.既方便理解也便于测试.

   我的代码居然能看出业务流程.函数数量均衡,不像他的代码函数太多,跟踪跳转的很累,也
   乱了头绪.函数长度也正好在可理解阅读范围内.而且有一个流程控制函数,把流程处理环节
   串了起来.细深入跟踪某一环节,又发现了更细的流程.每个函数都看起来简单,但整体来看,
   却实现了复杂的功能.他问我是怎么做到的？我说,我的心中只有业务,业务和代码,我认为只
   是英语和汉语的区别,表达的是同一个思路.而在你心中,业务是DOC上的文字,代码是你的技术
   表现,你老需要把业务和代码映射拧在一起,我则不需要.业务流程如何,我的代码流程就是如何. 

 

 4. 一定要对主要的业务流程代码进行单元测试,在写代码的时候也要考虑是否方便进行单元测试,
   这样可以直接提高代码质量,并方便后续修改人员进行 修改 <-> 测试 的工作.
   
 5. 交叉代码复查工作.小组内开发人员之间发现有人的代码出现坏迹象(要提出坏的理由和解决建议)
    ,这就需要他整改重构自己的代码.
   
   否则,定了规范,光喊口号让大家遵守规范又不检查又不惩罚,谁爱遵守规范?
   
 6. 修改遗留代码,对于原有的大流水代码或有明显错误的地方要勇于进行重构,但一定要小心,谨慎并
   做足充分的测试,重构的结果一定要符合 上述的 1 - 4.
 
 7. 对日常的一些比较有功用性的代码进行积累,避免不必要的重发开发.
 
 8. 如果需要应用新的框架和技术,要对此工具或技术进行比较多的了解,要满足 简单 高效的要求,
    并对相关开发人员进行简单培训.