从写代码到设计代码的艺术

前言

       只要你干过两三年编程，就有可能曾被某人的糟糕的代码绊倒过。如果你编程不止两三年，也有可能被这种代码拖过后腿。进度延缓的程度会很严重。有些团队在项目初期进展迅速，但有那么一两年的时间却慢如蜗行。对代码的每次修改都影响到其他两三处代码。修改无小事。每次添加或修改代码，都得对那堆扭纹柴了然于心，这样才能往上扔更多的扭纹柴。 这团乱麻越来越大，再也无法理清，最后束手无策。

      随着混乱的增加，团队生产力也持续下降，趋向于零。当生产力下降时，管理层就只有一件事可做了：增加更多人手到项目中，期望提升生产力一可是新人并不熟悉系统的设计。--《代码整洁之道》

      首先，需要谨记于心：只是让应用运转起来，和尽心保证代码质量是两个完全不同的事。一方面，你需要实现产品需求。但是另一方面，应该花点时间，确保函数功能简单、使用易读的变量和函数命名，避免函数的副作用等等。

命名

        不知道大家有没有发现，迭代过程中代码读写时间比例其实是10：1，而新开发一个项目，读写比例也会远大于1：1，代码的可读性会大大提升迭代效率

•  变量的名不要用key，v，e这种含糊的名称，命名应该做到见名知意，好的命名应该是简单明了，并且不会有歧义误导他人，可参考Spring类和变量命名，做到见名知意。

  

  
  

• 要做到全文可搜索，含糊的变量以及变量名中包含重复内容会导致搜索结果干扰结果过多，浪费ide提供给我们的强大功能

函数

短小！短小！短小！

函数的第一原则就是短小，第二原则也是短小

为什么要短小？

• 短小的函数易于理解可读性高。

• 短小的函数方复用能更好划分类职责，便于拆分保证高内聚。

函数多长合适呢？

        函数的长度尽量控制到一个评估能够容纳下整个函数

如何做到短小呢？

         要保证一个函数只做一件事，做好这件事。

如何判断函数是否只做了一件事呢

        需要判断函数是否能够拆分出一个新的函数，是否包含区段，什么是区段呢，以我们在线购票为例子，首先需要生成购票账单，查询相关数据，扣减库存，发送提示消息等一系列流程，假如所有操作都写在一个函数里，那这个函数就会很长，代码区段就是执行以上一个步骤所包含的操作。代码过长我们应该把区段抽象处来，用面向对象的思想将区段划分到不同的类及不同的函数中。

函数参数

        

• 参数的数量尽量保持在三个以下，想象一下如果一个函数的入参只有一个，你能很快的理解，如果有两个你需要思考下这两个参数分别是什么，如果有三个呢四个呢？

• 其实上面已经给过答案，当函数的参数有三个或这三个以上时，你就要考虑是不是要抽象一个类作为参数了。

•  慎用变长参数，如果变长参数只有一个那就相当于一个List参数，如果超过三个变量，变长参数可能会导致调用方法时参数过多难以理解，如下图

 Error.Java 依赖磁铁

         返回错误码通常暗示某处有个类或是枚举，定义了所有错误码。

  public enun Error {

         OK, 

         INVALID, 

         NO_SUCH, 

         LOCKED, 

         OUT_QF_RESOURCES;

  }

        这样的类就是一块依赖磁铁(dependency magnet)；其他许多类都得导入和使用它.当 Error枚举修改时,所有这些其他的类都需要重新编译和部署这对Error类造成了负面压力。程序员不愿增加新的错误代码，因为这样他们就得重新构建和部署所有东西。于是他们就复 用旧的错误码，而不添加新的。使用异常替代错误码，新异常就可以从异常类派生出来，无需重新编译或重新部署。

如何写出这样的函数

       写代码和写别的东西很像。在写论文或文章时，你先想什么就写什么，然后再打磨它。初稿也许粗的无序，你就斟酌推敲，直至达到你心目中的样子。

      我写函数时，一开始都冗长而复杂，有太多缩进和嵌套循环，有过长的参数列表。名称是随意取的，也会有重复的代码。不过我会配上一套单元测试，覆盖每行丑晒的代码。

      然后我打磨这些代码，分解函数、修改名称、消除重复。我缩短和重新安置方法。有时 我还拆散类。同时保持测试通过。

      最后，遵循本章列出的规则，我组装好这些函数。

      我并不从一开始就按照规则写函数，我想没人做得到。

       希望大家重视，当代码完成一个阶段之后，一定要在你对代码非常熟悉的时候审视一下这些代码，考虑一下以上的原则及优化方法，自己的代码是否适用。如果优化方法适用，并且违反以上原则的时候，大家真的需要及时整改。

       我相信大家有过这样的经历：过段时间，当这段代码发现问题或者日常迭代需要更改之前自己所写的代码时，不仅别人不好读懂，自己也需要花时间。其实代码事实上是用来读的。

switch语句

        switch语句天生就是为了做多件事情，这明显是违背了方法只做一件事的原则，解决的方案就是把switch语句放到抽象的底层，新建构建工厂类生产对象。

注释

为什么要写注释

        注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。

       迭代过程中注释存在的时间越久，就离其所描述的代码约远，越来越背离原来的意思，最终变为错误注释，会产生误导，造成的原因可能是开发人员没有维护注释。

        注释并不能美化糟糕的代码，有时间用注释解释混乱的代码，不如花时间优化下代码。对比一下

必要的注释

       当然有些注释是必要的注释，比如编写人创建时间等等。

注释掉的代码

        由于我们现在有优秀的代码版本管理工具，没有必要保留注释掉的代码。

边界

       在我们的代码结构中难免会需要调用第三方接口，我们需要尽量将第三方代码与我们的业务代码剥离开，保证与第三方代码的边界，避免混乱。

类

类变量顺序

       类应该从一组列表开始，顺序 公有静态变量、私有静态变量、私有实体变量

类应该短小

    类应该保持尽量的短小，不要冗杂过多的代码。

单一权责原则

          类应该只有一个权责（职责），修改它的理由应该只有一个。让软件运行和让软件整洁是两种截然不同的工作。

内聚

        类应该有少量的实体变量，类中的每个方法都应该操作一个或多个这种变量，方法操作的变量越多，则内聚性越高。

为了修改而组织

        我们来看下书中的例子下面是一组数据库操作类，如果新增方法，我们要做的就是修改原有类。

        改进后，我们得到了一组数据操作类，我们再拓展新的操作时，可以通过增加类的方式完成。在满足单一职责原则的同时也满足了设计模式中的开闭原则。