标签：
第九章 现实中的软件工程
理想状况下，软件工程=过程+方法+工具。然而工程成功的真正关键，并不在于你把你的团队“组织”得多好。即使在团队中他们都表现得有条不紊，你一样会面临失败。
愚公如果停下来，思考的问题可能是碎石的方法，而项目经理从细节中跳出来，思考的问题就应当是完成工程的方法。评价这个方法的好坏的标准只有一个：节约成本。
不计成本的项目计划不会得到经营者的支持，毫无目的地消耗成本是项目中的慢性毒药，最致命的风险是成本的枯竭。
我经常注意到的成本因素包括时间、人力、资金和客户成本。而大多数情况下，人们不会把客户的数量及耐心当作（客户）成本来计算。
OOP所基于的数据结构是对象(Object)，而AOP所基于的数据结构就是切面(Aspect)。Aspect在定义时没有确定的对象模块，本身只是对一个"对象模块群体"的观察视角，因此它更易于表现成接口——只有描述而没有实现。
AOP的三个概念：
指示(Advice)/拦截器(Interceptor): 考察这些对象以“达到什么样的目的”(即需求)；
引导(Introduction): 在目标上实现这些需求时，目标所需要表现出来的公共特性，引导特性可能需要配合编译器来实现；
元数据(Metadata): 如果需要，为既有对象实体再补充一些参考数据。
学习任何一种新的编程方法，你需要做的仅仅是回到工程最核心的环节：程序= 算法+结构+方法。
抛开实现的技术细节不论，在工程中，“以什么驱动开发”其实是一个过程的问题。而你应该明白，过程的选择(或制定)取决于你的工程需要，以及它在相关应用领域的适用性、过程工具的充备性和这个过程理论的完善程度，而不是大公司的鼓吹。
“敏捷”所表达的其实是对工程目标的尊重，是对人的创造性和主动性的尊重。“传统工程”所代表的则是规范和规模化。
无论多敏捷，如果具体的方法不能应用于“团队化的工程”，那敏捷本身就失去了工程价值。因此，为了应对“规模化”这个目标，敏捷宣言基于的前提是：工程团队认可敏捷的价值，遵循敏捷提出的价值观和基本原则。
因此，敏捷以及它的核心思想“敏捷软件开发宣言”，是以实现、实施、实践为主要手段，以体现人本位主要内涵的行为准则：
一种人本化、共有的团队特性与气质
一种契约型的团队组织结构和领导风格
一些以“解决问题”为中心的思想方法
极限实质上是使团队遵循这些“行为准则”的一些“形式化方法”。当然，极限在对一些工程要素的权衡上，也给出了建议和实践成果。
第十章 具体工程
作为合格的项目经理（或工程决策者），你必须要洞悉各种工程方法的应用环境、代价，也必须清楚所在团队或公司的规模与实力，同时还要了解团队的优点和弱点。只有充分评估这些因素，你才可能决策在具体的工程项目中应用的方法，或尝试之。
我们不必承诺可变性或兼容性，或以确定的抽象方法向不同角色描述系统，或具体解决方案必须面临未知的极端环境（复杂性）。
我们不必要求以某种形式上的美观或逻辑上严谨的方式来展示系统或目标。我们只需要找到最切实的手段来展示与实现目标。
我们不必保障解决方案的纯粹。我们尽可以在实施中选择各种复合方案，或者已经证明（或表面看来）并不完美的方案——前提是，你知道这个方案自身的问题与面临的问题域。
在谈论任何将工程“具体化”的方法与手段之前，我们必须首先提及的基本观念包括：
确认工程的本质需求是实现。任何时候，记住“实现”是第一要务，应将对假想或理论设想的探索放在下一个版本，应远离空想。
第一要务是确定具体工程的具体目标。任何时候，请确保这些目标是可叙述的、可回顾的、可表现为具体软件产品（或其特性）的。
而在具体的实施中，我们要保持灵活和切实的实践观念：
坚持：决策的前提与背景不变，决策不变；
置疑：任何看起来完美的东西都一定有问题；
开放：接受任何观点，知其所用。
在所有实践活动中最重要但也是最难保障的就是：控制规模。
“分类法”也是思维方法的问题，从思维法的角度来看，广义工程考虑的是对工程问题的“统治”，而具体工程则考虑的是“分治”。统而治之，寻求一个不变的方法固然是有可能的，但往往因循守旧，用旧法来治新病，新病未治了，又更添新病。而这就是软件工程界的现状。
所谓分治，关键就在于隔离问题域：
找到造成混乱的问题之间的关系，以及分类出无关的问题
把问题放到界面上去讨论，而不是放在里面去讨论
如果一个项目经理能把“我们要用什么方法，向着什么样的目标前进”这样的一件事情说清楚，那么项目也就成功了一半。
成功不能被复制，关键在于“它所处的背景”不能被复制。这种背景因素既包含那件事的时代背景，还包括成就那件事的人们的历史背景、文化背景，以及个性。
在具体工程的实践中，面对变化，灵活地调适组织、工程、方法与人，而后，反思。
标签：
原文地址：http://www.cnblogs.com/Ribbon/p/4511948.html
