大道至简第七章第八章

大道至简第7、8章

第一节：大公司手中的算盘

      大公司们在标准、理论、语言上的争来夺去，未必出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企图，其最终目的是在整个软件工程体系中的全面胜出。

      算盘上的绝大多数人，只是用于计算胜负的一枚算子。

 第二节：回到工程的关键点

       因而，除了软件本质力量的推动之外，商业因素也推动着软件工程系的发展。大公司们的争夺战的最终结果，已经开始把软件工程，从原始的“自生演进”状态，逐渐推进到“它激发展”的状态上了。

       接着就出现了软件工程层状模型（EHM），其试图割裂工程元素，以使得工程角色定位以及各自视角更加清晰明确。而从这个模型可以看出，在“程序”与“方法”层面，是关注于“（具体的）实现”的；而在“过程”和“工程”层面，要首先考虑团队问题。

第三节：思考项目成本的经理

       理想状况下，“软件工程=过程+方法+工具”。工程成功的真正关键要思考项目的成本。

第四节：审视AOP

      AOP不是语言而是方法论，其所基于的数据结构是方面（Aspect），Java用类来实现Aspect。Aspect在定义时没有确定的对象模块，它本身只是一个“对象模块群体”的观察视角，因此它更易于表现成接口——只有描述而没有实现。它关注于“有相似需求的考察对象”的群体特征。其相似性在群体中表现得越广泛，则AOP的优势也就越明显。

AOP概念：指示/拦截器、引导、元数据。

第五节：审视MDA/MDD

       MDA讨论的是“创建出机器可读和高度抽象模型”的方法。受MDA影响的开发活动被称为MDD。

MDA架构作为一个新的软件开发方法的架构，如果没有成熟的软件理论支持，那么它在工程中的实用价值就有限。

第八章：是思考还是思想

第一节：软件工程三个要素的价值

      三要素：工具、方法与过程，工程的整体问题仍旧是“实现”。

第二节：其实RUP是一个杂物箱

      RUP能够包容全部的已知理论，而RUP能不能被利用起来，取决于辨识能力和组织能力。

第三节：UML与甲骨文之间的异同

       一方面UML的规范中没有提供一个标准来衡量“怎样的UML图是描述充分的”；另一方面，UML作为一个语言，也无法直接在某个硬件平台中被语法检错和调试。所以在工程中使用UML图应该有相应的文字来描述他。

第四节：经营者里开发者很远，反之亦然

      因为角色的关注层面完全不同，所以经营者与开发者之间有很远的距离，项目经理就需要协调经营者与开发者之间的沟通。

第五节：矛盾：实现目标与保障质量

      在项目实施过程中，需要平衡时间、资源和功能（平衡三角）。其讨论的是目标问题，并没有讨论质量问题。于是项目实施过程中实现目标与保障质量是矛盾的。

第六节：枝节与细节

       

枝节是事实发展的次要的分枝，它不涉及行为本身，也不是对行为本身的考量。细节只有做到何种程度的问题，而不并是关不关注(或做不做)的问题。

第七节：灵活的软件工程

      “知律而变”中的“律”字，若解释作“规律”，那么便是可以用于软件工程中的了。“道”是规律，如果明“道”，而可以变化无穷，这样做软件工程才是活的。“知律”的另一层意思，是在于“知道原理”。明白“为什么要这样”或者“为什么不是那样”。这在软件开发中是常见的问题，大多数人不知究竟地使用着技巧和方法，而一旦出了问题，则归究于这些技巧和方法的不好。

转载于:https://www.cnblogs.com/muamu/p/4954157.html