设计做到什么程度？

在TXX的设计Review会议上，WQX问我，我们的设计可以做到什么程度？
我说，钱多就设计的详细，钱少就设计的粗略。
他说，也许我们可以稳定到某一个程度，不论项目大小，钱多少。

我想，大家都体验到了UML为设计带来的许多好处，比如交流便捷，规范开发，还有就是强迫思考，强迫我们考虑“谁是谁”和“谁做什么”。

如何使用UML，Martin Fowler在《UML Distilled Third Edition》中做了很精辟的总结，我理理自己的思路，以飨大家。

在设计精细程度上，一般有三种用法：草图，蓝图和程序。

将UML视为草图，着重于沟通交流，在纸上或者白板上与一群人讨论，并不一定拘泥于UML的格式。我们不会讨论所有要写的程序，着眼点只在系统的部分或者某个层面。我们可以在几个小时的开发工作前，用10分钟交流下设计；或者用1天的时间，整理整理接下来为期两周的迭代。

这样的设计可能是非正式的，我们可以把白板上的照下来，把纸上的扫描下来，再加进设计文档。使用草图，也往往意味着我们会讨论一些可能的替代性做法。所以，Martin说草图的本质是“选择性”。

我觉着在YXXXX项目中，用的是这样的方式。我要求大家把接口定义出来，把主要的时序画出来，不论是在纸上还是在Visio上，已经画好还是现场画。我关心的接口有两部分，Java程序接口，主要是业务层接口，需要知道业务层暴露出哪些方法供别人调用；还有前后的数据接口，即DTO，我需要知道业务层的方法需要什么数据，会返回什么数据。我关心开发人员是否理解了调用顺序，以及开发人员的工作分配，即谁做哪个类哪个方法。

将UML视为蓝图，更倾向于“完整性”。我们关注于系统的整体结构，框架层次，必须完成大的设计决策。如系统是由哪些子系统/模块构成的，其间的联系是什么，层次如何分布，怎样限定层与层的通信，关键类的识别和关键方法的分配等等。

这时我们需要借助工具来完成，并遵循一些标准，比如命名方式，注释规则，画图约束等等。这样的设计一般比较正式，也可能是大多数项目所使用的。接下来，可能会继续细化，增加类的契约，方法的契约等等；也可能直接用来开发，更进一步的设计会在写代码前完成。

在TXX项目中，我们便用的是这种方式。我们识别定义了主要的类方法，但并未描述业务规则和异常，并未满足80/20法则（80%的方法和20%的类），对类和方法的描述也不是十分充分。而在实际开发过程中，蓝图更多的起指导作用，约束力比较小。

蓝图与草图的主要区别在于：草图强调信息通讯，而蓝图强调无所不包；草图具有探索性质，而蓝图是定稿。

如果在蓝图的基础上继续设计，那么写代码的工作也就将越“无趣”；甚至，如果工具支持的话，我们可以在UML中完成代码。MDA（模型驱动架构）就是基于这样的思路。将UML视为程序语言，就需要可以把设计人员画的图直接生成为代码，将写的说明性文字生成为注释。

目前这种方式我只是听说过，还从没有见过。

对于持有第一种视角的人来说，UML中最重要的是图；而对于后两种观点，UML最重要的是本质（分析方法、设计方法）。

而对于概念（概念是OO的核心）理解来说，也会有两种观点：软件观点（software perspective）和概念观点（conceptual perspective）。

持有软件观点的人的设计，任何UML元素（包、类、关系等等）都可以对应到软件的实体中；而持有概念观点的人，UML元素则对应到业务领域中的概念。

从程序员成长的设计师可能更容易具有软件观点；而概念观点更容易为业务领域专家所有。

回到我们的问题上，需要将设计做到什么程度。程度必然与衡量有关，而衡量就必须有标准。通过项目的积累，我们会逐步完善这个衡量标准。

排除设计观点的差异，忽略成本因素，与设计相关最直接的因素是：时间，作者（设计人员）和读者（开发人员）。

毋庸置疑，时间决定了设计的程度。不同的项目有不同的时间限制，而资源也是有限的，或许我们可以根据不同的项目类型，制定不同的设计标准。

设计人员的能力决定了设计的质量，也许会因经验不足，导致开发阶段风险与成本上升。提高设计能力是我们持久的目标。

不同的开发人员，对设计的要求应该是不同的。如果是成员之间比较熟悉的团队，草图的方式是最便捷和有效的；如果开发人员水平参差不齐，使用蓝图不失为一个好办法；而开发人员仅仅是传说中的“蓝领”，那么我们不得不将设计视为程序。

