软件工程实践者的思想(PDF格式)-第9部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！





Aspect　关注于“有相似需求的考察对象”的群体特性。其　



相似性在群体中表现得越广泛，则　AOP　　　　　　　　　　　　　　的优势也就越明　



显。例如在　Delphi　　的　VCL　框架中，以下两个需求就可以　



　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



①　　　人们在争论Aspect　到底应该译成“切面”还是“方面”这件事上　



花了很多功夫。其实，就如同讨论前面的“关注点”究竟是“点”　



还是“线”的问题一样，他们陷入了细节。如果这些细节被作为　



问题持续下去，那么可能有一天台海战争将不是发生在军队之间，　



而是在程序员之间：到底是“物件”，还是“对象”？　　



②　　　在C　中，这个名词是“结构（Struct）　”。很多人不会承认“对象是　



有继承关系的记录”这样的观点。是的，所有的教科书上都不会　



这样写。但是从数据结构本身以及数据结构在语言中的实现来看，　



对象终究是记录。记录是平板化的内存存储体系中所能表达的最　



复杂的单一数据体。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…94


…………………………………………………………Page　99……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



用　AOP　　的思想来实现：　　



　　　　）　　使　Delphi　　中的全部对象具有多线程特性（　即线程　



　　　　　　　安全）　；　　



　　　　）　　实现助手工具类以观察、控制　Delphi　　　　　　　　对象的运　



　　　　　　　行期特性或表现。　　

　　　　　



　　　到现在为止，我们弄清楚了　AOP　作为“思想、方法、　



工具”的一些基本知识，以及它的应用范围：至少你要明　



白，他是用来考察对象（而不是设计对象）　的思想方法。　　



　　　所以接下来　AOP　　的三个概念我们就明白了：　　



　　　　）　　指示（advice）/拦截器（interceptor）　：考察这些对象　



　　　　　　　以“达到什么样的目的”（　即需求）　；　　



　　　　）　　引导（introduction）　：在目标上实现这些需求时，　



　　　　　　　目标所需要表现出来的公共特性。引导特性可能　



　　　　　　　需要配合编译器来实现。　　



　　　　）　　元数据（metadata）　：如果需要，为既有对象实体　



　　　　　　　再补充一些参考数据。　　



　　　确切的说，切分点（Pointcut）并不是　AOP　　编程方法所　



需要的概念，而是　AOP　　作为一个框架时所需要的一个工　



具：一组辨识　Acpects　和　Objects　　的索引。　　



　　　现在你已经会用　Acpect　　　　　的思想来编程了，而无论它　



是用　Java　　来实现的，或者是用　C#　、Delphi　，乃至于　



FORTRAN　或　COBOL　。你需要做的是，回到工程最核心　



的那个环节：编程＝算法＋结构＋方法。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…95


…………………………………………………………Page　100……………………………………………………………

第　7　章　　现实中的软件工程　　



　　　　5。　　　审视　MDA/MDD　　



　　　　MDA（Model　　Driven　　Architecture）　也是一个方法论层　



面上的名词。它讨论的是“创建出机器可读和高度抽象的　



模　型　”　的　方　法　。　受　　MDA　　　　　　　影　响　的　开　发　活　动　被　称　为　



MDD（Model　Driven　Development）　。　　



　　　　与　MDD　在同一个层面上的概念是：　　



　　　　）　　　TDD（Test　Driven　Development）　　

　　　　）　　　FDD（Feature　Driven　Development）　　

　　　　）　　　BDD（Business　Driven　Development）　　

　　　　）　　　R…TDD（Rapid　Template…Driven　　

　　　　　　　　Development）　　

　　　　）　　　CDD（Contract　Driven　Development）　　

　　　　）　　　RDD（Requirements　Driven　Development）　　

　　　　）　　　。。。　　

　　　　我不厌其烦地罗列这些名词，只想告诉读者一个事　



实：什么都可以“驱动开发”。　　



　　　　不同的方案提供商基于自己的产品构架和当前的理　



论倾向，随时都在准备改变他们“驱动开发”的方式。在　



这种形势下的　　　　　　　　“xDD　”或“xDA　”，已经成为他们促销产　



品的保留用词。　　



　　　　　　



　　　　回到软件工程的过程环节中来吧，你会看到，“以什　



么驱动开发”只是一个“以哪个环节为中心（或导引）　”的　



问题。所以你会看到　TDD　　中的　X　模型（也可参考　V　模型）　



是这样的：　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…96


