面向过程谁之错？

本文部分文字引自http://www.cnblogs.com/lguyss/archive/2010/05/16/1736719.html，特此感谢！

首先，在下无意冒犯土星的狗狗，笔者也支持土星的狗狗的5步管理流程，换作笔者，也会按照这流程去管理的。引用过来，只是期望能在项目管理中，抛弃面向过程这一技术实践，换成面向对象，让世界变的更美好。

其次，笔者对此文是一改再改，删除了很多具有针对性的话语，其实本文的初衷只是想让读者明白，面向对象后，我们的项目会以什么样的形式展现出来，为什么这样的展现要比面向过程要好，出了问题也好修复等等。

 

1、每天的运营组晨会会在上午10点前进行，主要内容为：任务完成情况汇报、未关闭问题原因分析并跟进、系统问题较集中的功能模块重点讨论、对于开发组的整改日清列表。

 

面向过程中，经常会发现。A页面“换灯泡”的按钮未失效，而B页面的“换灯泡”失效了，所以B页面成了问题集中的功能模块。

面向对象后，只会发现所有“换灯泡”的按钮都失效了。

同时，

面向过程中，经常会发现，修改A功能后，把B功能修坏了。

面向对象后，绝对不会发现，修改A，把B修坏了，因为，有unit test。

 

 
2、对于系统用户每天都会提出各种各样的问题，运营组结合平时积累的一些业务知识进行判断，并有针对性的对开发组提出高标准，限期修改，避免更大的问题出现，并且对于实施 的负责人一票到底，不允许出现要求用户同一问题向两个人询问的情况出现。

 

面向过程中，随着时间的推移，这个过程式的代码由于补丁不断，会变得伤痕累累（行数的不断增加，爆炸式的if...else...嵌套）。当行数到达一定极限时，程序员就很难阅读，也很难在限期内修改掉最新的BUG。所以，经常能听到：为什么会加班呢？为什么修一个BUG要3天？

面向对象后，随着时间的推移，由于不断的重构，首先就能保证出现的问题绝对不是大问题。再由于面向对象强调松耦合，高内聚，一个函数只完成一个独立的功能，那么，程序员在修改起来，也只会面对不超过一屏的代码（相信这是很多公司的标准），维护也会变得十分轻松。

3、对于运营组内部管理，根据不同水平的成员和问题的级别分类，将紧急和棘手的问题交给业务技术水平高的成员负责，将重复性相对高的运维工作交给刚入职不久的员工负责，从而提出了问题日清的要求，保证系统稳定，提高用户满意度。

 

面向过程中，才会出现技术水平高超的程序员才能完成的问题。也只有面向过程才会有重复性的工作。

面向对象后，任何紧急和棘手的问题都会在架构阶段得以解决。笔者不赞成这样对于程序员的水平的评估：你不会socket，我会，所以我技术比你好。比较赞同的是：你写的函数编写时间短，运行时间短，占用资源少，代码量少，他人也易于阅读。

 
4、每周的周例会，运营组全体成员和开发组负责人都要参与，对于本周出现的重大责任问题进行剖析并追究开发责任人；对于重复出现的问题对运营组相关责任人进行批评，并找出负责修改此功能的开发负责人，进行考核；对于没有出现问题的模块和解决用户问题得到用户表扬的负责人，进行激励。

 

考核和激励每个公司自有标准。

5、每月月底，我会将EXCEL电子文档内的工作整理归类，将晨会和周例会的主要内容概况到一起做分析，结合系统问题提报平台导出的问题解决情况向客户做汇报，以此来总结一个月的运营工作情况。

 

同意,无论面向过程或者面向对象，汇报和总结都是必须的。

 

 

最后提一个问题：换一个灯泡需要几个程序员？

答案是：不需要程序员，调用灯泡类的换灯泡方法即可。