 |
相關閱讀 |
大道至简——软件工程实践者的思想 第8章 是思考还是思想
|
>>> 讀書—連接古今充實信仰 >>> | 簡體 傳統 |
第8章 是思考还是思想
“此郎亦管中窥豹，时见一斑。”
——《晋书王献之传》
1. 软件工程三个要素的价值
思考问题的方法可以是由点及面的，也可以是统揽全局的。换成业界最常用的词汇，就是“自上而下”还是“自下而上”的区别。
“牛屎图”中描述的工具、方法与过程也被称为软件工程的三个要素。在本书中他们被分解开来思考，并不是要孤立这个三个层面。——它们实际上是相互作用的。
例如“过程”问题，就既有实施过程的工具，也有相关的过程方法理论。我虽然说方法是“基于一种数据结构的编程实践的结果”，但这实在一种非常狭义的定义。这个定义在过程的开发环节是有效的(或者说是对“开发方法”的定义)。然而“需求”、“设计”、“测试”等等其它环节也有各自的方法论，即使站在具体环节之外，过程本身也有方法论的问题，这还不包括管理方法等等在内。
由于方法在过程环节以及过程总体层面上具有贯通性，因此保证“方法(或其行为)”的实施的“工具”也会出现在过程的各个环节和层面上。因此这样得到的软件工程模型将不是经典的、层状的“牛屎图”，而可能象太极图一样由阴阳交汇而生万物。
为了不使读者认为我已经入了道家理论的歧途，这样
的一副图还是交由你自己去画吧。只不过你应该清楚，即
使画出了太极图的软件工程模型，你所视见到的仍旧是工
程的细部环节。就如同以管窥豹一般，斑是斑，豹是豹。
你能把每一个“管见”拼合起来，你得到的才能是
“豹”，而不是“斑”。所以尽管本书割裂了软件工程的各
个要素，并从每个孤立的层面来审视。然而实质上，你应
该回归到软件工程的本体上来思考问题，而不是仅关注于
每一个局部的要素。
工程的整体问题仍旧是“实现”。
2. 其实 RUP 是一个杂物箱
我或许总是在批评 RUP，但是我不得不承认它是对
前人在软件过程思想方面高度包容。
请注意我用“包容”这个词，而不是按照语言习惯那
样用“概括”。因为如果是“高度概括”，那你应该把目光
投向瀑布模型，而 RUP 其实就象一个杂物箱一样“包容”
了全部的已知理论。
你可以把 RUP 定制成其它任何模型所表述的过程形
态。——RUP 本身的特质决定了这一点。——因而它也
如同一个杂物箱一样放满了各种希奇古怪的东西。你可能
从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者
是一根钓杆……
喂，等等。面对“软件开发”这样的一个需求，钓杆
能有什么作用呢？在你扔掉它之前，请转换一下你的思
维：钓杆可能带给你的团队以精神上的激励。如果你能意
识到这一点，那么它将立即转化为生产力：把钓杆挂在开
发部的墙上。
RUP 能不能被用起来，将取决于在于你刚才那个挑
挑捡捡的行为，以及现在你在拿到钓杆后的辨识能力与组
织能力。
3. UML 与甲骨文之间的异同
在你真的打算用甲骨文来写项目文档之前，请先明确
UML 与甲骨文之间的异同。
在这本书里，他们都被作为沟通的工具。因此目标是
沟通，而不是“选用工具”这件事本身。更进一步的推论
是：即使你因为个人喜好而选择了甲骨文，也不要试图在
结绳记事的原始人面前去用它。
UML 与甲骨文都是符号文字，都具有象形含义。然
而这并不表明 UML 符号本身能表达多么丰富的含义。如
果要象甲骨文一样用几代人、上千册的论着去解释它，那
么 UML 图的价值也就只剩下象征性的意义了。
出于沟通的必要，这种语言的象征意义在一个图中应
当被表述得足够准确和详细，乃至于针对于不同的阅读者
来说都能提供了充足的信息。然而，一方面 UML 的规范
中没有提供一个标准来衡量“怎样的 UML 图是描述充分
的”；另一方面，UML 作为一个语言，也无法直接在某个
硬件平台中被语法检错和调试。
所以在工程中使用 UML 图，应该有相应的文字来描
述它。而且这种描述与图之间的对应关系要持续地维护下
去。如果这种关系松散了、断裂了，那么下一个阅读 UML
图的人所面对的，将是无异于甲骨文出土时的困境。
好在做 UML 图的那个工程设计人员(在辞世之前)还
有机会为这些古怪符号写下规约。
4. 经营者离开发者很远，反之亦然
使我第一次意识到 EHM 模型反映了角色所关注的不
同视角的人，是我的老板。
事实上，他是一个完全不懂软件技术的老板。在 EHM
模型中，他所处于的位置在最右端，而开发者在最左端，
在二者之间没有相同的关注界面(关注点)。EHM 真实地反
应了“老板不懂技术”的合理性，同样也真实的反应了“开
发者转型为老板”的道路将是相当地漫长与艰难。
于是，项目经理这个中间角色就有了一种使命：协调
经营者与开发者之间的沟通。
例如招来一名开发高手，对于公司的运作并不会有深
入的影响(当然如果你招来了 Anders Hejlsberg 就另当别
论)。因此，我甚至不需要与 BOSS 讨论这名高手的来历
及作用。同样，与一个技术分析人员讨论一个产品的技术
价值与市场价值之间的差异，以及市场运作方式与技术实
现手段的无关性，是毫无必要的。
你要理解这种根源：角色的关注层面完全不同。
5. 矛盾：实现目标与保障质量
在需求阶段我们就会面临“目标”的问题。然而(在
大多数时候)，与此相反的是我们会在项目交付和试用时
才会碰到客户在质量上的投诉。
需求人员会把所有的责任归咎到开发人员，而开发人
员又不停地埋怨需求的不清不楚或者变更的没完没了。又
如果正巧需求和开发都是同一个人或者小组来做的，那么
他们便会开始埋怨客户的苛刻以及工期的紧张。
总之一件事，没有人会跳出来说：我们原本就错了。
然而事实上可能真的出在源头：我们把目标定错了。
我们看到，在项目的平衡三角(时间、资源和功能)中
讨论的是目标问题，但并不讨论质量问题。也就是说，经
典教材中总是关注：如何更快的完成项目，并减少资源占
用，以及实现更多的功能。然而，即使平衡了这种关系，
项目的结果仍可能产生一个天生的残障。
因为目标可能在平衡中确立，但质量却要在过程中控
制。即使在时间、资源和功能三者中取得了平衡，即使客
户、项目组和公司同样满意于这个平衡“目标”，它仍然
有可能是“不能实施”的。
如果原定的目标(的整体)本身就过大，那么无论如何
平衡这三者之间的关系，其结果仍旧是保障不了质量。
问题是：又有谁愿意在最初签订协议的时候，就降低
或者放弃协议的标的呢？
6. 枝节与细节
刚才说到目标和质量的问题时，提及“平衡时间、资
源和功能三者的关系”。这其实是一个实施过程中的细节。
或者说，它是一个具体的方法，而不是目的。
所以我们通常所说的细节，其实是对实施方法的一些
有限量的描绘。比如“软件工艺”这个概念本身的提出，
就是考究“细节问题”的。从这个角度上来说，我并不反
对“细节决定成败”这样的观点。但请注意一个前提：这
是技术或方法的细部。
我其实在前面的行文中一再地混用了“细节”与“枝
节”这两个词。枝节是事实发展的次要的分枝，它不涉及
行为本身，也不是对行为本身的考量。因此我在前面的文
字中说到“跳出细节”，其实的本意是“跳出枝节”。——
细节只有做到何种程度的问题，而不并是关不关注(或做
不做)的问题。
大多数情况下，管理人员有责任去审核、评估其它成
员的工作成果。这个时候可以讨论“细节决定成败”这样
的问题，因为这决定了产品的最终质量，而质量是工程的
目标之一。
而在另一些情况下，例如管理人员做事件的决策的时
候，就必须要学会忽略枝节问题。
混淆这两个名词的使用，其根本原因在于一大部分读
者并不能区分“细节”与“枝节”。从惯于“实做”的程
序员一路走来的工程人员，很难分清自己什么时候是在
“工作”，而什么时候又是在“决策”。
因此我只好用最笨的方法提示管理者：别管它是细节
还是枝节，只要你感到你的脚趾已经沾上了泥淖，就快点
回头。
用脚趾去感觉，有时比用头脑去思维来得有效。
7. 灵活的软件工程
并不象现代人想见的那样，古诗词一定是“逐字论平
仄”的。变化或者变通，其实是常见之事。因此古词谱中，
才常会见到冠以“摊破”、“减字”、“添字”等字的词格。
然则古人在词格上的这种变通，是基于“音律”的。
通常说的词律是指词格，这与音律是两回事。词律(格)
是平仄，音律则是乐器、音调与歌舞。古词中用来吟唱与
歌舞的词牌就不能混用，律不同，调不同，如是之。
“古人做词的变格，势必依音律而为之，舍周邦彦、东坡、
辛弃疾此等人物，轻易变格，是为他人所笑话的。所以，词谱中
所录变格既少，且俱为名家所创。”
然而古词的音律(亦即是律谱)已经失传了，也就是
说，今天的词是用来读的，不是唱，也不是舞，甚至连吟
哦也不是。所以今人总是拿普通话中的 1、2 声作为平声，
3、4 声为仄声来填词，并以此论平仄，而全然不想词的
格律的根基是“词律”与“音律”这两个部分的融合。
我曾经参与过一个讨论，叫“古人是如何说话的”。
在我看来，古人做文章和说话是两回事，文章中之乎者也，
日常交流中还是市井俚语的。因此评论中会说“以俚语入
词”。也可见填词作文章与说话毕竟是不同。再者说话也
存在方言的问题，因此方言之间平仄音调也当不同。古代
的歌妓是要求会“官话”的，这相当于现在“普通话”的
地位，她们歌唱起来，也是用的“官话”。
更进一步的推论是：古代的词律中的平仄是以官话为
基础的。然而如今的普通话毕竟不是古时的“官话”，也
就是说，即使我们以普通话的四声为基础在论平仄，在古
人看来，也是可笑的：这样做出来的词，依旧不可唱，也
不可读。
因此今人做词的标准，是应该重定的了。除了词格(这
里仅指字句的格式)和用韵之外，其它的部分是无法遵循
的了。在各字的平仄以及句式上，应当以“能通顺”和“能
品味”为准，风格上则以古雅为益。
仅此而已。
对于我这样的格律观点，一位网友曾有一句“未蕴而
变，自欺也。知律而变，智者之道也”，实为良言。变向
不变求。不变者，万变之所源，亦万变之所归。习诗词之
法度，若蚕虫之结茧，若无结茧于前，何有破茧于后？故，
知律而变，智者之道也。
“知律而变”中的“律”字，若解释作“规律”，那么便是可以用于软件工程中的了。“道”是规律，如果明“道”，而可以变化无穷，这样做软件工程才是活的。就如同今人难于填词一样，不明道，则不明智，不明智则无所以为，因而在软件工程实施中不可避免的盲目与停滞。
“知律”的另一层意思，是在于“知道原理”。明白“为什么要这样”或者“为什么不是那样”。这在软件开发中是常见的问题，大多数人不知究竟地使用着技巧和方法，而一旦出了问题，则归究于这些技巧和方法的不好。
而真正的问题在于，这些人(我们通常叫做 Copy&Paster)并不知道这些技巧、技术和方法的原理，因而不知道变通，也不知道回避错误。
所以死读一本《软件工程》的人不会做真正的软件工程。
所以我写《大道至简——软件工程实践者的思想》。
周爱民(Aimingoo) 2013-08-24 22:39:52
評論集
暫無評論。
稱謂：
内容：
驗證：
返回列表