我的编码过程

编码原则

我比较推崇优秀编码中的SLAP原则和面向对象的SRP原则。

• SLAP原则（单一抽象层次原则）的含义是：让一个方法中所有的操作处于相同的抽象层。符合SLAP原则的代码，阅读起来更流畅且易于理解。
• SRP原则（单一职责原则）的含义是：一个类应该仅有一个引起它变化的原因。遵循SRP原则的好处是，减低了类的复杂性，提高了代码的可读性、可维护性。

我的编码过程主要借鉴了这2个原则的思想，形成了自己的两个原则：

• 自顶向下逐层编码：做任何一个编码动作时，都自顶向下逐层细化。在本层次没有完成之前，不要涉足下一层的编码。这样在整个编码过程中，会时刻掌握着大局，不会迷失方向，更加胸有成竹，避免因为陷入细节迷失大局方向而导致的不合理设计和返工。
• 单任务非抢占编码：不要一次做多件事情，一次只做一件事情。做完一件事情再做另外一件事情，不要中途跳转。例如：在做当前这件事情的时候，突然想到前面做完的某件事情可能还需要修改一下，或者突然想到一个好的设计后面的事情会用到，先用txt文件把自己突然想到的内容记录下来，然后继续把手上的事情做完。

编码过程

自顶向下逐层设计

• 拿到需求分析文档，看懂需求。
• 用PPT或白纸简单画一下系统中各部件的交互流程。
• 用UML设计各部件的包、类图（遵循面向对象设计原则、使用合理的设计模式）。
• 在类图中补充各类的公共方法。
• 用txt文档记录需要编码的任务（只简单记录任务，不含设计的内容，设计内容在PPT、白纸、UML类图上）。
  例如：
  1 新建类A
  1.1 实现public方法MethodA1()；
  1.2 实现public方法MethodA2()；
  2 新建类B
  2.1 实现public方法MethodB1()；
  2.2 实现public方法MethodB2()；

自顶向下逐层搭建代码框架

• 把每个类的空架子搭起来：public方法先写一个空的，在方法里面用注释把大致的逻辑写出来，写清楚什么条件下调用了其他类的哪个pubic方法。把类大致的成员变量写上去。
• 对照设计的流程图，简单看一遍现在的代码框架，看是否与设计的有偏差。
• 逐个类实现其中的public方法。先设计public方法中的操作应该怎么抽象，应该抽象出几个下一层次的private方法（按照SLAP原则抽象）。然后把public方法注释去掉，改为对private方法的调用，这时候public方法已经编码完了。
• 把前面抽象出来的private方法实现任务写入到txt文档中。
  例如：
  1 新建类A
  1.1 实现public方法MethodA1()；
  1.1.1 实现private方法MethodA3();
  1.1.2 实现private方法MethodA4();
  1.2 实现public方法MethodA2()；
  1.2.1 实现private方法MethodA5();
  1.2.2 实现private方法MethodA6();
  2 新建类B
  2.1 实现public方法MethodB1()；
  2.1.1 实现private方法MethodB3();
  2.1.2 实现private方法MethodB4();
  2.2 实现public方法MethodB2()；
  2.2.1 实现private方法MethodB5();
  2.2.2 实现private方法MethodB6();
• 对照设计的流程图，再看一遍现在的代码框架，看是否与设计的有偏差。

写UT测试用例

。。。。。。

自顶向下逐层填充代码实现

• 逐个类逐层实现其中的private方法。参考上面实现public方法的步骤：先按照SLAP原则抽象本private方法，实现本private方法，然后在txt文档上记录新抽象出来的下层private方法实现任务。
  例如：
  1 新建类A
  1.1 实现public方法MethodA1()；
  1.1.1 实现private方法MethodA3();
  1.1.1.1 实现private方法MethodA7();
  1.1.1.2 实现private方法MethodA8();
  1.1.2 实现private方法MethodA4();
  1.2 实现public方法MethodA2()；
  1.2.1 实现private方法MethodA5();
  1.2.2 实现private方法MethodA6();
  。。。。。。
• 继续逐层实现其中的private方法，直到所有代码都写完。当正在实现某个方法时，突然想前面已经写完的方法可能还需要修改一下，先用txt文件把自己突然想到的内容记录下来，然后继续把手上的事情做完，然后再去修改前面实现的方法。
• 编码过程中也是逐步细化设计的过程，可能会反过来修改前面的设计文档和类图。

按照各个维度多次走读代码

• 业务端到端正常流程快速走读
• 业务端到端异常流程快速走读
• 自顶向下逐层详细走读每个方法（按代码行自上向下检视，每次完整看完一个方法，不要中途跳转到该方法调用的底层方法上去）
• 重点检查每个方法中循环、控制语句在各条件下的处理逻辑
• 业务端到端正常流程详细走读
• 业务端到端异常流程详细走读

按照上面这几个思维维度来多次走读代码，每次走读只用一个思维维度，走读过程中查找BUG和写得不好需要优化的地方，走读过程中把找到的修改点先用txt文档记录下来（如下：），等这次走读完后，再集中修改BUG和优化代码。修改完BUG后，再开始下一次走读。
1 新建类A
1.1 实现public方法MethodA1()；
1.1.1 实现private方法MethodA3();
1.1.1.1 实现private方法MethodA7();
Bug1：xx场景没有考虑，功能缺失。
优化2：方法太长了，要再抽象提取几个方法出来。
1.1.1.2 实现private方法MethodA8();
。。。。。。

执行UT测试用例

通过多次检视，当觉得自己写的代码，各种场景都考虑全了，觉得没问题了。再通过自测试来证明一下自己的代码没有Bug。
而不是刚写完代码，心里还没底，就急着想通过测试/调试 来找自己代码中的Bug。