先考虑清楚业务逻辑再写代码

业务逻辑与代码

代码只不过是业务逻辑的一种展现形式，所以写代码前应该先思考清楚业务逻辑。

Review 代码

在 Review 代码发现代码逻辑很混乱的时候，很多时候都是逻辑没有梳理清楚。逻辑混乱，自然代码也混乱。梳理清楚业务逻辑，就为代码打下了良好的基础。业务逻辑到代码的映射依然有可能出问题，下面用一个抽象的业务逻辑逻辑来举例说明这个过程。

业务表述

我们要做完成一件事情 doSomething。完成这件事情需要先做 A，再做 B。A 过程要先执行 a1,然后执行 a2,然后执行 a3。B 过程需要执行 b1，然后 b2。事情最终完成。

虽然本例是抽象的，现实世界的任何事情或业务都可以用类似的树形结构来表述，故本例是通用的。

正确的代码实现

能接受的几种代码写法，正确的代码块+合理注释

void doSomething(){    //A    a1逻辑伪代码.....;    a2逻辑伪代码.....;    a3逻辑伪代码.....;
    //B    b1逻辑伪代码;    b2逻辑伪代码;    b3逻辑伪代码;}

或者更优秀些，对代码块进行抽取小方法，每个方法抽象对等，符合业务描述

void doSomething(){    doA();    doB();}
void doA(){    a1逻辑伪代码.....;    a2逻辑伪代码.....;    a3逻辑伪代码.....;}void doB(){    b1逻辑伪代码;    b2逻辑伪代码;}

当然你也可以继续对 a1,a2,b1,b2 抽象方法，以上三种写法都可以接受，小方法抽取与否并无太大差别，可以参考《小方法抽取与母语的关系》

第一种问题：不对等

第一种常见的问题不太严重，只对部分逻辑进行了抽取，造成方法中执行不对等；改进办法抽取方法，或通过空行分割加以注释，就可接受。

void doSomething(){    a1逻辑伪代码.....;    a2逻辑伪代码.....;    a3逻辑伪代码.....;    doB();}
void doB(){    b1逻辑伪代码;    b2逻辑伪代码;}

第二种问题：不对等+部分抽取

第二种是对部分逻辑进行了抽取，抽取的方法应该都不太好命名，已经影响到了代码阅读和理解。

void doSomething(){    doA();    a3逻辑伪代码.....;    doB();}void doA(){    a1逻辑伪代码.....;    a2逻辑伪代码.....;}
void doB(){    b1逻辑伪代码;    b2逻辑伪代码;}

第三种问题：不对等+抽取错误

第三种是最严重的问题，逻辑已经很难读懂，如果在这个基础上再应用一些设计模式，就成功的成为了只有自己可以看懂的代码。

代码基础能力思考

能做到本文说的代码层次清晰，对等，代码就及格了。(这个及格标准其实并不低)

很多人看到这里，会觉得这些错误太明显，自己绝对不会写出这么懒的代码；我想，一开始也许不会，但伴随新需求，代码逐渐腐烂，不同人不断修改，基本见到的都是把这几个问题综合展现的代码，不看到最底层执行，根本不知道代码在做什么。

实际我见到的情况是，不仅仅是代码腐烂问题，新项目做完，能达到这个标准的也不多，但这个标准真的只是及格分，站在这个标准之上，才可以考虑代码如何更好的面对变化，抽取变化为接口，使用更优秀的设计模式等等。

如果都做不到及格分，任何加工只会是雪上加霜，代码会更看不懂。

关于小方法的不同看法，可以参考另一篇《小方法抽取与母语的关系》