除此，还有很多重要的因素，如软件开发的生命周期，需求稳定程度等等。

最后的结论是，设计可能无法稳定到一个程度，也许WQX的意思是我们可以稳定到某一种质量。

路上听说一个电影很好， 于是我回来在电驴上搜索：
麦兜响叮当。
结果找不到。半个月之后偶然听我一个同学告诉我， 是麦兜响当当。

那天忽然要用到=>， 但是忘了怎么用。
于是在MSDN搜索lamda表达式。
只有一个结果还还不相关。
后来意外的注意到是lambda。

要找以前看的一个帖子， 但是忘了地址。
就百度：
你觉得你是宋思明？
你认为你是宋思明？
你感觉你是宋思明？
结果都没有找到。
很郁闷。

一周之后我找到那个帖子了， 题目是：
你以为你是宋思明？

加条件的时候，
应该用80%还是百分之八十还是八成呢？
应该用20%还是百分制而是还是二成呢？
应该用方法还是method呢？
应该用类还是class呢？
随便拼拼凑凑这已经三十六种组合了。

希望你能想明白搜索引擎里的关键字意味着什么。

额外说下我在一家公司曾经被一个领导批评过一次。
他这么说的：
“你是个批评家， 你把我的设计批评的一文不值。很好。 可是， 你的建议呢？ 我应该怎么设计？ 符合你心意的完美设计是什么样的？ 你觉得我的不够灵活， 那你的灵活解决方案呢？ 你觉得我的设计过分复杂， 那么， 你的简明方案呢？ ”

还有， 今天一件事情让我很感慨。
做性能测试， 对方说：
“看下瓶颈在哪里。 如果是web server的配置不够， 那我们就加一台webserver 服务器。 如果是数据库服务器的配置不够，那我们就给数据库服务器升级”。
我说， 很奇怪。 我对数据库和IIS都不是很熟悉， 所以问个问题。 既然同样是服务器配置不够， 为什么你一个考虑是加机器而另一个考虑的是升级配置呢？ 是不是两者对配置的要求不一样所以不得不分开考虑？
他沉默了下， 告诉我：
没考虑那么多。 只是因为数据库的license很贵~

还有我有个很大胆很冒犯的猜测， 我觉得你一定很喜欢linux。

我想这个不是项目钱少的问题，应该是你那个所谓的“老大”的能力问题吧。

嗯，归根到底是因为没有钱，所以请不到很有能力的老大~

另，我搜到的有关80/20/UML的信息是这样：利用UML的20%就可以为80%的问题建模。
不知道这是不是LZ原话的出处。

To ur_cheeky：
淡定~ 大家看问题的角度不一样，实际面对的问题也不一样。如果你有什么好的观点，也希望能够写篇帖子，拿出来大家一起学习。

@Arthas

>这个。。 我只能膜拜您的阅读速度~ 要是我打死不敢这么和人家诡辩。 为什么呢？ 因为我确确实实不可能在两个帖子之间读完三万条记录~

我想我们在使用搜索引擎时，都是带着某些问题去检索、去“听说”，然后再在结果中查看那些与我们需要了解的问题相关的信息，来寻找答案（不一定都是正确的）。

给你举个例子吧：

某人上“百度”去搜索“猪头”，他一定是带着某些问题去“听说”的。如果这个人真的没有带着问题去“听说”，那这个人的问题就比较严重了。

当他“听说”出很多的条目结果后，在不改变搜索条件的情况下，把每一个条目结果都查看了一遍，那这个人的问题就相当严重了，因为他真的已经是“猪头”了。

希望你能读懂我给你打比方。

@Arthas

帮腔的得先做好功课再出来说话。

>我记得在学校的时候去过一公司实习， 写一段asp.net代码， 访问数据库。 然后对于防sql注入很头疼。 问当时的老大， 咋弄？没弄过？　老大说了句：敢给你做的项目，　都是不值得去防ｓｑｌ注入的。我说为啥？　他说，　钱少。

首先不是别人说的都一定是正确的，自己先要动动脑筋，亲自实践，再下结论。否则就成了“人云亦云”、“不懂装懂”了。

防止“SQL 注入”简单有效的就是采用“参数化的SQL命令”来访问数据库。我想这个不是项目钱少的问题，应该是你那个所谓的“老大”的能力问题吧。

无知并不可怕，知道自己的无知，就知道自己有了“茶具”，是大好事。

可怕的是无知还不知道自己的无知，那可就“杯具”了，是大坏事。

楼主好像“答非所问”呀，在打“擦边球”呀！

首先你解释的“80%的方法和20%的类”，它和著名的“80/20法则”好像没有一点关系呀！

