其实想写这篇文章很久了，但是一直都没有动手，今天不一下缺。
首先介绍一下背景：项目由两种语言来完成java和.net（非面向对象语言的可以掠过下文）。
今天再次听到两位同事（老员工）说老大要他们在设计文档中画流程图，而且要把整个系统的流程图画出来。心中一楞，看来流程图还真是个害人的东西。
首先从我自己负责的模块来说吧。我的工作是接别人的工作的，算是维护和改写吧。刚接手的时候不是很明白为什么一个方法会是600+行（一个类也就2-3个方法），想很久也没有想明白，于是在熟悉了流程之后，把流程图画出来，然后把大的方法分解成了小的方法。但是还是一个很大的类。再后来，日子比较清闲也看了一下重构方面的书，于是实验了一下，把大类们都分解成了各个职责明确的小类，（主要用到的方法是提取基类，提取公共方法等方法），于是将几个600+行的大类分解成了10个100-200行的类（当然还有部分方法放到了公共类库中，大约100行代码量吧）。在完成重构后，业务流程发生了一个很大的改变，需要将我负责的模块的业务逻辑进行很大的改动。本来以为这次的改动会让我很难受，孰料我竟然用了3个10行的左右的函数和一个if语句解决了这次更改（当然动手之前想了差不多半天），剩下的工作量都是和界面的搏斗。这是我第一次真切的感受到面向对象的力量。
其次是从我负责的整个系统的重构工作中看到的情况。以前的系统是由2个同事写的(其中一个以前是php的），但是我看到的代码都是一些500+行的大函数，很多时候我看到的是一个300+行的page_load函数。很多的代码是重复的，就算是在page_load函数里面也有重复的，也是可以提取共用代码的。我一直都想不通。直到后来，可能是看到了某个靓妹，突然脑充血想到自己以前负责鉴权重构的时候的过程，一切都明白了。
当时的过程是，我老大要求我将整个过程画出来，画得很细，大约有60-80个框的流程图，拧起来就是2～3斤的葡萄了。然后因为这个流程图是在详细设计的时候画的，所以我在写程序的过程中也就大致按照这个流程把整个鉴权过程写到了一个类中，最后我也写了一个600+行的类（唯一的安慰是，没有写一个600+行的函数）。
于是我得出了一个结论：在OO为主要编程语言的详细设计说明书中不应该出现流程图，取而代之的是时序图（其他的可能没有那么好）。（或者我们对在每一个流程中标志这个流程属于那一个类，好像有点扯蛋哦。。。）当然，你有可能会说在详细设计的时候就是应该这样子做的，如果你们公司的流程是这样的，我想请你写下具体的流程，因为我确实没有经历过这种公司。至于另外一种可能会说，一个类600+行，或者一个功能600+行的代码，是你们在做功能拆分的时候做的不够细，这一点我是承认的，但是功能怎么样分细，用对象的职责还是别的什么方法，也请赐教。
至于我为什么会有这样的结论了？主要是因为如果你可以画出一个时序图，你总得将一些职责分细，所以总的来说对于一个类承担的职责总会比以前的少了。而且，当你画时序图的时候，你应该会想一下类的构成。所以我们的类的职责就明确了一些，我们的类也就小了，腰也不酸，腿也不痛了。
但是，是不是流程图就一无是处了？我觉得倒不是，因为对于需求分析和概要设计这些需要对用户或者非技术人员解释的文档，流程图还是很简单明确的，特别是在做需求设计的时候。我们在这里遇到的问题只是因为我们把流程图直接细化copy到了详细设计之中。（可能你是纯化论者，说用例（user case）也很容易跟客户沟通，但是我确实见过不懂用例图，但是流程图还画得很好的客户）
又或者，这是不是七宗罪中的懒惰。。。。
欢迎交流意见。
