对2010年7月前工作的总结

最新推荐文章于 2025-04-20 15:18:42 发布

原创最新推荐文章于 2025-04-20 15:18:42 发布 · 348 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#工作 #2010 #文档 #测试 #产品

反思总结专栏收录该内容

2 篇文章

订阅专栏

本文强调了在软件开发过程中，编码之前详细撰写文档及定期总结的重要性。通过案例分析，阐述了缺乏文档和总结可能导致的问题，并提出了改进措施，如详细记录界面说明、后台流程、表结构等，以及在开发过程中维护文档的重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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

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

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

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

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

最后包括表结构定义。

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

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