读《大道至简》第七八章有感
今天我读了《大道至简》的第七章——现实中的软件工程和第八章——是思考还是思想。其中第七章主要讲了现实中的软件工程一些需要注意的地方。而第八章作者则分享了一些他自己在编程过程中的思考和思想。
下面是一些第七章的感想：
第一节：大公司手中的算盘。这一节主要讲的是一些大公司例如Borland 与IBM ，IBM 与SUN，以及SUN与Apple，他们一面打压对手的优势，一面又借助对手和同盟的力量来削弱自己的劣势或者补充实力，于是就出现了现在软件界相互制衡局面的出现。这些大公司在标准、理论、语言上的争来夺去，未必全然出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企图，其最终目的是在整个软件工程体系中的全面胜出。而所有这些公司就像棋盘上的棋子，只是用来计算胜负罢了。
第二节：回到工程的关键点。除了软件本力量的推动之外，商业因素也极大的推动了软件工程的发展。而作者在以前画的模型图中的关注点加了标注，于是就成了软件工程层状模型（EMH）。这个模型在“程序”与“方法”层面，关注于“实现”，在“过程”和“工程”
层面，考虑的首要问题是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为；而项目经理则保障团队的稳定性和一致性。但是这只是一种基本模式，或者说是理想模式。
第三节：思考项目成本的经理。这一节所讲的知识是说：作为一个项目经理，你可能今天的工作是写一份项目计划案，或者听测试部的报告，又或者是安排会议来听取和分析一个新的产品需求。但是这只是细节，一个好的项目经理更应该做好的是考虑好项目的成本，否则这个项目注定要失败。
第四节：审视AOP.首先我们要确定的是AOP不是语言而是方法论。我们提到过开发方法是基于一种数据结构的编程实践的结果。很显然，OOP所基于的数据结构是对象(Object) ，
而AOP所基于的数据结构就是方面(Aspect)。Aspect是在定义时没有确定的对象模块，只有描述而没有实现。既然我们已经会用 Acpect的思想来编程了,而这时你需要做的是，回到工程最核心的那个环节：编程＝算法＋结构＋方法。
第五节：审视MDA/MDD。MDA也是方法论层面上的名词，受MDA影响的开发活动称为MDD。而作者想要表达的是有许多方法都可以驱动开发，而在工程中，“以什么驱动开发”是一个过程问题，过程的选择(或制定) 取决于你的工程需要，以及它在相关应用领域的适用性、过程工具的充备性和这个过程理论的完善程度。MDA架构作为一个新的软件开发方法的架构，即使在技术研究、底层协议和软件实现方面经过了持续地完善而渐至成熟，但我们也不能将自己的项目直接不加审视的建立在这个架构上。
接下来是第八章的一些感想。
第一节：软件工程三个要素的价值。而所谓的三个要素则是：工具、方法与过程。虽然本书中将他们分开来思考，但他们实际是相互作用的。所以尽管本书割裂了软件工程的各个要素，并从每个孤立的层面来审视。然而实质上，你应该回归到软件工程的本体上来思考问题，而不是仅关注于每一个局部的要素。工程的这提问题仍然是“实现”。
第二节：其实RUP是一个杂物箱。这主要是说RUP像杂物箱一样包容了前人在软件过程思想内容。你可能 从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者是一根钓杆……
面对“软件开发”这样的一个需求，钓杆能有什么作用呢？只要你转化一下思维：钓竿可能带给你的团队精神上的激励。它就能转化成为生产力。至于RUP能不能被利用起来就要看你在“杂物箱”里取出东西后的辨识能力与组织能力了。
第三节：UML与甲骨文之间的异同。在你真的打算用甲骨文来写项目文档之前，请先明确UML与甲骨文之间的异同。UML 与甲骨文都是符号文字，都具有象形含义。然
而这并不表明UML符号本身能表达多么丰富的含义。如果要象甲骨文一样用几代人、上千册的论著去解释它，那么UML图的价值也就只剩下象征性的意义了。而在使用UML图的时候应有相关的文字来描述，否则下一个阅读UML的人将面对的将是无异于甲骨文出土是的困境。
第四节：经营者离开发者很远，反之亦然 。这节是说经营者不必离开发者很近，开发者同样不必接近经营者，因为他们有完全不同的的关注层面。而这就需要有一个好的项目及管理作为中间角色来够沟通好经营者与开发者之间的关系。
第五节：矛盾：实现目标与质量保障。我们看到，在项目的平衡三角( 时间、资源和功能) 中讨论的是目标问题，但并不讨论质量问题。也就是说，经典教材中总是关注：如何更快的完成项目，并减少资源占用，以及实现更多的功能。然而，即使平衡了这种关系，项目的结果仍可能产生一个天生的残障。如果原定的目标( 的整体) 本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧是保障不了质量。
第六节：枝节与细节。我们通常所说的细节，其实是对实施方法的一些有限量的描绘。比如“软件工艺”这个概念本身的提出，就是考究“细节问题”的。枝节是事实发展的次要的分枝，它不涉及行为本身，也不是对行为本身的考量。因此我在前面的文字中说到“跳出细节”，它本意是“跳出枝节”，细节只有做到何种程度的问题，而不并是关不关注。而在现实中大家却经常混淆这两个概念，所以作者提醒管理者：别管它是细节还是枝节，只要你感到你的脚趾已经沾上了泥淖，就快点回头。
第七节：灵活的软件工程。在软件开发中是常见的问题，大多数人不知究竟地使用着技巧和方法，而一旦出了问题，则归究于这些技巧和方法的不好。而真正的问题在于，这些人
并不知道这些技巧、技术和方法的原理，因而不知道变通，也不知道回避错误。所以我们不能指望死读一本《软件工程》就会真正的做软件，而是要学会变通。
总之，通过这两章，我更加了解了一些现实中的软件工程的实现及需要注意的问题，同时在软件的实现过程中要学会变通。