标签：style 使用 strong 文件 数据 问题 sp 代码 on
最近经历了一次规模不算小的项目开发与上线，过后感触颇多，有成就感，但也有不少经验和教训，总结记下以备后用。
注：考虑到保密问题，有些细节写的很模糊。
1.与旧有系统的兼容性
本次开发的这个项目主要是将旧版系统完全升级(重写)为新版系统，但是由于很多数据是通过旧版系统生成，所以新版系统上线后产生了数据兼容性问题。
(1)在测试环境下所有菜单中文没有什么问题，然而上线当天晚上，文件打包发送到服务器上后，发现所有中文变成了乱码，不得已，数十个模板只好一个一个手改，好在不是很多，每人分了几个很快搞定了，可是事后在想，如果当时更多中文菜单出错怎么办，而且在那种情景下，再进行大规模文件更改很容易导致出错。后来发现，是由于测试环境和线上环境的编码设置存在差异，而开发时候没考虑到这第一点才出现了这样的问题。
(2)第二个问题(该模块由本人负责开发)是由于原来的系统是一款著名的cms,现在新的系统不再使用，然而该CMS的内嵌富文本编辑器在处理单双引号实体转义方面有些瑕疵(也可能由于我们使用的版本较早)，早期由该编辑器编辑的文本数据通过新系统中新的编辑器显示后，标签没有被解析，实体被原样输出。
总结：遇到新系统升级类型的开发的时候，一定要充分考虑到新旧系统的兼容问题。
2.业务需求模糊不清
曾经在某程序员论坛上看到一则博客，说的是程序员是否需要学习所在领域的业务知识，现在工作了近一年，结合自己的亲身经历，对这个问题的回答是：必须需要，而且很重要。中国的软件开发企业主要还是应用开发居多，而应用开发是必须结合具体的业务场景的，如果连自己开发的模块的业务流程都不知道，怎么去做开发，不知道what，如何去how，所以从这个角度讲，业务流程就是应用层软件开发中的“算法”。
(1)旧版系统向新系统迁移时，后台管理模块有些字段和功能需要裁减，但由于业务不清楚，裁减过程中出现了不该去掉的功能去掉了，可以去掉的没去掉，导致阶段性会议评审中被反馈返工修改，对工期造成了影响，只能通过加班完成。
(2)最近随着互联网兴起，敏捷开发也如火如荼地在各个企业被“采用”，然而，在这之中的大多数情况是“画虎不成反类犬”，敏捷开发强调“重交流，轻文档”，可是到了具体实践中变成了“靠交流，不文档”。造成的后果就是项目中切入新手，就需要花大量实践去通过阅读代码等低效率的方法熟悉业务，同时新手对组内老成员的询问(主要是业务上的)频繁打算其思维，这是很烦人的(相信大家都有写代码时候被打断的情况，那个感觉就不多说了)，再进一步，完美、高效的沟通也许可以替代书面，但是纵观程序员这个群体的沟通能力，呵呵。。。。。
总结：业务中可以多交流，但是该有的文档还是应该要有，尤其是相对而言变动较少的业务流程，还是应该文档化。
3.工期安排
(1)整个开发过程中穿插着阶段性评审会议，会后可能会对根据评审对模块进行反馈式修改，这样就会导致工期延后。
(2)整个项目中，同样一个模块，对于熟练的老手和新手所需要花费的时间是不同的，因此在安排工期和分配任务时需要考虑。
总结：安排工期不应当仅仅按照模块一个接一个安排，每个阶段中应当留出冗余时间来应付工期本身的进度变更。
4.上线环境和测试(开发)环境的一致
(1)新系统有一个功能模块，是手机发送下载功能，同事在开发这个功能时，测试环境竟然不能进行短信发送，也就是说，验证码发送下载这个流程无法进行上线前测试，没办法，只好在脑子里进行流程测验，仔细审查了所有代码的流程，最后上线前自信满满认为不会出问题，结果当晚上线这个功能无法正常使用。。。。。。。。
(2)前面说的乱码问题，由于线上的数据和测试环境的数据不一样，测试环境很多静态资源没有，结果在单元测试的时候也没有发现图片无法显示和乱码问题，结果上了线出问题了。
(3)测试。有些公司感觉对测试的重视还是不够，许多测试都是形式化的走一遍流程，更不用说什么边界测试等等，而程序员单元测试的时候，总是倾向使用“干净”的数据，使得问题无法被尽可能多的被暴露。
总结：测试环境从布局、数据到软件版本，都应该和上线环境尽可能相同；单元测试的时候应该尽可能详细，如果时间条件允许，组员之间可以进行交叉模块测试。
这次上线学习了不少，既有技术上的也有非技术的，总结下来以后经常复习思考，避免下次上线跌倒在同样的地方，同时随着工作经验的增长，文中有些观点可能还需要进行修正和补充，欢迎大家提出宝贵的意见。
标签：style 使用 strong 文件 数据 问题 sp 代码 on
原文地址：http://my.oschina.net/u/1472370/blog/313172
