如何编写可信赖的代码

 

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

       遵循严格的代码规范， 学习好的编程模式，  避免常见的编程错误， 持续小步重构改进，  严格测试与必要文档，  理解所写的每一行代码， 正确使用 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.  添加新的测试用例或需求， 持续改善。

     

       以上采用的是“文档与测试导引” 的方法。既要写文档， 又要写测试， 这种方法看上去工做量大， 实际上反而多是一种捷径。 实际上， 文档、测试、开发三者的本质都是表达， 彼此会是相辅相成的。 固然， 与“测试驱动论”或“文档驱动论”不一样， 编写文档以及经过测试用例并非最终目的， 只是一种检验途径。 还须要尽力去编写可读性良好的代码。