其次你对“不给钱做软件就没有设计了”的回复完全就是“脱体的零分作文”，根本没有提到“钱和设计的关系”！

综上所述，你的回答只能给“零分”，但还是非常感谢你的回复。

>不给钱做软件就没有设计了
很多公益项目是非营利性的，但是也在花钱，花的是投资人、赞助商、纳税人的钱。
而有些，为了个人、群体兴趣的，比如大部分的开源，项目的确不花钱，但是你不能说没有成本，因为有人投入就会有成本产生，只是此时的成本可能不以金钱来衡量，比如时间。

>80%的方法和20%的类
80%的方法和20%的类，在这里是有上下文场景的。在分析阶段结束，我们需要找到主要的动作和概念。这些动作将来会转化为方法，80%的动作被找到，意味着系统的行为基本上是可控的。在所有的系统动作中，分析结束后找到其中的80%，这是80%的来源。
而在设计阶段，将概念套用在架构或模式上转化为类后，这些直接由概念生成的类（往往是实体类、或者BO），只占系统总类数量的20%。这是20%的来源。
>我们识别定义了主要的类方法，但并未描述业务规则和异常，并未满足80/20法则（80%的方法和20%的类），对类和方法的描述也不是十分充分。
我的意思是，我们在分析设计阶段做的不够细致，在概念、动作和约束上还有很多遗漏，这些工作最后在开发阶段完成。
那么，需要不需要做细致，能不能做细致，则由很多因素制约，如战略目标、项目规模、开发方法、人员能力、人员之间的熟悉程度、时间压力、质量要求、客户群等等。而对一个以营利为最终目的项目来说，这些因素最终都会以成本的方式体现。
因此，我现在还是认为，钱多就设计的详细，钱少就设计的粗略。

很久没有地方争辩狡辩诡辩各种辩了。憋死我了。
你这是给了我一个机会啊， 感谢下先。
说下我的看法：


>>楼主别把无知当有知！照你的话讲，不给钱做软件就没有设计了，真是可笑至极！
我也觉得很可笑。 然而很遗憾， 虽然我们不愿意承认这个事情， 但是有的时候， 还真是这样！ 虽然楼主虽然没有提到这个说法。
哎， 我也觉得做软件这点挺悲哀的。delphi的fans那么多， 最后还是完蛋了。 C#被骂的那么惨， 结果现在还是横行天下让很多delphi的fans不得不为了生存而来学习。 没办法。 微软有钱。直接把你老大挖过来。

>>软件设计能够做到什么程度是与采用的软件开发方法和人员能力有关。楼主竟然能说出于项目成本有关，真是长见识了，楼主真是“有才”呀！
很遗憾， 软件能设计到什么程度还真的就未必和能力成正比。 尤其是前几天看那个《梦断代码》， 真的是， 内牛满面啊~~
我记得在学校的时候去过一公司实习， 写一段asp.net代码， 访问数据库。 然后对于防sql注入很头疼。 问当时的老大， 咋弄？没弄过？　老大说了句：敢给你做的项目，　都是不值得去防ｓｑｌ注入的。我说为啥？　他说，　钱少。

>>楼主还讲什么“80/20法则（80%的方法和20%的类）”，听说过“80/20法则”应用于推销学、企业管理、人力资源管理、人际关系处理等，还真没听说过“80/20法则”像你这样解释的
引用我一个朋友说过的一句话：“没见过吧？ 那就让你见见看~”

>>按照楼主的提示，在Google上去听说了一下“80/20  uml”，的确找到了3万以上的词条，但就是没有找到楼主提到的“80%的方法和20%的类”呀！请教楼主是在哪个Google上“听说”的？！烦劳给摘抄片断看看！
这个。。 我只能膜拜您的阅读速度~ 要是我打死不敢这么和人家诡辩。 为什么呢？ 因为我确确实实不可能在两个帖子之间读完三万条记录~

额外说下这位同学的ID似乎有点。。 不和谐。:~
还有楼主也不是圣人。
最后说下上面几条有的是争辩有的是诡辩，　请这位同学不要断章取义～
:-|

按照楼主的提示，在Google上去听说了一下“80/20  uml”，的确找到了3万以上的词条，但就是没有找到楼主提到的“80%的方法和20%的类”呀！

请教楼主是在哪个Google上“听说”的？！烦劳给摘抄片断看看！

搞技术最需要“实事求是”，好像“听说”一下你就有理了，我倒要看看你能听说出什么不一样！

告诉我，80%方法和20%类都是如何从UML来的？我倒很想再“听说听说”！