标签：style 使用 strong 文件 sp 数据 on 问题 代码
这几天，跟旁边项目组的同事聊天，下班的时候也一起聊些项目上的事。通过他的描述和我看到的一些情况。确实发现不少问题的。首先就是上线成功率不高。很少有一次发布成功的情况。大部分都是发布之后，出现各种问题，又得改bug重发。开发和测试流程不规范，开发人员很随意。然后就是各种技术风险。
发布质量不高每次发布都跟打仗一样，每次上线发布，都要一两个小时，作为一个公司内部的web系统，一次小版本的更新，发布时间都要在1个小时以上，就足以说明很多问题。
发布质量不高
1. 发布的质量不高，没有进行系统的集成测试，每次都是开发人员测试通过之后，就完事了。没有集成测试的过程，导致上线之后，本功能没问题，但是影响到其他的功能。导致上线不成功，重新修改bug ，然后上线。
2. 发布人员没有进行必要的冒烟测试，由于没有专门的测试人员，发布和测试的人员都是开发人员进行的。所以，发布人员，没有获取完最新的代码之后，没有进行必要的冒烟测试之后，就直接发布。导致很多时候，发布之后，网站直接不可用。这类问题，应该上线之前的冒烟测试就要测试出来。
流程不规范
开发流程不规范。开发的时候，有很多随意性，有些数据库脚本，没有在测试环境测试，直接就在生产环境中执行。或者本身脚本没有问题，但是影响到其他功能。开发人员只关注自己的那一块，没注意到修改之后，对其他功能的影响。
测试流程部规范。只测试自己的部分功能，没有经过集成测试，就直接发布，导致系统发布之后，出现各种未知的问题。
有些时候竟然出现发布完之后，开发人员还有代码未迁入或是发布人员未获取到开发人员所提交的代码的情况。这类问题，必须要有规范的流程。
团队分工不明确
这个项目可以分为api和web网站两部分。但是开发人员对其定义不明确，职责也不明确。出了问题，所有开发人员都去猜测问题可能会出现在那块，所有的人都从前端测试到后台，做了很多无用功。如果分工明确，那么api 的去检查api是否有问题，web网站的开发人员去检查网站前端。这样就能快速定位并解决问题。
技术风险
由于这个项目用到了mysql，EntityFramework这以前没用过的东西，导致存在很多技术风险。比如mysql 所有的开发人员都是只知道一般的使用，没有一个对mysql 了解比较深的人，EntityFramework 也是如此。出现了性能问题，很多时候不知道该如何优化。
思考
1. 明确分工和职责。项目分块，专人负责。
2. 优化开发流程，倡导代码规范，修改代码之前，确保没有其他地方使用到，团队对于哪类文件该提交哪类文件不该提交要达成共识。
3. 优化测试流程，所有的功能，开发人员测试没问题之后，才算完成，提交，一定要进行集成测试，发布之前开始要求提交代码，并进行集成测试。所有的功能要在测试环境测试通过才能发布。测试人员发布的最终发布版本，要进行必要的冒烟测试。
4. 消除技术风险，技术问题，交由专门负责人员解决，mysql和EntityFramework 这类交由专人负责并掌握。消除这类技术风险。
标签：style 使用 strong 文件 sp 数据 on 问题 代码
原文地址：http://www.cnblogs.com/zhangweizhong/p/4025341.html