…………………………………………………………Page　101……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



　　　　　　



　　　　如果你仍旧不能明白为什么会有这么多被神秘力量　



所“驱动着的开发”，那么你就干脆去厨房找个平底锅烧　



点热油，然后敲下一个鸡蛋，很快，你就体悟“以蛋黄驱　



动开发”的真谛了。　　



　　　　　　



　　　　抛开实现的技术细节不论，在工程中，“以什么驱动　



开发”其实是一个过程问题。而你应该明白，过程的选择　



（或制定）取决于你的工程需要，以及它在相关应用领域的　



适用性、过程工具的充备性和这个过程理论的完善程度，　



而不是大公司们的鼓吹。　　



　　　　　　



　　　　过程模型决定了工程的实施步骤和组织方式。但是　



Object　Management　Group　（OMG）　　尽管对　MDA　提出了一　



套完备的技术和方法体系，工程实施者却无法在这个体系　



中找到一个可以适用的软件过程模型。——MDA　　　　　　　　　　　　　　　　　　　　　　不讨论　



过程。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…97


…………………………………………………………Page　102……………………………………………………………

第　7　章　　现实中的软件工程　　



　　　　　也就是说，MDA　　　　　　　　　架构作为一个新的软件开发方法的　



架构，即使在技术研究、底层协议和软件实现方面经过了　



持续地完善而渐至成熟，然而如果没有同样成熟的软件过　



程理论支持，那么它在工程中的实用价值也就有限。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　仔细审视一下这个　MDA　，如果你现在就决定将下一　



个工程项目建立在这个构架的基础上，或者用　MDD　　的方　



式来开发　BIOS　，那么你离精神病就不远了。　　



　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…98


…………………………………………………………Page　103……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　　第8章　　是思考还是思想　　



　　　　　“此郎亦管中窥豹，时见一斑。”　　



　　　　　　　　　　　　　　　　　　　　　　　　　　——《晋书·王献之传》　　



　　　　1。　　　软件工程三个要素的价值　　



　　　　思考问题的方法可以是由点及面的，也可以是统揽全　



局的。换成业界最常用的词汇，就是“自上而下”还是“自　



下而上”的区别。　　



　　　　　“牛屎图”中描述的工具、方法与过程也被称为软件　



工程的三个要素。在本书中他们被分解开来思考，并不是　



要孤立这个三个层面。——它们实际上是相互作用的。　　



　　　　例如“过程”问题，就既有实施过程的工具，也有相　



关的过程方法理论。我虽然说方法是“基于一种数据结构　



的编程实践的结果”，但这实在一种非常狭义的定义。这　



个定义在过程的开发环节是有效的（或者说是对“开发方　



法”的定义）　。然而“需求”、“设计”、“测试”等等其它　



环节也有各自的方法论，即使站在具体环节之外，过程本　



身也有方法论的问题，这还不包括管理方法等等在内。　　



　　　　　　



　　　　由于方法在过程环节以及过程总体层面上具有贯通　



性，因此保证“方法（或其行为）　”的实施的“工具”也会　



　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…99


…………………………………………………………Page　104……………………………………………………………

第　8　章　　是思考还是思想　　



出现在过程的各个环节和层面上。因此这样得到的软件工　



程模型将不是经典的、层状的“牛屎图”，而可能象太极　



图一样由阴阳交汇而生万物。　　



　　　为了不使读者认为我已经入了道家理论的歧途，这样　



的一副图还是交由你自己去画吧。只不过你应该清楚，即　



使画出了太极图的软件工程模型，你所视见到的仍旧是工　



程的细部环节。就如同以管窥豹一般，斑是斑，豹是豹。　　



　　　你能把每一个“管见”拼合起来，你得到的才能是　



　“豹”，而不是“斑”。所以尽管本书割裂了软件工程的各　



个要素，并从每个孤立的层面来审视。然而实质上，你应　



该回归到软件工程的本体上来思考问题，而不是仅关注于　



每一个局部的要素。　　



　　　工程的整体问题仍旧是“实现”。　　



　　　2。　　　其实　RUP　是一个杂物箱　　



　　　我或许总是在批评　RUP　，但是我不得不承认它是对　



前人在软件过程思想方面高度包容。　　



　　　请注意我用“包容”这个词，而不是按照语言习惯那　



样用“概括”。因为如果是“高度概括”，那你应该把目光　



投向瀑布模型，而　RUP　其实就象一个杂物箱一样“包容”　



了全部的已知理论。　　



