大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
录制于：
从实践出发探索架构的本质
受访人 潘加宇 温昱 采访人 Jason Lai(赖翥翔) 发布于 2008年2月1日 长度 00:41:46
概要
架构是什么？架构设计就是设计接口吗？如何成为一个好的架构师？架构种类很多，开发人员如何选择？如何划分用例的粒度？架构设计过程中一定要引入很多的文档吗？如何将需求转化成一个良好设计的架构？UMLChina首席专家潘加宇和资深咨询顾问温昱和读者分享了他们对这些让人迷惑的问题的看法。
个人简介
潘加宇，UMLChina首席专家，北京大学硕士，1999年创建UMLChina，研究需求和设计技能，2002年以“聚焦最后一公里”的方式，对外提供UML需求和设计的技术指导和训练服务。
温昱，资深咨询顾问，软件架构专家，著有《软件架构设计》，松耦合空间网站创办人。作为资深咨询顾问，已为众多知名企业提供了卓有成效的培训与咨询服务。
致谢：感谢SD2China大会提供采访支持，感谢浪潮软件质保中心副主任和架构社区编辑孙向晖提供智慧支持！
架构是什么？架构设计就是设计接口吗？如何成为一个好的架构师？架构种类很多，开发人员如何选择？如何划分用例的粒度？架构设计过程中一定要引入很多的文档吗？如何将需求转化成一个良好设计的架构？UMLChina首席专家潘加宇和资深咨询顾问温昱和读者分享了他们对这些让人迷惑的问题的看法。
个人简介
潘加宇，UMLChina首席专家，北京大学硕士，1999年创建UMLChina，研究需求和设计技能，2002年以“聚焦最后一公里”的方式，对外提供UML需求和设计的技术指导和训练服务。
温昱，资深咨询顾问，软件架构专家，著有《软件架构设计》，松耦合空间网站创办人。作为资深咨询顾问，已为众多知名企业提供了卓有成效的培训与咨询服务。
致谢：感谢SD2China大会提供采访支持，感谢浪潮软件质保中心副主任和架构社区编辑孙向晖提供智慧支持！
潘加宇（以下简称潘）：大家好，我是UMLChina的潘加宇，很高兴能有机会和大家在这里交流。
温昱（以下简称温）：大家好，我是温昱，现在是专门来做这个软件架构的培训和咨询，是去年的时候从公司辞职，专门来做这一块。之前涉及的行业比较多，从金融到航空领域到操作系统，之后涉及到这个电信、多媒体，包括最后我服务的一家企业是做平台。从去年开始专职做这个架构的培训和咨询之后，也积累了一些相关的客户，大家对我的这个培训和咨询的反馈，使得我更有信心把这块做下去，谢谢大家。
温昱（以下简称温）：大家好，我是温昱，现在是专门来做这个软件架构的培训和咨询，是去年的时候从公司辞职，专门来做这一块。之前涉及的行业比较多，从金融到航空领域到操作系统，之后涉及到这个电信、多媒体，包括最后我服务的一家企业是做平台。从去年开始专职做这个架构的培训和咨询之后，也积累了一些相关的客户，大家对我的这个培训和咨询的反馈，使得我更有信心把这块做下去，谢谢大家。
温：我来说一下个人看法，整个软件架构这个领域还是很年轻，在业界当中关于架构的定义个数很多。我们在业界，也就是说是实践者，我们会为它归类，第一大类我把它叫做结构派，在我的书籍上也会提到；第二大类叫决策派，第一大类基本上可以说软件架构等于组件加交互，传统的说法是架构等于组件加交互，加约束。伦巴斯先生为这个经典的定义又加入了最新的元素，他说架构等于多个结构，那么每个结构等于组件加交互，加外部可见属性，这个也是在我们业界当中呢，架构的定义认可度最高的一块。第二种类型是决策派，他的典型就是RUP提出的这个定义：软件架构是一系列有层次的这个决策，它包括了哪些种类等。这是两个流派，但是这两个流派绝对不是矛盾的，我们实践当中的确如此，或者说从这个实践的主体、客体角度来解释一下，那组成派就是关注实践的客体，软件本身；那决策派关心的是软件主体、架构师，这两个概念本身是非常好的统一的。请加宇谈一谈。
潘：温昱这些知识应该比我要丰富得多，因为我只要关注的是需求和设计的这个技能和细节上面，架构对我来说是比较宏大的一个概念，但是我记得Martin Fowler曾经在书里面，对架构模式书里面说，架构这个词是最容易混淆的一个东西了。架构是什么，不同人有不同说法，这个我们很多公司里面都有架构师，也有接触过很多架构师头衔的开发人员，但有的实际上就是部门经理，有的人是项目经理，喜欢自称架构师。所以这个概念是比较宏大的，那我在我理解来说，架构应该是一些对某个软件的类型来说，比较稳定的一些东西，他是从很多个项目里面提炼出来，就像我们这个人，还有那个脊椎动物都有骨骼一样，你不管人怎么样，长得怎么样，里面的骨骼的机制是一样的，那这些东西可能跟具体的一些项目是没关系的。那正是因为它没关系，所以一旦我们一个团队选定了一个架构之后，我想这个架构上面的变化就不应该很大，而是应该重点就把这个精力放在业务上面，这是我对这个架构的看法。
潘：温昱这些知识应该比我要丰富得多，因为我只要关注的是需求和设计的这个技能和细节上面，架构对我来说是比较宏大的一个概念，但是我记得Martin Fowler曾经在书里面，对架构模式书里面说，架构这个词是最容易混淆的一个东西了。架构是什么，不同人有不同说法，这个我们很多公司里面都有架构师，也有接触过很多架构师头衔的开发人员，但有的实际上就是部门经理，有的人是项目经理，喜欢自称架构师。所以这个概念是比较宏大的，那我在我理解来说，架构应该是一些对某个软件的类型来说，比较稳定的一些东西，他是从很多个项目里面提炼出来，就像我们这个人，还有那个脊椎动物都有骨骼一样，你不管人怎么样，长得怎么样，里面的骨骼的机制是一样的，那这些东西可能跟具体的一些项目是没关系的。那正是因为它没关系，所以一旦我们一个团队选定了一个架构之后，我想这个架构上面的变化就不应该很大，而是应该重点就把这个精力放在业务上面，这是我对这个架构的看法。
温：看来InfoQ还是很专业。的确，我和客户接触这么多呢，我发现非常非常多的这个开发出身的程序员，往往是抱以这种观点，我这里还会有相关的案例，那我这个客户还是微软的合作伙伴，他负责架构，后来也在咨询我这个问题。那温老师，您说是不是我要把这个架构设计好，是不是直接要考虑哪种设计模式呢？我们说这里面是有误解的，直接考虑设计模式问题很大。设计模式也好，接口也好，是架构设计成果当中非常关键的部分。但是我们整个架构设计的活动，前期还有更加关键的因素。或者这么说，从我的培训来讲，我关注三个环节，依次，首先是从需求向架构过渡这块，这个环节呢，我们业界有一些具体的说法，包括国外的这个统计，说架构师面对的需求有很多需求是衍生需求，系统分析师未必能够看到这些需求，甚至直接有统计数据出来，这个一般的做出来的需求和我们架构师面对的需求，这个数量是不在一个数量级之上的，于是我们比较强调从需求向架构设计过渡这个环节。再比如说，这个环节当中会关注一个问题，就是说需求的数量非常的庞大，那么我们架构师没有足够的时间，把所有的需求分析透彻，这时候怎么办呢？也是我们从需求向架构设计过渡当中非常重要的问题；第二个环节是概念架构设计，这个词汇本身，大家可能会觉得生疏，但是整个业界、国际业界都是这么做的，概念架构设计，我这里提一点，就是这个架构模式。架构模式什么时候引入的？和设计模式的引入绝对不在一个层面。所以说概念性架构还是很关键的，我这里已经提到了架构模式的一个典型。
那么到了架构设计的后期阶段，才会考虑这个接口以及我们的这个设计模式等等，我们把它叫做细化架构设计，这一块工作量自然是最大的，也会用到业界，非常标准的这种多视图的设计方法，这是谈了对刚刚的这种业界比较流行的这种架构设计，就是设计接口和设计模式，这样一种观点。我们强调比较体系化的方法，需求进，架构出，是每个架构师非常非常关心的一个这种结果。那么中间怎么做？大致呢我的看法是三个环节相相环套。
那么到了架构设计的后期阶段，才会考虑这个接口以及我们的这个设计模式等等，我们把它叫做细化架构设计，这一块工作量自然是最大的，也会用到业界，非常标准的这种多视图的设计方法，这是谈了对刚刚的这种业界比较流行的这种架构设计，就是设计接口和设计模式，这样一种观点。我们强调比较体系化的方法，需求进，架构出，是每个架构师非常非常关心的一个这种结果。那么中间怎么做？大致呢我的看法是三个环节相相环套。
温：需求设计，设计在整个国际生产层次，架构设计和详细设计，这种我谈得是架构设计的内部的一些工作，也就是说呢，外部的朋友看到架构师仅仅是设计出来了架构，但我们架构师到底是怎么做得，那我们通过这种整个业界最佳实践的这种总结，包括我们个人的10年的经验的这种加入，最终我们认为架构师所做的工作会包括大致三个环节。
温：这个问题在内训的时候也经常问到。第一个环节从需求向架构过渡，不产生整个企业可见的工件，它会反应在这个架构设计文档当中的一项，就是需求的权衡考虑；那第二块呢，概念架构设计依然，它的工件本身呢，不是说正式的工件，有个概念架构设计文档，虽然我们会用这个概念架构设计的成果去做这个像投标的工作啊，但是他本身是没有专门的这个工件产生的，也是反应在架构设计文档当中，比如概述部分。倒是这个第三个阶段，细化架构设计，它产生的文档是真真实实的这种，特别是居于多视图的架构文档。
潘：那我对这方面的话，就是架构方面我了解的并不是很多，主要还是关注技能上面.但还是我刚才那个观点就是说，很多还是细节上的问题，宏观上面的话，我们把握的是一个问题，但是很多时候出问题是在细节上。所以细节上的话，温昱在这方面有什么看法呢。
潘：那我对这方面的话，就是架构方面我了解的并不是很多，主要还是关注技能上面.但还是我刚才那个观点就是说，很多还是细节上的问题，宏观上面的话，我们把握的是一个问题，但是很多时候出问题是在细节上。所以细节上的话，温昱在这方面有什么看法呢。
温：加宇提到一些很具体的问题，我这里说一个例子。那我这个客户是微软的合作伙伴，他在做架构的时候呢，我跟他说你早期要考虑一个很具体的问题，就Server的问题，你不要认为你做得是一个整体的应用，你要考虑，你的这个用户的这种数量这么大，你整个系统未来是一个很大的系统，你怎么样在最早期的时候关注把整个系统划分成不同的硬盘，而不说一大块硬盘。包括后面他会涉及到一个很具体的问题，他说我怎么样管理我的这个用户状态，他会是做社区，他的用户呢，他告诉我两大类，第一类微软的客户，MSN的这个注册用户；第二类是我自己社区的注册用户，他会问我这个用户的状态怎么管？我说我之前不是跟你说了吗，你要考虑Server的问题，你要考虑是不是有些问题可以抽取出来，现在你这个上下文有很重要的一个可以利用的一个技术平台，就是微软的MSN，已经做得非常不错了，那么你会问自己一个问题，为什么你要亲自来管用户的状态？我给他的建议是让微软帮你做，怎么帮？他已经帮你了，微软整个MSN Messenger，它会把用户的状态管理起来。那么你可以做一个非常非常细节的调整，我在用户注册的时候，必须要求用户提交MSN的帐号，最终你做用户状态管理的时候，只需要做一个封装，MSN有专门的这个Notification Server，就是管理用户状态的，是实时的管理，你封装起来，你是他的合作伙伴，一定会非常完善的把这个状态管理起来。的确，加宇说得很对，每个层次的工作都有很多这个细节的工作，包括架构设计，架构设计虽然是解决很宏大的问题，但是有非常非常多的细节，也会依赖我们架构师的经验把它解决好。
那我想提一个问题，就是说在架构设计这块呢，好像刚才谈到的是一个自顶向下的这种方式，那其实就是另外在社区里边，还有另外一种事件是自底向上的，就是说把这个设计或者软件从一点一点这些特性给它堆砌起来的，那二位怎么看这样的这个设计方式呢？
潘：根据我理解的话，就是说自底而上、自顶而下都是要的，就是说关键还是那个两种怎么分工。这个顶上的话，这个分以前我们分是怎么分，就是说功能分解的话是越分它越细的，然后最后一直分到很细微的一面。为什么要分？本来计算机本身一大块那个运行的更加流畅，为什么要分？是人脑搞不定，所以就要分，那么就分呢，那架构师就用那个，首席的架构师分成一大块、分一小块，小块再由自己的架构师再分成更小块，那总是功能分解的方式。那现在就是说可以这样分，按照高焕堂老师这个理论就是说应该是越分越复杂，分的话，就是把中间的架构变成接口，然后各个接口的地方完全由专业化的厂商去做这个具体的实现，他可以做很多种实现，将来就是采用一种越分越复杂。就像一个电脑一样，组装电脑那个厂商用联想，卖不了多少钱，他赚不了多少钱，但规模大了也能赚钱，但是真正的钱都被里面越分越细的那个专业厂商，像Intel给赚走了，这是自顶而下的分法。我们说这个有点像我们社会制度里面的，你要有那个宪法一样，宪法并不管你具体怎么做，但它有宪法，然后你具体怎么做呢？由下面各个区、各个人来做，那自底而上也是非常重要的，就是说本来你软件应该怎么组织，你用架构师头脑来预测，这个是很危险的事情，那本来应该是个自主制的，然后慢慢地自底而上的上去，这两个是缺一不可的，这是我的看法，看看温昱的看法。
温：之前也会和朋友聊到这个软件行业，特点到底在哪里，到底和哪个行业最像，这个朋友呢，他的观点呢，我和大家分享一下。那这个朋友说，软件行业和写小说最像，因为会和每个生活的领域相关，我们没有办法类比汽车行业，很多软件专家思考这个问题，汽车行业这么复杂，那我们软件行业哪一天才能做到像汽车行业这样好。但是我这个朋友的观点很到位，会和每个行业结合，于是我们的这个自顶向下以及自底向上，这种做法有它特定的领域，当我们解决这种商业问题，那这种信息化的系统，这时候自顶向下非常的合适。换一个领域，硬件密集型的，大量的具体硬件，那么这时候你可以考虑自底向上，把很多的这个设备分装起来，包括风险的问题，这个设备到底能不能被我软件控制起来呢？甚至会涉及到我们的硬件问题，这是自底向上的一个特点，有很多底层的危险性。那我的职业生涯当中非常有幸，也参与了这个航空领域专用操作系统的研发，那在这个操作系统领域呢，整个业界做法基本上是第三种做法，从中间向两边，为什么？直接封装底层，封装出来什么标准没有规划，自顶向下，依然还是有问题，没有基础，因为离硬件还很远。那操作系统这个行业比较好的一种做法，自中间向两边，先规定我们的这个操作系统的这个SysCall，那你会提供一个怎么样的一个虚拟机，那我们说操作系统很多观点，虚拟机观点，进程管理观点等等。于是我也会提到第三种是在不同的领域，所以说具体是自顶向下，还是自底向上，还是从中间到两边等等适用的系统，我个人看法。
温：之前也会和朋友聊到这个软件行业，特点到底在哪里，到底和哪个行业最像，这个朋友呢，他的观点呢，我和大家分享一下。那这个朋友说，软件行业和写小说最像，因为会和每个生活的领域相关，我们没有办法类比汽车行业，很多软件专家思考这个问题，汽车行业这么复杂，那我们软件行业哪一天才能做到像汽车行业这样好。但是我这个朋友的观点很到位，会和每个行业结合，于是我们的这个自顶向下以及自底向上，这种做法有它特定的领域，当我们解决这种商业问题，那这种信息化的系统，这时候自顶向下非常的合适。换一个领域，硬件密集型的，大量的具体硬件，那么这时候你可以考虑自底向上，把很多的这个设备分装起来，包括风险的问题，这个设备到底能不能被我软件控制起来呢？甚至会涉及到我们的硬件问题，这是自底向上的一个特点，有很多底层的危险性。那我的职业生涯当中非常有幸，也参与了这个航空领域专用操作系统的研发，那在这个操作系统领域呢，整个业界做法基本上是第三种做法，从中间向两边，为什么？直接封装底层，封装出来什么标准没有规划，自顶向下，依然还是有问题，没有基础，因为离硬件还很远。那操作系统这个行业比较好的一种做法，自中间向两边，先规定我们的这个操作系统的这个SysCall，那你会提供一个怎么样的一个虚拟机，那我们说操作系统很多观点，虚拟机观点，进程管理观点等等。于是我也会提到第三种是在不同的领域，所以说具体是自顶向下，还是自底向上，还是从中间到两边等等适用的系统，我个人看法。
温：从需求向架构过渡，实际上这个很巧，是我明天演讲的一个话题，我在演讲当中也会举一个案例，那我提一下。这个案例是我特意设计的，因为我发现这个分层架构大家怎么用的，用来用去，展现层、业务层、数据层这种方式。我们说呢，架构模式不是拍脑袋出来的，也不是说直接照抄的，我们的系统到底有什么样的特点？这时候你要考虑它到底是什么样的分层架构，到底分几层。那我们做平台的时候要做七层架构，我这里案例当中呢，它的背景是压缩，背景是压缩，我们要做压缩系统、压缩工具，这时候在这个内训的时候呢，很多的学员呢，也会做出来使用经典的三层架构出来。最终呢，实际上我们培训的目标是要告诉大家，先分析后综合，架构模式是分析出来的，不是拍脑袋和照抄过来的。你去分析我的系统会涉及到什么职责，最终架构模式会把这些职责非常好地、非常有秩序地这个组合起来。这里提到一个观点，提到一个综合，做我们的这种架构模式的规划。其他方面呢，时间关系也不便展开。听听加宇的意见。
潘：实际上我能谈的就是说这个从需求往设计方面走，那这里面经常会有很多误解，就是说很多开发人员觉得我只要学那些设计的技术就可以了，比如说设计模式、对象分析的思想等等。但实际上这里面真正的瓶颈不是设计的技术，也不是建模技术。你要做好，实际上你需求是问题域，相当于提出问题，相当于出题。那我们的这个设计相当于把那个题目给做了，做到这个需求，满足需求的这个结果，那这本身的话，从问题跳到解决方案本身它是鸿沟，有一道鸿沟，这鸿沟计算机是无法帮我们推导的，所以才需要开发人员来推导，而鸿沟下面是可以推导的，你说现在的模型，你自动，像有些嵌入式的系统，他们状态以及模式，就直接就执行了，他不会有人工编码的，因为人工编码会引进危险的。那也就是鸿沟下面的这部分，就是说跳到解决方案之后的部分，是可以计算机自动过渡的，难度在于就是说如何从问题跳到第一步这个解决方案，这部分只能靠我们人脑。那么这个人脑只有我们的系统分析原理，用架构师的大脑。他一方面要具备业务知识，第二方面要具备这个建模的技术，你要掌握一种建模技术，要么是面向对象的，要么是以前的结构化分析和设计都可以，这两个都可以。但是想想最终的瓶颈，我认为还是在这个业务知识上面，你说对象基础你掌握到一定程度，它里面的原则都知道了，那对象基础里面的原理、原则、模式，原理不就那么几条吗，原则也就十几条，模式上千个，这些都融会贯通就没有问题了。但实际上即使你掌握了原理，也没用，为什么？你怎么面对对象分离变化？那这个口号都会喊了，但实际上真正的难点，真正的细节上的难点，你怎么知道那个是变的，那个是不变的，那你必须要对业务有一个很透彻的了解。所以很多开发人员他以为学那个就可以了，所以真正瓶颈都在这里。就是说如果我们对业务没有一个很贴切的，对这个业务内涵没有一个透彻的理解的话，实际上最终出来的模型肯定还是不好的，所以就是说不管怎么样，一定要对业务有透彻的理解，这才能够做好这个从需求到架构的过渡。
潘：实际上我能谈的就是说这个从需求往设计方面走，那这里面经常会有很多误解，就是说很多开发人员觉得我只要学那些设计的技术就可以了，比如说设计模式、对象分析的思想等等。但实际上这里面真正的瓶颈不是设计的技术，也不是建模技术。你要做好，实际上你需求是问题域，相当于提出问题，相当于出题。那我们的这个设计相当于把那个题目给做了，做到这个需求，满足需求的这个结果，那这本身的话，从问题跳到解决方案本身它是鸿沟，有一道鸿沟，这鸿沟计算机是无法帮我们推导的，所以才需要开发人员来推导，而鸿沟下面是可以推导的，你说现在的模型，你自动，像有些嵌入式的系统，他们状态以及模式，就直接就执行了，他不会有人工编码的，因为人工编码会引进危险的。那也就是鸿沟下面的这部分，就是说跳到解决方案之后的部分，是可以计算机自动过渡的，难度在于就是说如何从问题跳到第一步这个解决方案，这部分只能靠我们人脑。那么这个人脑只有我们的系统分析原理，用架构师的大脑。他一方面要具备业务知识，第二方面要具备这个建模的技术，你要掌握一种建模技术，要么是面向对象的，要么是以前的结构化分析和设计都可以，这两个都可以。但是想想最终的瓶颈，我认为还是在这个业务知识上面，你说对象基础你掌握到一定程度，它里面的原则都知道了，那对象基础里面的原理、原则、模式，原理不就那么几条吗，原则也就十几条，模式上千个，这些都融会贯通就没有问题了。但实际上即使你掌握了原理，也没用，为什么？你怎么面对对象分离变化？那这个口号都会喊了，但实际上真正的难点，真正的细节上的难点，你怎么知道那个是变的，那个是不变的，那你必须要对业务有一个很透彻的了解。所以很多开发人员他以为学那个就可以了，所以真正瓶颈都在这里。就是说如果我们对业务没有一个很贴切的，对这个业务内涵没有一个透彻的理解的话，实际上最终出来的模型肯定还是不好的，所以就是说不管怎么样，一定要对业务有透彻的理解，这才能够做好这个从需求到架构的过渡。
温：这个提法是企业架构领域当中的一种架构框架，它具体提出来的就是业务架构、应用架构、信息架构和技术架构，实际上作为我们架构师一定要认识到一点，这四种是架构视图。我们说整个业界做软件架构设计，很多视图的方法已经在IEEE1471标准当中已经明确推荐的，怎么样描述架构，怎么样思考架构。那么企业架构（EA）这一块是架构的一个很重要的分支，他也会提出来自己的方法，这个提法应该是企业架构设计方法的这种多视图的方法，不是四种架构，这个问题也很典型。
我在写软件架构设计这本书的时候，我的一位朋友问我，温昱你写这本书是写什么架构？我说呢，我知道你是怎么想的，你认为架构分几种，那么我想告诉你，是我们架构设计方法当中把它分成了视图，只不过我们在实践当中不想说这个业务架构视图，实际上是视图的概念。这个概念呢，我们生活当中也会有很有意思的例子，互联网是一个非常非常大型的系统，他的架构视图在哪里？为什么伊拉克战争的时候，报纸上会说这个软件行业，这IT行业真的很棒，对不对？这样一个国家会轰炸的非常厉害，但是消息依然能够通过互联网发送出去，怎么样，包的存储转发。但是在这个一年之前吧，台湾光缆断裂事件，使得我们的这个互联网受到了非常多的媒体的批评，这问题怎么理解，为什么刚刚还是很好的，现在突然变成很坏了？可以通过我们架构视图的这个思维角度去解释它。互联网这个系统它的逻辑架构设计的非常棒，包的存储转发机制就是当中一个非常非常好的想法，那么我们的互联网呢，它的这个物理架构或者叫部署架构设计有问题，恐怕是这个基于成本的考虑，我只在那个非常容易发生地震的海峡部署了一条关键路径的这样一个光缆。于是断裂了之后影响互通性，这是我对这个架构视图的一个看法。
潘：我对这个没有什么看法，主要还是在细节上，着力我还是说这个。
我在写软件架构设计这本书的时候，我的一位朋友问我，温昱你写这本书是写什么架构？我说呢，我知道你是怎么想的，你认为架构分几种，那么我想告诉你，是我们架构设计方法当中把它分成了视图，只不过我们在实践当中不想说这个业务架构视图，实际上是视图的概念。这个概念呢，我们生活当中也会有很有意思的例子，互联网是一个非常非常大型的系统，他的架构视图在哪里？为什么伊拉克战争的时候，报纸上会说这个软件行业，这IT行业真的很棒，对不对？这样一个国家会轰炸的非常厉害，但是消息依然能够通过互联网发送出去，怎么样，包的存储转发。但是在这个一年之前吧，台湾光缆断裂事件，使得我们的这个互联网受到了非常多的媒体的批评，这问题怎么理解，为什么刚刚还是很好的，现在突然变成很坏了？可以通过我们架构视图的这个思维角度去解释它。互联网这个系统它的逻辑架构设计的非常棒，包的存储转发机制就是当中一个非常非常好的想法，那么我们的互联网呢，它的这个物理架构或者叫部署架构设计有问题，恐怕是这个基于成本的考虑，我只在那个非常容易发生地震的海峡部署了一条关键路径的这样一个光缆。于是断裂了之后影响互通性，这是我对这个架构视图的一个看法。
潘：我对这个没有什么看法，主要还是在细节上，着力我还是说这个。
那就是RUP这边呢，他提出有一个四加一的视图，然后中间有一个很重要观点就是，有一个很重要的概念就是说用例视图，然后这里边呢人们经常会对这个用例视图里边的一个粒度会产生一些疑问，那我想问一下，就是说二位在这个对用例的粒度这方面怎么划分？二位有什么样的看法？
潘：那这个问题实际上也是我被问得最多的，也是大家问这个用例问的最多的，实际上这个涉及到一个很关键的问题，就我们为什么我们要使用用例这种方法？不是说有人拿出来推销，也不是说最终一定要用这个，否则不时髦，那是被逼无奈，就是我们现在的以前这种捕获需求的方式已经不够了，如果还够的，包括架构设计一样，如果说以前的方法还灵，还够用，我们为什么要用它呢？那是因为没办法，谁也不想多干活，但是问题是什么？不行了，市场经济了，你不这样想是不行了，所以这种新方法，这种更好的方法它主要的目的就是说首先必须要把重心放在社众的这一端，然后来揣摩社众的真实的用心，比如说你用例用得对不对，关键点就是有没有加强我们和社众之间的联系，那么从这点来看，用例的粒度应该就不成问题了，用力实际上就是一个契约吗，就是系统能够为我们提供什么样的契约，那么这个契约到底是多大多小合适呢？完全是取决于社众对他的看法。
那实际上大家想象一个问题就明白了。比如说经常我会有人问的，比如说我们去医院，以医院为研究对象，挂号算不算用例？那实际上这个问题，如果说能回答对，为什么你说是，为什么是？不是，为什么不是？能够回答对，基本上就已经理解了这契约的含义。答案是不对，不是。那为什么呢？不是说挂号没价值，而是说在涉众的心里面，医院能够向他承诺的契约，不只是挂号那么简单。如果说你只是挂完号，涉众觉得这个医院的契约已经完成了，那么显然很可能这个人就不是病人了，可能是“黄牛党”去挂号，那么医院很可能会为“黄牛党”提供挂号的服务，但是为病人提供的，他向病人承诺的，以及病人对医院的这种期望，它远远不只挂号这么简单。因为我们研究对象是医院，所以医院他的契约是看病，但是如果说我们转换一个研究对象，比如说挂号室，那么挂号就是他的用例。为什么？因为病人他不会说因为挂号室只给他了挂号，不给他看病，他会骂这个挂号室。他不会，那么这个就是我们首先为什么会有粒度的看法，是因为很多时候，我们头脑里面的概念模糊掉了，才会有粒度的看法，那么头脑里面概念很清楚，就是说首先破解的关键，就是说你的研究对象是什么？只要讨论用例的时候，第一个事情是要问，你到底目前的研究对象是什么？很多人觉得这个事情没价值。比如说，我们再举一个例子，比如说有一人事管理系统，那么我们的员工在这个系统里面请假，交请假单，然后老板要批假，然后人事部门要备案，这三个事情完成之后，才能算是请到假。那经常就会有人认为，真正的用例是什么？是请假，为什么？在员工看来呢，能够请到假而且回家了，才算是达到了目的。但实际上这个目的的时候，当他这样说的时候，他头脑里面已经把他的研究对象偷偷的改变掉了。他把系统还有他的上司还有人事部门那人绑在一起，作为一个研究对象，实际上这只有这几个东西才能够向他承诺能请到假，系统本身是无法承诺让他能请到假的，他只能向他承诺什么？他把请假单交进来，然后他把他行起来，那么这个才是系统的契约，如果说在这个地方有模糊，那么实际上我们只要问一个问题，我们的研究对象是什么，就可以了。
那么第二个问题是经常会有人问了，就是比如我现在一个Email，发Email的一个系统，那么这个研究人员也很清楚了，那么到底发邮件、收邮件是两个用例呢？还是收发邮件是一个用例，这是一个最常问的问题，类似的问题，那是很简单，标准答案在涉众的心里面，没有标准答案，就是说你在涉众看来收邮件、发邮件是两个事情还是一个事情？这个没有答案的，那到底是两个事情还是一个事情？我问大家的话，大家肯定会说，肯定是一个事情，不是的。那么前两天我刚经历一个项目，就是两个事情，那么这个用户，汽车的用户，他对收邮件是很在意的，这个用例是摆在什么？很高的位置，但发邮件，他并不想在汽车上发邮件，点点的他不能，他也不想，这个需求是很低的，很可能这个版本根本不需要这个功能。主要是两点，第一个，我们的研究对象是什么？这个是能破解力度问题；第二个就是说剩下的问题交给涉众，我们就去揣摩社众的心意，其他的就没有标准答案了，不管怎么样都是对的。
那实际上大家想象一个问题就明白了。比如说经常我会有人问的，比如说我们去医院，以医院为研究对象，挂号算不算用例？那实际上这个问题，如果说能回答对，为什么你说是，为什么是？不是，为什么不是？能够回答对，基本上就已经理解了这契约的含义。答案是不对，不是。那为什么呢？不是说挂号没价值，而是说在涉众的心里面，医院能够向他承诺的契约，不只是挂号那么简单。如果说你只是挂完号，涉众觉得这个医院的契约已经完成了，那么显然很可能这个人就不是病人了，可能是“黄牛党”去挂号，那么医院很可能会为“黄牛党”提供挂号的服务，但是为病人提供的，他向病人承诺的，以及病人对医院的这种期望，它远远不只挂号这么简单。因为我们研究对象是医院，所以医院他的契约是看病，但是如果说我们转换一个研究对象，比如说挂号室，那么挂号就是他的用例。为什么？因为病人他不会说因为挂号室只给他了挂号，不给他看病，他会骂这个挂号室。他不会，那么这个就是我们首先为什么会有粒度的看法，是因为很多时候，我们头脑里面的概念模糊掉了，才会有粒度的看法，那么头脑里面概念很清楚，就是说首先破解的关键，就是说你的研究对象是什么？只要讨论用例的时候，第一个事情是要问，你到底目前的研究对象是什么？很多人觉得这个事情没价值。比如说，我们再举一个例子，比如说有一人事管理系统，那么我们的员工在这个系统里面请假，交请假单，然后老板要批假，然后人事部门要备案，这三个事情完成之后，才能算是请到假。那经常就会有人认为，真正的用例是什么？是请假，为什么？在员工看来呢，能够请到假而且回家了，才算是达到了目的。但实际上这个目的的时候，当他这样说的时候，他头脑里面已经把他的研究对象偷偷的改变掉了。他把系统还有他的上司还有人事部门那人绑在一起，作为一个研究对象，实际上这只有这几个东西才能够向他承诺能请到假，系统本身是无法承诺让他能请到假的，他只能向他承诺什么？他把请假单交进来，然后他把他行起来，那么这个才是系统的契约，如果说在这个地方有模糊，那么实际上我们只要问一个问题，我们的研究对象是什么，就可以了。
那么第二个问题是经常会有人问了，就是比如我现在一个Email，发Email的一个系统，那么这个研究人员也很清楚了，那么到底发邮件、收邮件是两个用例呢？还是收发邮件是一个用例，这是一个最常问的问题，类似的问题，那是很简单，标准答案在涉众的心里面，没有标准答案，就是说你在涉众看来收邮件、发邮件是两个事情还是一个事情？这个没有答案的，那到底是两个事情还是一个事情？我问大家的话，大家肯定会说，肯定是一个事情，不是的。那么前两天我刚经历一个项目，就是两个事情，那么这个用户，汽车的用户，他对收邮件是很在意的，这个用例是摆在什么？很高的位置，但发邮件，他并不想在汽车上发邮件，点点的他不能，他也不想，这个需求是很低的，很可能这个版本根本不需要这个功能。主要是两点，第一个，我们的研究对象是什么？这个是能破解力度问题；第二个就是说剩下的问题交给涉众，我们就去揣摩社众的心意，其他的就没有标准答案了，不管怎么样都是对的。
目前二位谈到的这些一些传统架构设计方法，会引入很多的文档，然后目前社区里边有另外一种呼声是说，我们要减少这些面面俱到的文档，然后让尽量精简这样的设计，然后就让代码，就把代码作为一种设计，那二位对这方面是怎么样一个看法呢？
温：发散谈一下吧。代码里面肯定是藏着设计的，包括我的职业生涯中有时候是拿到大量源代码，前面的工作是前任做的，文档很差，人走掉了，这时候怎么办？最终依然推进下去了，因为代码里面有设计，我也会和大家分享，一些读代码的技巧，第一要借助建模工具，正逆向工程；第二怎么样删代码，当你要读程序的时候，删代码是很好的一个技巧，把不关键代码删掉，你读出代码当中的架构；第三接触重构，有些核心代码，大家去改它的时候，不敢乱碰，只是在很小心地增加，最后充满了这种注释，Modify by谁谁谁，对不对？最终我们说读核心代码的时候，可以借助重构的方式，把相关的名称，相关的职责都可以调整划分开来。
再谈另外一点，很多时候，我会见到一些入职的员工，他们去画类图等等，他们直接从代码当中找到类图，这些类图本身是设计不错，但是我们说如果细节高了价值是不大的。你画和这个工具逆向出来有什么差异吗？所以说我们在考虑设计的时候，未必是把所有的细节的这种依赖都画出来，这是设计或者说直接整个代替这种设计文档的一种做法的不妥之处，任何时候你的细节程度一样，那么你的图和代码没什么区别，这时候倒是说这个代码就是设计，这块会有一定的问题。画出蜘蛛网式的图永远是有问题的，包括UML当中的每一种图，一定要有相关的抽象，才可以方便交流。
潘：对这方面的话确实也有很多的话语，因为这毕竟是一个很吸引人的一个说法，如果代码可以设计就可以不写文档，这个本身我也没什么意见。我的观点就是说，世界上有各种各样的团队，各种各样的项目，没有一个统一的标准，如果说代码能当文档用，可以不写文档那很好，但很多时候我们还是我刚才的说法，不是我们自己想做而喜欢做，谁想多干活呢？很多时候就是被迫为之吗，你不得不干，那么这种很多很多。所以就是说如果能够少做一点，那当然好，但是很多时候是必须要做的，那么Ivar Jacobson他以前也是，推断的RUP，那么后来他也发现大家用的时候很多误区，就是说经常会人问说，有没有一个团队完完整整实施RUP？经常会有这样问，但实际上RUP这种东西他不是让你完完整整实施的，是要经过团队的特点来裁减，那么在团队的特点来裁减的话，按道理来说，整个世界上不应该有两只团队，他们的过程是完全一样的，就是该出什么样的文档，很详细的文档还是很粗的文档，出不出文档应该是没有完全一样的。就像足球比赛一样，战术，巴西有巴西的战术，德国有德国的战术，意大利有意大利的战术，不能够说巴西队他看了意大利拿了冠军，他就学意大利，肯定不行，那么他跟团队成员的情况，跟这个项目的类型是密切相关的。所以我的观点就是说与其去争论文档多少，或者说过程应该规范好，还是敏捷好，当然敏捷这两个字就像革命一样，它已经占了这个道德上的制高点啊。但是要注意占领这个道德上制高点的东西，我们更要很谨慎的对待它，那么我不并是说敏捷不好，而是说关键还是中间的技能，如果我们的技能能上去，选择什么样的过程这个不是问题，出多少文档就不是问题；如果说是技能上不去的话，你出一个文档也是错的，包括你的代码也是错的，这些技能就是我刚刚说得一些需求的技能，就找到问题的技能，里面有很多很多的细节，设计的技能有很多很多细节，那我觉得改进的重点还是要在这个技能问题上，特别是技能的细节上。如果说像，还是拿足球举例，如果中国队有12个或者20个罗纳尔迪尼奥，那么以前的朱广沪他就不会说，为打什么样的战术而伤神。那以前朱广沪是什么？就是说中国队员上场要像疯狗一样，喊口号，但事实上对疯狗的意思讲就是要勇，后来不行了，我中国队员不但要当疯狗，还要当警犬，这些都是口号。但实际上问题的关键不在口号而在于什么？如何能从一个不再疯的狗变成疯狗，如何能够从一个很普通的狗变成警犬，这里面有很大量的技能问题，如果大家都像警犬，都像罗纳尔迪尼奥一样，打什么战术这里有很大的余地。但是如果说你手上的人，他的素质是非常低的，都是年轻球员，那很多你可选择的余地是非常小的，已经非常非常。，那实际上这里面，还是我的观点就是说技能改进为主，过程改进这个东西，或者说到底是用规范点的方法，还是包括XP好还是其他方法等，这个东西，我都不想去争论，实际上包括Ivar Jacobson，他现在说过程够了，我们实践吧。也就是说他把归纳最佳实践就用就行了，至于你该用哪一些，这本身不是很重要，每个团队跟人家是不一样的。
温：好了，我来补充一句，加宇刚才提到一个非常好的一点观点就是文档，做多少、做到什么程度要看这个实际情况，要看团队情况。那我还想补充一小点，就是还要看客户的情况，总之想看文档的人到底是什么样的角色，如果是客户就是你这个项目业主是直接外包给你，还要看相关的文档，也会考虑他的要求，总之是要看整个这个实际情况是怎么样，有没有这个去看文档的需求，可以这么说吧。
再谈另外一点，很多时候，我会见到一些入职的员工，他们去画类图等等，他们直接从代码当中找到类图，这些类图本身是设计不错，但是我们说如果细节高了价值是不大的。你画和这个工具逆向出来有什么差异吗？所以说我们在考虑设计的时候，未必是把所有的细节的这种依赖都画出来，这是设计或者说直接整个代替这种设计文档的一种做法的不妥之处，任何时候你的细节程度一样，那么你的图和代码没什么区别，这时候倒是说这个代码就是设计，这块会有一定的问题。画出蜘蛛网式的图永远是有问题的，包括UML当中的每一种图，一定要有相关的抽象，才可以方便交流。
潘：对这方面的话确实也有很多的话语，因为这毕竟是一个很吸引人的一个说法，如果代码可以设计就可以不写文档，这个本身我也没什么意见。我的观点就是说，世界上有各种各样的团队，各种各样的项目，没有一个统一的标准，如果说代码能当文档用，可以不写文档那很好，但很多时候我们还是我刚才的说法，不是我们自己想做而喜欢做，谁想多干活呢？很多时候就是被迫为之吗，你不得不干，那么这种很多很多。所以就是说如果能够少做一点，那当然好，但是很多时候是必须要做的，那么Ivar Jacobson他以前也是，推断的RUP，那么后来他也发现大家用的时候很多误区，就是说经常会人问说，有没有一个团队完完整整实施RUP？经常会有这样问，但实际上RUP这种东西他不是让你完完整整实施的，是要经过团队的特点来裁减，那么在团队的特点来裁减的话，按道理来说，整个世界上不应该有两只团队，他们的过程是完全一样的，就是该出什么样的文档，很详细的文档还是很粗的文档，出不出文档应该是没有完全一样的。就像足球比赛一样，战术，巴西有巴西的战术，德国有德国的战术，意大利有意大利的战术，不能够说巴西队他看了意大利拿了冠军，他就学意大利，肯定不行，那么他跟团队成员的情况，跟这个项目的类型是密切相关的。所以我的观点就是说与其去争论文档多少，或者说过程应该规范好，还是敏捷好，当然敏捷这两个字就像革命一样，它已经占了这个道德上的制高点啊。但是要注意占领这个道德上制高点的东西，我们更要很谨慎的对待它，那么我不并是说敏捷不好，而是说关键还是中间的技能，如果我们的技能能上去，选择什么样的过程这个不是问题，出多少文档就不是问题；如果说是技能上不去的话，你出一个文档也是错的，包括你的代码也是错的，这些技能就是我刚刚说得一些需求的技能，就找到问题的技能，里面有很多很多的细节，设计的技能有很多很多细节，那我觉得改进的重点还是要在这个技能问题上，特别是技能的细节上。如果说像，还是拿足球举例，如果中国队有12个或者20个罗纳尔迪尼奥，那么以前的朱广沪他就不会说，为打什么样的战术而伤神。那以前朱广沪是什么？就是说中国队员上场要像疯狗一样，喊口号，但事实上对疯狗的意思讲就是要勇，后来不行了，我中国队员不但要当疯狗，还要当警犬，这些都是口号。但实际上问题的关键不在口号而在于什么？如何能从一个不再疯的狗变成疯狗，如何能够从一个很普通的狗变成警犬，这里面有很大量的技能问题，如果大家都像警犬，都像罗纳尔迪尼奥一样，打什么战术这里有很大的余地。但是如果说你手上的人，他的素质是非常低的，都是年轻球员，那很多你可选择的余地是非常小的，已经非常非常。，那实际上这里面，还是我的观点就是说技能改进为主，过程改进这个东西，或者说到底是用规范点的方法，还是包括XP好还是其他方法等，这个东西，我都不想去争论，实际上包括Ivar Jacobson，他现在说过程够了，我们实践吧。也就是说他把归纳最佳实践就用就行了，至于你该用哪一些，这本身不是很重要，每个团队跟人家是不一样的。
温：好了，我来补充一句，加宇刚才提到一个非常好的一点观点就是文档，做多少、做到什么程度要看这个实际情况，要看团队情况。那我还想补充一小点，就是还要看客户的情况，总之想看文档的人到底是什么样的角色，如果是客户就是你这个项目业主是直接外包给你，还要看相关的文档，也会考虑他的要求，总之是要看整个这个实际情况是怎么样，有没有这个去看文档的需求，可以这么说吧。
温：这个呢，大师Grade Booch大致是怎么归纳的呢？三方面，第一方面呢，就是偷，也就是借鉴业界现成的一些正确的做法或者说是成功的做法；第二种是方法，我们先说第三种，第三种就是直接靠经验或者灵感来创造。第一种是偷，第三种是创造，那么介于两者之间呢，我们刚才也提到方法。方法它不是说完全照搬，也不是说我就完全创造，它会有一些理性的分析，也会权衡怎么样来做这件事情，大致来讲，这个Grade Booch已经帮我们回答这个问题了。
能不能改善一下网速
发表人
wang metis
发表于
Re: 能不能改善一下网速
发表人
xu rolle
发表于
《软件架构设计》：一本包装出来的浮躁精品
发表人
Zhang Charlie
发表于
Re: 《软件架构设计》：一本包装出来的浮躁精品
发表人
wang justin
发表于
关于什么是张恂的标准
发表人
Zhang Charlie
发表于
Re: 关于什么是张恂的标准
发表人
Xu Alex
发表于
Re: 《软件架构设计》：一本包装出来的浮躁精品
发表人
Chang Robin
发表于
Re: 《软件架构设计》：一本包装出来的浮躁精品
发表人
Shi Feng
发表于
确实网速很慢，视频看得不是很舒服
发表人
叶 旭辉
发表于
何以见得！？
发表人
Xu Eric
发表于
Re: 何以见得！？
发表人
Xu Eric
发表于
要义
发表人
郭 名讳
发表于
一些关于架构的论文
发表人
luzhou tang
发表于
对业务的理解是关键
发表人
朱 宏伟
发表于
-
能不能改善一下网速
-
也不支持缓冲
效果太烂了 -
又一本包装出来的浮躁精品：评温昱《软件架构设计》
也许是我的粗心，我看错了，读得不够仔细，不够认真。
从软件专业的角度看，我认为这是一本非常初级的、所谓的软件架构设计图书。在周筠、孟岩等人的眼里，这是一本隆重推出的原创精品，不知道它是否符合博文视点其他股东和投资人的精品标准。而我个人的鉴定意见是，此书完全达不到精品尤其是原创精品的标准。显然，在周筠、孟岩的精品标准与张恂的精品标准之间存在着巨大的 Gap。那么，什么是咱中国软件人、程序员所能广泛认同的精品标准，这是我想建议大家来一起研究的。
我给所有图书的作者、编者、责编、总编、总监、总裁，以及形形色色的书托们 ... 等等一切利益相关者（包括张恂在内）的建议是：无论何时、何地，请千万不要投机取巧，千万不要忽悠读者。
好了，我要看书、编程去了，继续学习中 ...
软件架构设计专家 张恂
www.zhangxun.com -
“显然，在周筠、孟岩的精品标准与张恂的精品标准之间存在着巨大的 Gap。那么，什么是咱中国软件人、程序员所能广泛认同的精品标准，这是我想建议大家来一起研究的。”
有个问题，张恂的标准到底是什么？ -
又一本包装出来的浮躁精品：评温昱《软件架构设计》
也许是我的粗心，我看错了，读得不够仔细，不够认真。
从软件专业的角度看，我认为这是一本非常初级的、所谓的软件架构设计图书。在周筠、孟岩等人的眼里，这是一本隆重推出的原创精品，不知道它是否符合博文视点其他股东和投资人的精品标准。而我个人的鉴定意见是，此书完全达不到精品尤其是原创精品的标准。显然，在周筠、孟岩的精品标准与张恂的精品标准之间存在着巨大的 Gap。那么，什么是咱中国软件人、程序员所能广泛认同的精品标准，这是我想建议大家来一起研究的。
我给所有图书的作者、编者、责编、总编、总监、总裁，以及形形色色的书托们 ... 等等一切利益相关者（包括张恂在内）的建议是：无论何时、何地，请千万不要投机取巧，千万不要忽悠读者。
好了，我要看书、编程去了，继续学习中 ...
软件架构设计专家 张恂
www.zhangxun.com
成天就看到这个人在这里骂街，也不见你写出两本真正有用的东西来。看到别人写了一点东西出来就眼红了，难道你跟温昱有仇吗？看了很多你骂他的文章，今天实在有些看不过去了。
书虽然是初级了点，但是对于刚入门或想入门的SA来说也是好事呀，看问题不要太偏执。 -
justin wang:
有个问题，张恂的标准到底是什么？
简单地说，就是更加自律和专业（more professional），向更专业、技术水平更高的作者学习，起码要达到行业的平均水准。
软件研发作为一门科学和工程的艺术，也是一门特殊的专业和职业（profession），这项工作非常强调逻辑性，而科学的逻辑分析、思维和判断能力是需要经过长期专业、刻苦的训练才有可能掌握的。
客观上，温昱的《软件架构设计》恰恰缺乏概念完整性（concept integrity），逻辑混乱，写作水平表现得非常业余。我很难相信，这是一位资深软件架构师的创作。建议有关人士最好不要再表演下去了。
至于什么是软件技术图书的精品，什么是原创精品，我想众多西方的软件科学家、工程师、大师级专家们已经为我们作出了表率，大家都有收藏，不用我再赘举了吧。他们的著作所反映出来的那些质量属性，应该就是精品的标准。
张恂 -
说的好。作为一个技术人员一定要有所操守。不能昧着良心糊弄。那样只能会误人误己。
-
希望管理员自己能够测试一下，并改善
-
“如果你手上的人，他的素质是非常低的，高中生程序员。”
看来潘加宇直接把【素质】和【学历】挂钩，不愧是北京大学硕士，素质果然很高啊。 -
我就是一名高中生程序员，我在虚心学习你们的思想的同时，同时享受这种没有任何依据的侮辱，我不能认同素质可以和学历挂钩，在工作中我认为学历所起到的最大的作用还是敲门砖的作用，实际工作中的技术水平则完全取决勤奋、天赋和经验，就算在开发中会用到大学中我没有学习到的知识，我相信这我也能像学习一门新技术一样在较短时间入门。我认为大学知识并不全部是我需要的，而在社会中需要仅仅大学生这个身份。做为一个北京大学硕士，从你简单的谈吐中我更加能确定我的认识。
-
对于架构这个东东，实在没什么感觉，或许随着时间会有所认知。不过能够看到一些有价值的东西，足矣！建模技能需要积累；业务领域需要沟通
-
一些关于架构的论文
cloud.mao2.com/cloud/papers.html -
虽然没有读过这本书，但也了解一些温昱技术思想，个人觉得可以借鉴学习。张恂就别到处闹腾了，这里又不是娱乐圈，这么争吵只能降低自己的可信度。跟温昱有什么具体的技术分歧倒是可以拿出来晒晒，大家说不定能从中受益的。动不动就扣帽子，拿西方来唬人，已经不是那个年代了。
-
如果缺乏对业务的理解，再好的架构也是巴比伦塔。
14 条回复
关注此讨论 回复