职业生涯的前六年都是在软件公司做的，那时候流程再多，规范再严格，都有时间和空间来执行。最近几年在互联网公司工作也做相应的推行时，对于一些原来在软件公司一直使用的相对严格的规范和流程在执行过程中遇到非常多的问题。
遇到情况基本有几种：
1、更新比应用软件频繁。市场在变，客户在变，需求自然也在变，如果我们不变，就会被市场淘汰。原来做应用软件的时候，最多一周甚至一个月更新一次软件版本，客户已经很满意了，现在线上的东西，用户发现了BUG或体验不好的地方，一天都等不到，投诉量急剧上升，领导和PD会一直催着你解决问题；
2、线下测试环境往往和线上生产环境很难做到一致。尤其是解决跨域访问或一些需要和其他网站合作进行用户验证的功能，在线下几乎无法进行测试；
3、一个网站的功能数量往往可以和一个大型的应用软件相比。每一块都有相应的产品经理在优化推进，每一块都有多个技术人员进行开发，但是发布时只允许一个包上线。当多个分支同时进行，需要在相同的时间点上线，合并分支分成为开发人员的恶梦；
4、更新过快导致无法保持模型与代码的统一，代码缺少清晰的注释和说明（根本来不急写），代码执行性能较差；
5、分工过于细，程序员已经不清楚线上系统部署情况和服务器负载能力，写出来的代码安全性和可扩展性差。
面对这些问题，如果执行流程会更混乱，只有改造流程才能让工作更有序。目前对这些问题有一些解决办法和大家分享一下：
1、控制需求数量。虽然用户和产品经理（PD）会有很多需求让技术人员来解决，但并不一定要马上解决所有的问题。
首先，要区分事务的优先级。一般我们现在是以系统异常第一，BUG第二，功能需求第三的顺序在执行。
为什么系统异常排第一，是因为它会让应用服务器的性能急剧下降，甚至在没有多大流量的情况下直接当机，所以一定要优先解决。而经过测试的代码，最低要求也是没有异常才允许上线发布。
当然，功能也有高优先的，所以必须和客户、产品经理坐下来讨论哪些是第一时间要解决的，哪些是次要的。学习过时间管理的同学应该知道，优先级的划分是：紧急，重要，不紧急，不重要这四类。
紧急的固然是要马上解决的，但是重要的事务也是需要好好讨论的，比如性能优化，虽然现在的页面打开速度也能接受，但是如果不做更进一步的优化而页面上的功能越来越多，性能问题就会变成紧急的事务。一般来说，如果我们的精力90%放在解决重要的事务上，那么紧急的事务也就只有10%了。
其次，是控制发布次数。天天发布会让主分支一片混乱，也会让测试人员疲于奔命。我们现在一般是周二和周四晚上进行功能发布，这样其他部门也会做好相应的配合。重要的项目和紧急的事务，可以进入紧急发布流程，但紧急发布流程不能常用，常用会让业务部门觉得再小的东西也可以紧急发一下。
再就是要有专业的SCM人员，管理分支和发布包，不要让测试人员或开发人员兼职，这样只会更乱。
解决线上线下环境不一致的问题，除了线下会建立独立的测试环境外，线上我们现在是用一台用户无法正常访问的服务器进行部署，域名是以.net结尾的（我们正式的域名是.com），这样也可以访问进行一些测试，当然，也并不能完全解决问题，如果有更好的经验，希望能和大家一起分享！：）
规范是团队协作的根本，没有规范的代码会让其他同事无法正常理解或花费大量精力去理解你的代码。再忙再紧，一周也要进行一次代码检查，把MODEL补充齐，把注释和说明补充好。
安全和性能是互联网公司的程序员必须关注的。团队中应该有专门研究安全的同事，把安全条例做为天条进行执行。普通的代码规范执行有问题可能请个下午茶就行了，但安全是不容解释的，必须严格处理。性能也是一样，不同的公司会有不同的配准。为了让你的应用服务器单台支撑百万以上的流量，.aspx.CS里的代码必须在500毫秒内执行完。
以上是一些正在实行的经验，环境是百人左右的技术团队，其中还有很多不足，希望能给大家一些借鉴。
[引用:http://www.cnblogs.com/soso/archive/2008/06/12/1218277.html]