项目尾声，本该欢天喜地，可问题又屁颠屁颠的出现了，O(∩_∩)O~
问题：
300多张表，30来个视图，80多个存储过程，
项目尾声了，数据库整理人员还得一个一个得去问开发人员
这些表，视图，存储过程分别谁写的？
什么时候写的？
程序里是否有用到？
哪个模块用到了？
这个时候出现这样的问题，应该属于‘癌症’级别的严重了。
结合这个项目的实际开发情况，个人分析有以下几点原因：
1。项目开始就没设计好。
项目没做详细的设计，程序里会用到哪里类，哪些方法，哪些表，需要建立哪里视图，存储过程，都是未知数。
只是开发人员，需要一个就建立一个。建立却没一个统一文档记录。
2。项目开发中没规范编码格式。
编码人员，各有各的编码习惯，比如建立存储过程，A同志喜欢写一些注释：创建时间，创建人，大概描述等，
可B同事却没这个注释，写的代码只有Ta自己看得懂，甚至过段时间，都不确定是自己写的。
3。项目开发中就没有对这些进行统一管理。
在程序里，对存储过程的调用，没有对存储过程名称进行统一的管理。
哪里用就硬编码写上去，这样“又臭有硬”，哈哈。。。
个人觉得最好把存储过程的名称放到一个类里，统一管理，方便调用，
需要查找的时候，也不用整个项目查找。
当然，很多事情，都是做过之后才晓得怎么做。
总结才能积累经验，才能避免以后走弯路：
1。需求永远是第一。
以后做公司项目没需求文档，详细设计文档，绝不编码。
2。规范编码
编码之前，必须得统一个开发标准，因为代码不是一个人写。
3。人以群分物以类聚。分类，统一管理文档，SQL脚本，随时跟踪。
4。最好分工明细。
个人觉得，如果一个项目有3,4个人参与，就应该明确的分工。
A完成数据库的设计，比如表，视图，存储过程的编写。
B完成后台代码的编写。
C负责界面开发。
D负责测试
。。。。
当然目前很多公司，都是一个人负责一个模块，包括数据库的设计啊，后台代码，界面实现等等。
这样确实能让写代码的人，学到，接触到更多的东西，但是不专一，技术"不深入,难高潮"啊，嘿嘿...
记得以前看到一篇文章，一个马来西亚的人，他说他做登陆界面就做了4年，呵呵，很难想象。
但是可以肯定是说：他做登陆这个功能的经验绝对丰富。
软件不能按时按量的完成，
很大情况就是项目管理出了问题吧，大家应该同意这说法。
编码人员，别只局限于写代码吧，
写写博客，哪怕写的多垃圾，也是一次写作的锻炼。
发现没？园子里的“大牛“，都是常写博客的。
哈哈，下班，闪人，坐免费BRT。。。