对2010年7月前工作的总结

听好几位前辈都说过，要善于总结。有总结，才会有进步。

一个星期也好，一个月也好，几个月也罢，对自己做过的事情进行一次总结，那怕是一次“头脑回放”也好。想想自己做过的事情，同样的事情如果现在让你做，也许你就不会像以前那样去想去做了。写代码也一样，写完成整个功能模块，再看需求，再看自己的实现，然后再最好整体上进行一次重构，是比较理想的。

 

前面几个月所做的事情，在当时都能按时按需要完成，但到现在全面测试的时候，会发现有很多问题，但这些问题也不是太多的问题，有些则是完全可以避免的。可就是由于自己的原因，当时考虑不够仔细。这样，在测试阶段，也可以及时修改，可这些小问题，在客户眼中也不分大问题还是小问题，它会在客户心目中造成系统不稳定或者产品不成熟的印象。

 

在一个成熟的或者自己比较熟悉的系统上做开发，可能是比较大意、随意，相关的文档也没有去写或者写的不认真。比如前段时候让我负责的一个模块，整个系统流程我也比较清楚，对客户的需求掌握的也差不多，然后自己写文档，准备讨论。可写的时候，很浮躁，不太认真的去写，里面夹杂着部分伪代码，和经理讨论的时候，他一看也明白，可能是没有太认真的看吧，他对文档要求也一般。所以就过了。现在回过头来看代码，就会发现逻辑也是有些混乱。甚至有种重新再写次的冲动！

 

切记，在以后，不管自己看起来多简单或者多复杂，都要写文档。哪怕时间再紧张，也要写，写的原则就是让别人一看就明白，一看就可以接手。如果时间真的太紧张，就可以简单点。

文档内容首先要有界面说明，包括每个栏位的名字，长度，输入输出，类型，介绍，还有栏位之间逻辑控制。其次就是后台的流程说明，尽量详细到每步都有说明，有什么输入，有什么输出。形成一个闭环。如果负责的一整个模块，最好把每个小模块之间的关系也有图理出来。

最后包括表结构定义。

另外，如果有相关系统参数的配置，我觉得也最好添加进来，然后在开发过来中维护这份文档，和其他人员沟通的时候，就讲这份文档，我觉得效果会不错的。

 

主要是编码之前，把这么详细的文档和客户讨论一番后，可以把很多细小的问题确定下来，这样以后测试过程中，可能就会很顺利的。