　　　你可以把　RUP　　定制成其它任何模型所表述的过程形　



态。——RUP　　本身的特质决定了这一点。——因而它也　



如同一个杂物箱一样放满了各种希奇古怪的东西。你可能　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…100


…………………………………………………………Page　105……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者　



是一根钓杆……　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　



　　　　喂，等等。面对“软件开发”这样的一个需求，钓杆　



能有什么作用呢？在你扔掉它之前，请转换一下你的思　



维：钓杆可能带给你的团队以精神上的激励。如果你能意　



识到这一点，那么它将立即转化为生产力：把钓杆挂在开　



发部的墙上。　　



　　　　　　



　　　　RUP　　　能不能被用起来，将取决于在于你刚才那个挑　



挑捡捡的行为，以及现在你在拿到钓杆后的辨识能力与组　



织能力。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…101


…………………………………………………………Page　106……………………………………………………………

第　8　章　　是思考还是思想　　



　　　3。　　　UML　与甲骨文之间的异同　　



　　　在你真的打算用甲骨文来写项目文档之前，请先明确　



UML　与甲骨文之间的异同。　　



　　　在这本书里，他们都被作为沟通的工具。因此目标是　



沟通，而不是“选用工具”这件事本身。更进一步的推论　



是：即使你因为个人喜好而选择了甲骨文，也不要试图在　



结绳记事的原始人面前去用它。　　



　　　UML　　与甲骨文都是符号文字，都具有象形含义。然　



而这并不表明　UML　符号本身能表达多么丰富的含义。如　



果要象甲骨文一样用几代人、上千册的论著去解释它，那　



么　UML　　图的价值也就只剩下象征性的意义了。　　



　　　　　



　　　　出于沟通的必要，这种语言的象征意义在一个图中应　



当被表述得足够准确和详细，乃至于针对于不同的阅读者　



来说都能提供了充足的信息。然而，一方面　UML　　的规范　



中没有提供一个标准来衡量“怎样的　UML　　图是描述充分　



的”；另一方面，UML　作为一个语言，也无法直接在某个　



硬件平台中被语法检错和调试。　　



　　　　　



　　　所以在工程中使用　UML　　图，应该有相应的文字来描　



述它。而且这种描述与图之间的对应关系要持续地维护下　



去。如果这种关系松散了、断裂了，那么下一个阅读　UML　



图的人所面对的，将是无异于甲骨文出土时的困境。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…102


…………………………………………………………Page　107……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



　　　好在做　UML　　　图的那个工程设计人员（在辞世之前）还　



有机会为这些古怪符号写下规约。　　



　　　4。　　　经营者离开发者很远，反之亦然　　



　　　使我第一次意识到　EHM　模型反映了角色所关注的不　



同视角的人，是我的老板。　　



　　　事实上，他是一个完全不懂软件技术的老板。在　EHM　



模型中，他所处于的位置在最右端，而开发者在最左端，　



在二者之间没有相同的关注界面（关注点）　。EHM　真实地反　



应了“老板不懂技术”的合理性，同样也真实的反应了“开　



发者转型为老板”的道路将是相当地漫长与艰难。　　



　　　　　



　　　于是，项目经理这个中间角色就有了一种使命：协调　



经营者与开发者之间的沟通。　　



　　　例如招来一名开发高手，对于公司的运作并不会有深　



入的影响（　当然如果你招来了　Anders　　Hejlsberg　就另当别　



论）　。因此，我甚至不需要与　BOSS　　　　　讨论这名高手的来历　



及作用。同样，与一个技术分析人员讨论一个产品的技术　



价值与市场价值之间的差异，以及市场运作方式与技术实　



现手段的无关性，是毫无必要的。　　



　　　你要理解这种根源：角色的关注层面完全不同。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…103


…………………………………………………………Page　108……………………………………………………………

第　8　章　　是思考还是思想　　



　　　5。　　　矛盾：实现目标与保障质量　　



　　　在需求阶段我们就会面临“目标”的问题。然而（在　



大多数时候）　，与此相反的是我们会在项目交付和试用时　



才会碰到客户在质量上的投诉。　　



　　　需求人员会把所有的责任归咎到开发人员，而开发人　



员又不停地埋怨需求的不清不楚或者变更的没完没了。又　



如果正巧需求和开发都是同一个人或者小组来做的，那么　



他们便会开始埋怨客户的苛刻以及工期的紧张。　　



　　　　　



　　　总之一件事，没有人会跳出来说：我们原本就错了。　



