听好几位前辈都说过,要善于总结。有总结,才会有进步。
一个星期也好,一个月也好,几个月也罢,对自己做过的事情进行一次总结,那怕是一次“头脑回放”也好。想想自己做过的事情,同样的事情如果现在让你做,也许你就不会像以前那样去想去做了。写代码也一样,写完成整个功能模块,再看需求,再看自己的实现,然后再最好整体上进行一次重构,是比较理想的。
前面几个月所做的事情,在当时都能按时按需要完成,但到现在全面测试的时候,会发现有很多问题,但这些问题也不是太多的问题,有些则是完全可以避免的。可就是由于自己的原因,当时考虑不够仔细。这样,在测试阶段,也可以及时修改,可这些小问题,在客户眼中也不分大问题还是小问题,它会在客户心目中造成系统不稳定或者产品不成熟的印象。
在一个成熟的或者自己比较熟悉的系统上做开发,可能是比较大意、随意,相关的文档也没有去写或者写的不认真。比如前段时候让我负责的一个模块,整个系统流程我也比较清楚,对客户的需求掌握的也差不多,然后自己写文档,准备讨论。可写的时候,很浮躁,不太认真的去写,里面夹杂着部分伪代码,和经理讨论的时候,他一看也明白,可能是没有太认真的看吧,他对文档要求也一般。所以就过了。现在回过头来看代码,就会发现逻辑也是有些混乱。甚至有种重新再写次的冲动!
切记,在以后,不管自己看起来多简单或者多复杂,都要写文档。哪怕时间再紧张,也要写,写的原则就是让别人一看就明白,一看就可以接手。如果时间真的太紧张,就可以简单点。
文档内容首先要有界面说明,包括每个栏位的名字,长度,输入输出,类型,介绍,还有栏位之间逻辑控制。其次就是后台的流程说明,尽量详细到每步都有说明,有什么输入,有什么输出。形成一个闭环。如果负责的一整个模块,最好把每个小模块之间的关系也有图理出来。
最后包括表结构定义。
另外,如果有相关系统参数的配置,我觉得也最好添加进来,然后在开发过来中维护这份文档,和其他人员沟通的时候,就讲这份文档,我觉得效果会不错的。
主要是编码之前,把这么详细的文档和客户讨论一番后,可以把很多细小的问题确定下来,这样以后测试过程中,可能就会很顺利的。