项目已进入测试阶段。此时，编码风格对测试工作的影响体现得非常明显。具我观察，总结了几种代码结构。希望能对今后的工作有所借鉴。
1、 大多数编码采用了嵌套SQL编写业务。这样做的好处主要是性能有一定提高——不论多少数据，只要查询一次数据库就可以了。我觉得，这种代码过于追求性能了，使可读性遭到很大打击！几千行的组合SQL，运行Log显示出来的sql文是没有注释的，而且与式样书也是几乎不一致。这样的代码阅读过程难以想象，测试难度较高。
2、 有些编码是依据式样书编写业务。式样书提到一个SQL就写一个。但对程序流程有一些改动，主要是为了优化代码。这种代码往往需要多次查询数据库，虽然降低了一些性能，但并不超越软件的要求。我觉得，可读性和前一种相比大有提高。但对个人能力的要求较高。对于代码优化方面，编程的时候往往是不确定因素，不同的人优化重构出来的代码往往不一样，编码差异有时可能很大，难以制定统一的标准，不太适合成为团体软件开发模式。
3、 个别人完全按照式样书的流程编写代码。其注释几乎就是将式样书copy一遍。代码与式样书有着按顺序一一对应的特点。给我印象最深的是刘*的一次review。别人的代码被Review时往往会抱怨鸡蛋里挑骨头，而刘*的代码则完全挑不出骨头。其中，找出过几个被认为是应该调用共通而不应自己编写的代码片断；但，刘*拿出式样书，代码与式样书完全一致；如果调用共通，虽然编码易修改性、统一性等指标会提高，但是顺序就会被打乱，尤其是入力check，如果check顺序与式样书不符合，未必就不是功能缺陷，反而不可取。
我觉得完全按照式样书的编码方法虽然在编码量和编码性能等等指标上未必是最好的。但它有一个最大的优势：易于组织团体实施。编码标准非常明确——唯一的标准就是是否与式样书一致。如果一个团队在编码项目中明确运用这种过程，不同的人做出来的编码应该是完全一样的，十分适合团体软件开发。而后期测试工作，第3类代码更是体现出其优越性。其它类型的代码往往需要更多的测试数据代入测试数据流的正确性。而第3类代码则可以简化：运用简单的数据代入测试其可运行，然后对照式样书Review代码就完全可以确定代码的正确性。但是也有缺点，式样书的正确性往往容易被忽视。如果式样书是错误的，编码往往也会出错。
