hrmai

如果都像你这样，那么前面人做的项目出了问题又没有注释，你来修改，本来几分钟搞定的事非要浪费半天甚至更长时间，总之这是习惯！！！

彪悍的搞死搞残所有人，不解释。

楼主这个观点应该是从重构这本书来的吧 这本书说函数尽量简短 有自解释的功能 这点我很同意 有些人跟我说你把函数写个注释吧 开始我也想骂人 我都已经精简到三行了还看不懂 后来我觉得写程序就像写文章 要让任何人任何时候都能看懂，即使是一个不会编程的人，于是不但写注释 而且一行代码写三行注释 代码应该写的尽量简单 逻辑尽量清晰 注释写的尽量详细 即使是废话连篇接手人也能看得懂 关键不是写不写注释，关键是又长逻辑又混乱的程序，又没有注释，这种东西才真的很操蛋

如果是设计阶段： 在现实的业务沟通中，活动图（带泳道的流程图）可以很好的反应业务的走向，以及数据的流动。这个阶段关心的是业务和需求。 如果是开发阶段： 要了解对象的生命周期，调用关系，使用时序图可以更好的反应出重点。 其实并不是流程图不适应oo.而是要明确UML中的图应该在什么场景中使用，才能事半功倍。

画不画流程图跟是不是OO、类代码有多少行没啥关系。LZ举的例子更多的是重构的威力！对于大的功能，一般一个流程图是不够的，还要有小的子功能流程，显然就对应于单一职责的子函数了。

[quote]TYR： 哈 我们是小公司 啥东西都是自己弄，但是我坚持画流程图、序列图。自己思维不清晰的时候，画下流程图、序列图，是对自己思维的整理，同时也能很好地帮你改进不足。 这样做的另一个好处是别人能尽快接手你的工作，抽调过来的同事看系统架构、功能描述、流程图、序列图和代码里面的注释就可以直接帮你干活了。理解能力差点的也没有关系，对照着图来跟对方说上一遍也很快能让对方明白。 PS：序列图和流程图是两码事，目前我是两者都需要。[/quote] 可以再明确一点吗？

[quote]Old： 一开始走的是面向过程的思路来写程序，那难免会出现代码行在600+以上的大方法。 现在拿到的项目，尤其是WEB的项目，很少有团队或个人是以OO的角度来设计并实现的。这里面很多的历史也许大家或多或少都了解些。 这是进步还是倒退？[/quote] 是不是我们背负和很多或者我们得到了太多而不想去改变？

[quote]徐少侠： 时序图是把类之间的调用关系表达得最直接的一个图。 不过客户似乎对这种图还一时无法接受的，毕竟这个图里展现太多代码级别的细节了。 因此如果能碰到一个喜欢看时序图的用户，那真是太幸福了。 所以面对最终用户的时候，还是用例图管用一点。只是也不要给他看太细化的用例图。 [/quote] 时序图不应该作为和用户交互的东西，用例图或者流程图其实是一个很好的东西。现在我遇到的很多情况是我们根本没有OOD

@我是你的猪 [quote]我是你的猪：流程图是正确的.其实很多代码都是先有"600+行的代码",再重构成"10个100-200行的类"的.没有人能够直接写出每个方法就2~3行的代码出来.都是靠重构.[/quote] 问题是很多时候我们是later=never

一开始走的是面向过程的思路来写程序，那难免会出现代码行在600+以上的大方法。 现在拿到的项目，尤其是WEB的项目，很少有团队或个人是以OO的角度来设计并实现的。这里面很多的历史也许大家或多或少都了解些。 这是进步还是倒退？

回复中亮点不少。。。。 其实我部分赞同楼主的观点，个人感觉好的结构以及命名的确会让注释显得多余，不仅写着费事看着也显得费事，有时候看一些注释完全就是把方法名翻译成汉语，感觉没什么用。 但是注释的确是十分重要的，好的注释会是一大笔财富。 最后，发表评论说明自己观点就好，言语中伤就不好了！

流程图是正确的.其实很多代码都是先有"600+行的代码",再重构成"10个100-200行的类"的.没有人能够直接写出每个方法就2~3行的代码出来.都是靠重构.

时序图是把类之间的调用关系表达得最直接的一个图。 不过客户似乎对这种图还一时无法接受的，毕竟这个图里展现太多代码级别的细节了。 因此如果能碰到一个喜欢看时序图的用户，那真是太幸福了。 所以面对最终用户的时候，还是用例图管用一点。只是也不要给他看太细化的用例图。

流程图是面向过程时代的伟大利器。 但是到了面向对象的时候，他的作用仅仅能充分体现在一个函数的内部。 因为他无法清晰体现类和类之间的关系 我的推荐是可以尝试逐渐使用UML进行设计与分析。 从最基本的类图开始，然后是状态图、协作图、时序图等等。 UML是一个经典的废物。因为能熟练使用它的团队并不是很常见。 但是作为个人学习，他对程序员的帮助不亚于九阳神功。 有了一定的UML经验打底，天下武功的心法就都一样了。

太随意了....我遇到过 下面不听话 ，没有写代码的代价..

哈 我们是小公司 啥东西都是自己弄，但是我坚持画流程图、序列图。自己思维不清晰的时候，画下流程图、序列图，是对自己思维的整理，同时也能很好地帮你改进不足。 这样做的另一个好处是别人能尽快接手你的工作，抽调过来的同事看系统架构、功能描述、流程图、序列图和代码里面的注释就可以直接帮你干活了。理解能力差点的也没有关系，对照着图来跟对方说上一遍也很快能让对方明白。 PS：序列图和流程图是两码事，目前我是两者都需要。

好文。

和需求分析师有关系。 现在业务人员比较能接受流程图了，进出各种单位也经常能看到流程图。 但分给技术人员之前，需求分析师本应该做好桥梁的作用，但懒得做，结果就把流程图直接照搬给架构师。

[quote]Liu liu： 楼主假设了一种完美无暇的源代码（类结构、函数名称、设计、细节逻辑都完美到无法挑剔）。 作为一个专业人士，应该意识到这是不存在的。我们经常用20%时间来写新代码，用80%时间来修改(重构)旧代码，别人写的，或者是自己写的。[/quote] 这位兄弟说的很符合实际。 而博主写的这篇显然偏离了自己的出发点，让更多人认为你是在标榜自己

哗众取宠! 如果你正在写临时性代码呢，或者写作为底层核心类的公共方法呢 亦或是客户指定要求做FxCop或者StyleCop呢？