如何编写可信赖的代码

 

       软件, 逻辑之塔, 精微的艺术。

       遵循严格的代码规范, 学习好的编程模式,  避免常见的编程错误, 持续小步重构改进,  严格测试与必要文档, 理解所写的每一行代码, 正确使用 API, 代码 Review ,  追求更好的解决方案, 注重整体设计 。  

什么是好的代码

     作为一名合格的程序员, 需要满足的两个最基本要求:

        1.  能够编写值得信赖的程序和文档;
        2.  能够无障碍地与团队成员进行探讨交流。

     假设我们是一段代码的使用者, 对代码的要求会是怎样的?  

         代码有必要的文档, 详细说明了它的主要意图及设计思想;
         代码出色地完成了它所声称的工作, 对于不合法情况能够给出合理的返回结果或友好提示; 能够应对大数据量;
         代码稳固, 在异常情况下依然坚挺, 至少可以给出友好提示, 或降级运行;
         容易读懂、修改和扩展。

         通常情况下, 主要考虑以下质量属性: 正确性、性能、 健壮性、 可维护性。 
 
 

可信赖代码之道

     编写可信赖的代码, 需要采用多种方法和手段去逐步逼近。 以下是一些好的做法: 

     1.   确定一种严格的代码风格和规范, 严格遵行它。  
         
             良好的代码风格不会保证程序的正确性, 但能保证代码清爽易读,更容易找出错误;
   
 
     2.   掌握好的编程理念和模式, 尽可能使用习惯用法和推荐用法。
 
             a.   自顶向下, 意图导航;  
             b.   搭建原型, 逐步细化;
             c.   接口与实现分离解耦;
             d.   构造与使用分离解耦;
             e.   事件与处理器链分离解耦;
             f.     “一个事实”原则; “对修改关闭, 对扩展开放”原则; KISS 原则; 
             g.   充分利用已有成熟库和组件;
             h.   通过封装, 屏蔽低层复杂性, 使用容易理解的高层语义构建程序;
             i.    First Make it Right, Then Make it Good.
 
     推荐书籍:《 Effective Java 》, 《代码整洁之道》, 《Writing solid code》、 《编写可读代码的艺术》,《代码大全》, 《Unix / Linux 设计思想》,《敏捷技能修炼》, 《程序设计实践》(K&R) 。 
 

     3.  熟悉常见错误代码模式, 避免犯相同的错误。
 
       聪明的人从别人的错误中汲取教训。 《Code Quality: The Open Source Perspective》 这本书从代码层面深入讨论了各种编程错误。
 
       参阅: 《CR常见代码问题

       根据二八定律, 80% 的 BUG 是由 20% 的编程错误引起的, 因此, 熟悉这 20% 的编程错误并避免之, 就能避免 80% 的BUG 。此外, 有些 BUG 可能是由系统集成导致的, 属于更精微的层面, 另当别论。 充分利用编译器及静态代码分析工具检测代码。
 

      4.  持续小步重构改进,消除重复和代码坏味。

            a.   重复代码抽取为公共方法;
            b.   相似逻辑提炼微框架处理;
            c.   使用设计模式优化结构;
            d.   充分使用短小函数;
            e.   删除未用到的代码;   
    

      5.  设立严格的检验关卡, 仔细测试。

            a.   优先级: 关键部件 》 常用部件 》 不常用部件;
            b.   正常情况测试;
            c.   临界情况测试: 空/越界/一/二/;
            d.   等价类测试;
            e.   分支测试;
            f.    性能压力测试; 
 

     6.  深入理解实现原理和细节,准确理解和使用 API, 理解代码所做的事情。
        
            a.   完整理解 API 含义, 而不是一知半解的情况下调用;
            b.   检测 API 返回值并作出合理的措施;
​            c.   理解自己所编写的每一行代码, 它是如何与框架进行交互的;

      7.   代码讲解,有助于发现所犯的错误, 也能锻炼口头表达能力。
          
            a.   团队成员之间进行代码 Review;
            b.   给自己讲解所编写的代码;

      8.   思考更好的表达方式和方案, 追求更好的可维护性。

            a.   使用多线程并发处理 IO 调用, 而不是迭代;
            b.   使用异步调用改善响应流畅性;
            c.   使用 API 接口代替数据库查询;
            d.   对于简单方案的性能较低的实现方式, 思考更有效率的实现方式; 
            e.   对于代码中不太清晰的地方, 逐步替换为更清晰的实现;

      9.   阅读优秀开源项目代码,  潜移默化地汲取优秀的做法、思路和方案。

    10.   关注整体设计、细致编程、考虑周全。
 
       有些问题是由整体设计引入的, 比如整体的错误处理,  无法通过局部层面来解决。
         
       不当的架构设计会使代码修改和扩展变得困难, 迫使开发者编写大量临时方案去解决某个具体问题; 日积月累, 整个系统就会越来越腐烂, 越来越难以维护。 始终保持简洁有效的架构设计。         

       形成开发与测试的良性循环,建立高质量编程的一套方法和习惯(包括开发时间估算), 对每一个功能都能遵照这种方法和习惯。

       时间与质量的平衡。
 

后记参考

什么是不可信赖的代码 

        1.  没有文档;
        2.  不能(正确有效地)完成代码文档所声称的事情;
        3.  不能处理不合法情况;
        4.  无法应对大数据量的情况;
        5.  没有错误提示或不友好;
        6.  可能被恶意代码攻击;
        7.  难以读懂、理解和修改。
       

逼近高质量的基本方法

       这就有几个问题要思考一下, 可以根据这几个问题按图索骥, 一步步地逼近高质量编程。
        1.   这段​代码想要完成什么样的工作? 要求怎样的输入, 可以预期获得怎样的输出(输入-输出模型)?
        2.   什么是合法情况, 什么是不合法情况? 如何统一处理, 减少这种合法性检测的时间成本?
        3.   代码所要应对的数据量有多大? 是否可能存在时间或空间上的性能瓶颈? 如果有, 需要仔细设计好的结构和算法去解决;
        4.   代码所运行其中的环境如何(数据库操作/网络调用/文件读写)? 可能发生怎样的异常,导致什么错误? 如何进行异常处理?  
        5.   如何保证代码可读?  是否有可扩展性需求? 如果有, 需要在哪些方面提供灵活性? 
     
        基本方法:
        1.  编写文档, 描述所要完成的工作, 输入是什么, 输出是什么;  这是一个自我表达的过程, 有助于清晰思路;
        2.  编写有效的测试用例, 设立检验关卡。
        3.  编写代码, 持续小步重构、改进, 必要的时候同步更新文档,  通过测试用例;
        4.  代码Review.  添加新的测试用例或需求, 持续改善。
     
       以上采用的是“文档与测试导引” 的方法。既要写文档, 又要写测试, 这种方法看上去工作量大, 实际上反而可能是一种捷径。 实际上, 文档、测试、开发三者的本质都是表达, 彼此会是相辅相成的。 当然, 与“测试驱动论”或“文档驱动论”不同, 编写文档以及通过测试用例并不是最终目的, 只是一种检验途径。 还需要尽力去编写可读性良好的代码。  

 

posted @ 2013-11-20 19:33  琴水玉  阅读(547)  评论(1编辑  收藏  举报