一次大项目上线的总结与思考

最近经历了一次规模不算小的项目开发与上线，事后感触颇多，有成就感，但也有很多经验和教训，总结记下以备后用。

注：考虑到保密问题，有些细节写的很模糊。

1.与旧有系统的兼容性

本次开发的这个项目主要是将旧版系统彻底升级(重写)为新版系统，可是因为不少数据是经过旧版系统生成，因此新版系统上线后产生了数据兼容性问题。

(1)在测试环境下全部菜单中文没有什么问题，然而上线当天晚上，文件打包发送到服务器上后，发现全部中文变成了乱码，不得已，数十个模板只好一个一个手改，好在不是不少，每人分了几个很快搞定了，但是过后在想，若是当时更多中文菜单出错怎么办，并且在那种情景下，再进行大规模文件更改很容易致使出错。后来发现，是因为测试环境和线上环境的编码设置存在差别，而开发时候没考虑到这第一点才出现了这样的问题。

(2)第二个问题(该模块由本人负责开发)是因为原来的系统是一款著名的cms,如今新的系统再也不使用，然而该CMS的内嵌富文本编辑器在处理单双引号实体转义方面有些瑕疵(也可能因为咱们使用的版本较早)，早期由该编辑器编辑的文本数据经过新系统中新的编辑器显示后，标签没有被解析，实体被原样输出。

总结：遇到新系统升级类型的开发的时候，必定要充分考虑到新旧系统的兼容问题。

2.业务需求模糊不清

曾经在某程序员论坛上看到一则博客，说的是程序员是否须要学习所在领域的业务知识，如今工做了近一年，结合本身的亲身经历，对这个问题的回答是：必须须要，并且很重要。中国的软件开发企业主要仍是应用开发居多，而应用开发是必须结合具体的业务场景的，若是连本身开发的模块的业务流程都不知道，怎么去作开发，不知道what，如何去how，因此从这个角度讲，业务流程就是应用层软件开发中的“算法”。

(1)旧版系统向新系统迁移时，后台管理模块有些字段和功能须要裁减，但因为业务不清楚，裁减过程当中出现了不应去掉的功能去掉了，能够去掉的没去掉，致使阶段性会议评审中被反馈返工修改，对工期形成了影响，只能经过加班完成。

(2)最近随着互联网兴起，敏捷开发也如火如荼地在各个企业被“采用”，然而，在这之中的大多数状况是“画虎不成反类犬”，敏捷开发强调“重交流，轻文档”，但是到了具体实践中变成了“靠交流，不文档”。形成的后果就是项目中切入新手，就须要花大量实践去经过阅读代码等低效率的方法熟悉业务，同时新手对组内老成员的询问(主要是业务上的)频繁打算其思惟，这是很烦人的(相信你们都有写代码时候被打断的状况，那个感受就很少说了)，再进一步，完美、高效的沟通也许能够替代书面，可是纵观程序员这个群体的沟通能力，呵呵。。。。。

总结：业务中能够多交流，可是该有的文档仍是应该要有，尤为是相对而言变更较少的业务流程，仍是应该文档化。

3.工期安排

(1)整个开发过程当中穿插着阶段性评审会议，会后可能会对根据评审对模块进行反馈式修改，这样就会致使工期延后。

(2)整个项目中，一样一个模块，对于熟练的老手和新手所须要花费的时间是不一样的，所以在安排工期和分配任务时须要考虑。

总结：安排工期不该当仅仅按照模块一个接一个安排，每一个阶段中应当留出冗余时间来应付工期自己的进度变动。

4.上线环境和测试(开发)环境的一致

(1)新系统有一个功能模块，是手机发送下载功能，同事在开发这个功能时，测试环境居然不能进行短信发送，也就是说，验证码发送下载这个流程没法进行上线前测试，没办法，只好在脑子里进行流程测验，仔细审查了全部代码的流程，最后上线前自信满满认为不会出问题，结果当晚上线这个功能没法正常使用。。。。。。。。

(2)前面说的乱码问题，因为线上的数据和测试环境的数据不同，测试环境不少静态资源没有，结果在单元测试的时候也没有发现图片没法显示和乱码问题，结果上了线出问题了。

(3)测试。有些公司感受对测试的重视仍是不够，许多测试都是形式化的走一遍流程，更不用说什么边界测试等等，而程序员单元测试的时候，老是倾向使用“干净”的数据，使得问题没法被尽量多的被暴露。

总结：测试环境从布局、数据到软件版本，都应该和上线环境尽量相同；单元测试的时候应该尽量详细，若是时间条件容许，组员之间能够进行交叉模块测试。

        此次上线学习了很多，既有技术上的也有非技术的，总结下来之后常常复习思考，避免下次上线跌倒在一样的地方，同时随着工做经验的增加，文中有些观点可能还须要进行修正和补充，欢迎你们提出宝贵的意见。