全书笔记

	* 编程的根本：顺序、分支和循环。
	* 程序=算法+结构。
	* 编程的第一要务是先把事情分析清楚，事件先后的逻辑关系和依赖关系搞清楚，然后再去代码实现。
	* 积极工作和勤于思考都要占时间。
	* 算法是对一个程序的逻辑实现的描述，而结构是逻辑实现所依附的数据实体。
	* 在所有的算法描述中，有且仅有三种执行逻辑：顺序、分支和循环。简单若顺序表，复杂如树、图，他们的算法都是用上面这三种执行逻辑来描述的。
	* 编程语言只有喜欢与不喜欢的问题，没有会不会的问题。任何的一门语言，你都可以在两周内掌握并开始熟练编程。
	* 通常而言，语言的差别主要表现在适用范围上。一些语言适合做数值处理，一些语言适合做图形处理，还有一些语言则适合于网页。
	* 人的精力终归是有极限的。提出新的“方法”，解决的将是影响做事成效的根本问题。
	* 所谓“面向过程开发”，其实是对“结构化程序设计”在代码阶段的一个习惯性的说法。面向过程开发中，“过程”是CPU提供的，“单元”则是编译器提供的。程序员不需要再造就什么方法，就可以进行愚公式的开发工作了。
	* 团队的基本特性：主从、监督和责任。
	* 从管理角度来看，项目失败与否与项目经理的经验直接有关。
	* 项目成功是两个方面的评估：项目完成质量和项目完成时间。
	* 经验丰富的工程师能尽可能接近的预估工期，但没有办法保障预估的工期市局对合理的。
	* 组织模式确定的同时，相应的制度也有随之建立。
	* 对于一个已经规范管理、体制健全的公司，但前提是制度的人性化和公平性。
	* 项目开始之前，管理者应该确定组织机构模式，或者为组织中的成员进程角色定位和分工。
	* 
	* 如果有一群开发人员像蚂蚁一样辛勤工作，那么，先不要打扰他们。你应该跟随他们，看看他们是如何做的。发现规律，分析这个规律的价值，最后再尝试改变那些负面价值的规律。
	* 确定被“弹性分工”的员工需要可以快速的转换到新的角色，但首要考察的并不是他是否“有能力”胜任这个角色。能力可以通过学习来增强，而角色的转换，则首先是思想的转换。
	* 更好的选择是明确分工，而不是弹性分工。
	* 怎样了解客户产生需求的信息点？客户在公司层面的外在表现、内部机制和运营管理手段；客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为和方向所提出的需求。
	* 然后开始设计提问，每一个提问涵盖尽可能多的信息点，尽可能的具有发散性以便形成更多的推论和假设。
	* 设计需求条目：分析用户的没一个表格，以构建基础数据库；分析每一条数据的含义以确定它的上下限，以及数据间的相关性；从工作文档中去了解客户的组织结构及其相互关系，同时确定了每一类使用该系统的角色；从报表中去了解客户关注的数据信息，以及被他们所忽略掉的数据信息。从而整理出系统结构和模块，得到模块间的相互关系图，并通过这个图分析了数据交叉关系，设计了相应的数据索引并增加了一些新的关系下数据。最终得到一个系统模型，与这个系统的每一类用户接触之后，让他们来操作并提出意见，得到一份详尽的调研报告。
	* 接下来完成这个项目的需求分析报告，以及在这个分析上的一些框架型的设计。还有，一个被用户所接受的原始模型。
	* History的丰富和准确为项目的后继开发、维护提供了可能。
	* 历史记录与注释不是一回事。参考记录内容——需求阶段（与谁联系，联系方式、过程、结果以及由此引发的需求或变更）；设计阶段（如何进行设计、最初的框架、各个阶段的框架变化、因需求变更导致项目结构上的变化）；开发阶段（每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测；程序单元的测试框架；每一个设计和构架变更所导致的影响）；测试阶段（测试用例和测试报告）。
	* 沟通问题不仅仅存在于与客户交流之中，还存在于与项目的各个角色之间。UML的确是解决沟通问题的最佳手段之一。但只要是行之有效的、能在各个项目角色之间通用的，就是好的沟通方式。
	* 在每一次回顾项目是都应该注意：流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。
	* 瀑布模型将软件开发的过程分成需求、分析、设计、开发和测试5个阶段。【定义：计划、可行性研究、需求分析；实现：系统设计、程序设计、编码与模块测试、组合与系统测试；维护：运行和维护】
	* 工程只是实现的一种途径。否则，我们做完了工程的没一个过程，却没有完成项目的每一个“实现目标”。
	* V模型在每一个环节中都强调了测试（并提供了测试的依据），同时又在每一个环节都对实现者和测试者的分离。由于测试者相对于实现者是一种监督、考察和评审的关系，因此它相当于在不断地做回顾和确认。适用于工程外包，模型的左端是外包给的团队或者公司，而右端则是本企业中有丰富经验的工程人员。
	* 过程理论中，如果懂得了所谓的模型原本都演化自那个简单的瀑布，那么文档是按XP写还是按RUP写，也就可以应时、应需，因地制宜，择善而从了。
	* 越是简单的东西，往往越是接近与本质。
	* 项目经理的工作，就是要去组织这个工程中的各个角色，使得分工明确，步调一致，共同完成这个项目。
	* 语言只是工具。
	* 
	* 编程的本源定义：程序=算法+结构。→长期的编程实践，自然的归演和总结，必须沉淀为某种方法，于是“过程”就出现了，于是“对象”就出现了，于是相关的方法论也就出现了。→过程伴生工程而出现，过程解决的是工程中角色间的关系问题，过程中的问题，就是角色、沟通和环节的问题。→工程是对目标的描述和成果的检测。至于这个工程目标的实现，是“过程”和“方法”的事，而使之快速实现所需的，就是“工具”。
	* 
	* 经验来源于回顾、理解和分析，而不是你将要写的下一行代码。
	* 哪些环节重要取决于具体的编程行为，也就是具体的项目。
	* 除了需求、配置和文档，项目经理还必须关注于人力资源、项目资金以及多个项目之间的协调等等。项目经理必须更关注于对这个工程的组织和计划。站在“组织者”这个角色上，需要考虑的内容可能会是：为项目的各个阶段建立计划，并逐渐的细化计划的内容，以及确立项目过程中的没一个环节、每一个计划阶段的优先级和复杂度；确立项目或者产品阶段目标，成果的准确描述、定位，以及整个项目的质量目标及其评核办法；对团队中的不同角色展开培训，以指导并协调角色之间的工作，从而消除因为工作习惯的差异带来的影响；为每一个人准备他所需要的资源，准确评估他的工作量，以及决定是否为他增加一个副手；决定在哪些环节上反复审核和回顾，而在哪些环节上采用较为宽松的方式以加快进度；习惯于开会、组织更短而有效的会议以及建立激励机制，也不要忘记让每一个成员意识到这一项目的风险；不要乐观。
	* 回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是项目经理的日常工作。
	* 发钱的决策通常是由三个角色来做出的：部门/团队经理；绩效经理；财务经理。
	* 真正的BOSS是经营者。决定了一个方向，组织者保证决策与这个方向是同步的，而工程师在这样的一个方向、决策的构架下的一个具体行为。
	* 实现，是软件开发的本质需求。方法，是对既有行为的归纳总结。
	* 正是出于实现的需要，才设计了一些数据结构或逻辑结构来映射物理模型。而后，基于某种数据结构的编程实践的不断积累，决定了软件开放方法理论的产生。为了实现更大规模的软件系统而有了团队组织模式，而团队的协作决定了过程模型的产生，在过程环节中的沟通问题导致了模块化语言的出现。
	* 在“程序”与“方法”层面，是关注于“具体的实现”的；而在“过程”和“工程”层面，更首要考虑的是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为；而项目经理则保障团队的稳定性和一致性。
	* 软件工程=过程+方法+工具
	* 项目经理从细节中跳出来，思考的问题就应当是完成工程的“方法”。评价这个方法的好坏的标准只有一个：节约成本。
	* 关于思考成本：不计成本的项目计划不会得到经营者的支持；毫无目的的消耗成本是项目中的慢性毒药；最致命的风险是成本的枯竭。
	* 成本因素包括时间、人力、资金和客户成本（数量以及耐心）。
	* 过程的选择取决于你的工程需要，以及它在相关应用领域的适用性、过程工具的充备性和这个过程理论的完善程度，而不是大公司们的鼓吹。过程模型决定了工程队的实施步骤和组织方式。
	* 思考问题的方法可以是由点及面的，也可以是统揽全局的。
	* 软件工程三要素：工具、方法与过程。
	* 项目经理这个中间角色就有了一种使命：协调经营者与开发者之间的沟通。