订单管理系统开发小结

做了一个半月，终于可以交差了，也仅仅是可以交差而已。

这一个半月来，最大的感触就是，做产品型的软件时，必须要仔细的了解客户的需求，并且在动工写代码之前，首先需要列出来一个产品的功能构想和使用流程图给客户看，如果客户满意了，就动工写代码，不满意的话就针对客户提出的意见进行修改，直到客户对产品的功能和流程图满意了之后，再动工写代码。

这次出来遇到的最大的麻烦就是，自己的老板有一套思路，工厂的老板有一套思路。这个项目虽然交了差，但是到现在还是稀里糊涂的不知道当时是怎么签的合同，码农和客户的思路都没有达成一致，就动工写代码了，结果写出来的代码不能让工厂老板满意。这尼玛是必然的好不好，不按人家的思路做，结果自己这么做的理由还不能说服人家。。。想到这里，我都觉得老板接这个项目可能完全是出于情面，象征性的收点钱然后帮哥们的忙，因为如果是为赚钱的话，当然得遵循“客户就是上帝”的原则啊。

吐槽结束，进入正题。下面列出此次项目中找到的自己的软肋（其实事实是一个块硬肋都木有好吧T^T）。

1.没有养成模块化编程的思维：

问题：

刚开始做时，为了赶工期，对系统的修改总是东一砖西一瓦，力求改的东西最少。但是做到后来发现，这样做其实反而低效，因为写出来的代码基本不能重用，就算可以，还是要修修改改之后才可以。这样就导致，发现一段代码有问题，就需要改复制了这段代码的其它代码，这样就导致很可能有些地方漏改。

解决方案：

以后再实现某一功能是时，首先抱着这种态度——这个功能以后一定会重用，然后按这个思路来设计输入输出接口。要做的这点，必须先要对接下来要实现的功能做一个抽象，把这个功能分成两部分，一部分是通用部分，一部分是非通用部分。通用部分的接口是面向重用的，非通用部分的接口是面向特定系统的。

其实个人觉得模块化思维还是跟项目经验有关系，只有写过不好的代码，才能意识到好的代码应该是什么样的。

2.对数据的封装做的不好

问题：刚开始做时，觉得数据分类越清晰越好，于是就建了很多表。这样做有好处，也有坏处。好处就是查询的效率比较高，坏处就是代码的重用度很低，因为数据库是为了适应某个项目而建立的，再换一个项目，有些数据就没有用了，而且需要再添加另一些数据，这样一来，不同系统中操作数据库的代码的重用度就降低了。

解决方法：

以后再做项目时，首先要根据客户已经接收的流程图，来对数据做一个规划，抽象出来通用数据和专用数据，先建立数据库结构，然后再写代码。