维护型项目的管理

最近，一直在维护一个项目。项目很大，有很多个系统相互配合，且使用的语言也不一样。有JAVA写的系统，有PHP写的，各系统用的数据库也不一样，还有一些我说不出来的技术。项目一直需要维护，每个月都有新的需求要开发，也要支持新系统的部署和日常管理。这是一个企业很常见的产品模式，思路都很清晰。但是，我之所以写下这篇感悟，是因为我觉得自己对项目管理的感受更深了一层。

首先，我要说的是我们项目的不合理之处。

第一点，没有使用诸如MAVEN等的项目管理工具，造成项目代码虚胖。

第二点，没有使用适合该类型项目的按业务分包的模式，归类代码。造成的结果就是高度的耦合。

第三点，虽然使用了SVN协同开发，但没有版本管理。由于需要面对多台服务器的升级与维护，以及新需求的开发，没有版本管理，升级是多么痛苦的一件事。现实结果是我们经常因为未知原因，造成升级线网失败而回滚。

第四点，数据库的建模不合理，缺少约束，技术使用不当。其实项目程序总是处在维护中，由于各类人员的变动造成项目理解误差，即便是经过测试后的代码，上线后总是因为程序漏洞或者业务变动而造成垃圾数据的产生。和程序逻辑变动相比，数据库模型的变动是很小的。我觉得应该尽量把逻辑优先设定在数据库层。如果说在数据库层设置逻辑约束而影响性能，那么再考虑在程序逻辑层把好数据关。另外，项目的数据库建模也糟糕透了。关系不清楚，就连我们开发人员自己都不是很清楚。这种状况与人员变动也有关系。因为没有正确使用缓存，造成数据总是不同步。

第五点，文档不规范，也没有及时维护。这一点是非常严重的。单词拼写错误最为常见。数据库的字段命名，程序代码中，接口文档中有很多单词错误。另外，项目中一个词语有多个版本，比如“用户名”，有“user_name,account”；“机构”有“organization,agency,institution"。项目中也存在命名格式不专业的问题，有"user_name"格式的，有"username”格式的，也有"USERNAME"格式的，常用的是“userName”格式，最后这个才是规范。接口返回不规范也有，虽然有一个文档规范了接口返回的代码含义，但是实际中用的不准确。

第六点，接口设计不合理。接口设计过于复杂，返回数据范围广。这造成了接口异常的慢。即便是使用了缓存系统，复杂的接口，蕴含了复杂的逻辑处理，也快不起来。接口设计应满足一定粒度限制。不能太大也不宜太小，太大响应时间长；太小浪费请求时间。

第七点，安全性问题。这个问题，我不详述。虽为第七点，却是最大隐患。

很多时候，因为项目时间短，我们就会以此为借口，仓促奔赴战斗。我们总是告诉自己，将问题的解决归到未来的优化中。但问题在于，大厦堆的高了，修复难度和成本也高。做事情，基础最为重要。以上的几点问题，首先是因为基础没有打好，缺乏前瞻性；其次是项目管理缺失，最后是执行力不够。

其次，大型项目的管理，需要有公司层次的思维。

人员总是在变动，但公司是不动的。不论集体还是个人都会在过程中过程后积累知识，经验，发现不足之处。如果优秀的东西能够得到继承与发扬，不足之处能够得到改进，那么做出来的产品会越来越好，劳动也会越来越轻松。之所以说管理要有公司层的思维，是因为这个层次可以推广好的生产方式，这是继承的思维。这个层次可以更多地协调事务，毕竟问题的最佳解决层次不往往都是在一个范围。有的问题放到小组内解决即可，有的问题放到团队内部解决为好，有的问题放到公司内部解决最妥。具备这种能力，也需要职员有意识。

最后，人力交接的重要性。人员总是在变动。我刚来的时候，就立马被派着处理数据割接的问题。这里我也表达了管理层用人不当的一个问题。由于没有接受公司项目的培训而直接上了战场，造成的结果就是我没有很好的解决问题，给系统造成了BUG，最后我不得不花很多时间修复它。我认为人力交接是一个问题。主要集中在项目适应上。每个人对陌生的环境都需要一个适应过程。需要去了解业务，了解团队工作模式，了解现有的工作成果。不管怎么样，不管公司层次怎么想，作为团队LEADER一定要有这种思维。否则，会给他人和自己造成麻烦。

虽然感悟了很多不足之处，但是团队中也有很多地方可圈可点。不过，我这人对不合理的地方总是那么映像深刻，然后喜欢去寻找解决办法。对好的东西总是因为认同它，最后因为形成习惯而记不清。现在记录这些，对自己对他人都会有用吧。