《大道至简》第七、八章读后感
在结束这一学期的Java语言课的时候，首先很高兴能师从王老师学习Java，并且学到了好多东西，虽然Java课时结束了，但Java的学期才刚刚入门，所以在之后还有更大的挑战等着我，所以，今后的学习才是重中之重。
现实中的软件工程
理想状况下，软件工程=过程+方法+工具。然而工程成功的真正关键，并不在于你把你的团队“组织”得多好。即使在团队中他们都表现得有条不紊，你一样会面临失败。
愚公如果停下来，思考的问题可能是碎石的方法，而项目经理从细节中跳出来，思考的问题就应当是完成工程的方法。评价这个方法的好坏的标准只有一个：节约成本。
不计成本的项目计划不会得到经营者的支持，毫无目的地消耗成本是项目中的慢性毒药，最致命的风险是成本的枯竭。
我经常注意到的成本因素包括时间、人力、资金和客户成本。而大多数情况下，人们不会把客户的数量及耐心当作（客户）成本来计算。OOP所基于的数据结构是对象(Object)，而AOP所基于的数据结构就是切面。切面在定义时没有确定的对象模块，本身只是对一个"对象模块群体"的观察视角，因此它更易于表现成接口——只有描述而没有实现。
学习任何一种新的编程方法，你需要做的仅仅是回到工程最核心的环节：程序= 算法+结构+方法。抛开实现的技术细节不论，在工程中，“以什么驱动开发”其实是一个过程的问题。而你应该明白，过程的选择(或制定)取决于你的工程需要，以及它在相关应用领域的适用性、过程工具的充备性和这个过程理论的完善程度，而不是大公司的鼓吹。
“敏捷”所表达的其实是对工程目标的尊重，是对人的创造性和主动性的尊重。“传统工程”所代表的则是规范和规模化。无论多敏捷，如果具体的方法不能应用于“团队化的工程”，那敏捷本身就失去了工程价值。因此，为了应对“规模化”这个目标，敏捷宣言基于的前提是：工程团队认可敏捷的价值，遵循敏捷提出的价值观和基本原则。
因此，敏捷以及它的核心思想“敏捷软件开发宣言”，是以实现、实施、实践为主要手段，以体现人本位主要内涵的行为准则：
一种人本化、共有的团队特性与气质，一种契约型的团队组织结构和领导风格，一些以“解决问题”为中心的思想方法，极限实质上是使团队遵循这些“行为准则”的一些“形式化方法”。当然，极限在对一些工程要素的权衡上，也给出了建议和实践成果
是思考还是思想
角色的关注层面完全不同。
在需求阶段我们就会面临“目标”的问题，然而（在大多数的时候），与此相反的是我们会在项目交付和试用时才碰到客户在质量上的投诉。
目标可能在平衡中确立，但质量却要在过程中控制。即使在时间、资源和功能三者中取得了平衡，即使客户、项目组和公司同样满意于这个平衡的“目标”，它仍然有可能是“不能实施”的。
如果原定的目标（的整体）本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧保障不了质量。
大多数人不知就里地使用着技巧和方法，而一旦出了问题，则归咎于这些技巧和方法的不好，而真正的问题在于，这些人并不知道这些技巧、技术和方法的原理，因而不知道变通，也不知道回避错误。