然而事实上可能真的出在源头：我们把目标定错了。　　



　　　我们看到，在项目的平衡三角（　时间、资源和功能）　中　



讨论的是目标问题，但并不讨论质量问题。也就是说，经　



典教材中总是关注：如何更快的完成项目，并减少资源占　



用，以及实现更多的功能。然而，即使平衡了这种关系，　



项目的结果仍可能产生一个天生的残障。　　



　　　因为目标可能在平衡中确立，但质量却要在过程中控　



制。即使在时间、资源和功能三者中取得了平衡，即使客　



户、项目组和公司同样满意于这个平衡“目标”，它仍然　



有可能是“不能实施”的。　　



　　　　　



　　　如果原定的目标（　的整体）本身就过大，那么无论如何　



平衡这三者之间的关系，其结果仍旧是保障不了质量。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…104


…………………………………………………………Page　109……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



　　　问题是：又有谁愿意在最初签订协议的时候，就降低　



或者放弃协议的标的呢？　　



　　　6。　　　枝节与细节　　



　　　刚才说到目标和质量的问题时，提及“平衡时间、资　



源和功能三者的关系”。这其实是一个实施过程中的细节。　



或者说，它是一个具体的方法，而不是目的。　　



　　　所以我们通常所说的细节，其实是对实施方法的一些　



有限量的描绘。比如“软件工艺”这个概念本身的提出，　



就是考究“细节问题”的。从这个角度上来说，我并不反　



对“细节决定成败”这样的观点。但请注意一个前提：这　



是技术或方法的细部。　　



　　　　　



　　　我其实在前面的行文中一再地混用了“细节”与“枝　



节”这两个词。枝节是事实发展的次要的分枝，它不涉及　



行为本身，也不是对行为本身的考量。因此我在前面的文　



字中说到“跳出细节”，其实的本意是“跳出枝节”。——　



细节只有做到何种程度的问题，而不并是关不关注（或做　



不做）　的问题。　　



　　　大多数情况下，管理人员有责任去审核、评估其它成　



员的工作成果。这个时候可以讨论“细节决定成败”这样　



的问题，因为这决定了产品的最终质量，而质量是工程的　



目标之一。　　



　　　而在另一些情况下，例如管理人员做事件的决策的时　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…105


…………………………………………………………Page　110……………………………………………………………

第　8　章　　是思考还是思想　　



候，就必须要学会忽略枝节问题。　　



　　　混淆这两个名词的使用，其根本原因在于一大部分读　



者并不能区分“细节”与“枝节”。从惯于“实做”的程　



序员一路走来的工程人员，很难分清自己什么时候是在　



　“工作”，而什么时候又是在“决策”。　　



　　　因此我只好用最笨的方法提示管理者：别管它是细节　



还是枝节，只要你感到你的脚趾已经沾上了泥淖，就快点　



回头。　　



　　　用脚趾去感觉，有时比用头脑去思维来得有效。　　



　　　7。　　　灵活的软件工程　　



　　　并不象现代人想见的那样，古诗词一定是“逐字论平　



仄”的。变化或者变通，其实是常见之事。因此古词谱中，　



才常会见到冠以“摊破”、“减字”、“添字”等字的词格。　



然则古人在词格上的这种变通，是基于“音律”的。　　



　　　通常说的词律是指词格，这与音律是两回事。词律（格）　



是平仄，音律则是乐器、音调与歌舞。古词中用来吟唱与　



歌舞的词牌就不能混用，律不同，调不同，如是之。　　



　　　“古人做词的变格，势必依音律而为之，舍周邦彦、东坡、　



辛弃疾此等人物，轻易变格，是为他人所笑话的。所以，词谱中　



所录变格既少，且俱为名家所创。”　　



　　　然而古词的音律（　亦即是律谱）　已经失传了，也就是　



说，今天的词是用来读的，不是唱，也不是舞，甚至连吟　



哦也不是。所以今人总是拿普通话中的　1、2　声作为平声，　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…106


…………………………………………………………Page　111……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



3　、4　声为仄声来填词，并以此论平仄，而全然不想词的　



格律的根基是“词律”与“音律”这两个部分的融合。　　



　　　我曾经参与过一个讨论，叫“古人是如何说话的”。　



在我看来，古人做文章和说话是两回事，文章中之乎者也，　



日常交流中还是市井俚语的。因此评论中会说“以俚语入　



词”。也可见填词作文章与说话毕竟是不同。再者说话也　



存在方言的问题，因此方言之间平仄音调也