前三章
程序究竟是什么？1）给计算机的一系列指令2）计算机依据指令进行的操作第一种定义是程序员写程序时所用的第二种是使用程序的普通用户所用的程序员面对的是字母和符号，用户看到的是最终结果--计算机执行的操作。所以，计算机程序其实是这两者的混合体：程序员的指令，计算机执行的操作。除软件开发之外，没有任何领域的指令和结果联系得这么紧密。比如设计房子，建筑师给出指令，也就是蓝图。经过很多人的手，很长时间，才执行，才建起房子。房子是大家所有人解读建筑师指令的结果。相反，写程序时，计算机绝对服从命令，没有其他人，结果的质量完全取决于机器的质量，我们想法的质量，代码的质量。三个因素当中，代码的质量是软件工程要面对的重要问题。大多数内容在讨论怎样改善你交给机器的指令的结构和质量。为了改进结果，提高代码质量是最重要的问题，需要掌握提高代码质量的科学方法。
缺失的科学：
为某种创造性活动而制订，但尚未实施的计划。例句：确定了桥梁的设计
业已存在的创造物所遵循的计划，如:那座桥的设计相当不错
程序代码结构
速度重要，容易阅读重要
为满足需求，选择哪种编程语言
公司的机构怎样
什么时候召开团队会议
程序员工作时间如何安排
程序员绩效如何考核
这些决策与软件本身无关，只与组织有关。有些失败是由于管理。但不是本书主题，本书关注的是，如何为你的软件制订合理的技术决策。
与架构有关的技术决策，以及开发系统中的技术决策，都可以归到“软件设计”的范畴里
什么是设计？
动词：为创造性活动制订计划。比如，工程师本月会设计一座桥梁，下个月建造它。
名词：
动词时，计划活动，关心的事，代码结构，所用技术，制订技术决策，通常我们只是在脑子里做这些决定，有时候会把它写下来或画出来。
上一步的结果是软件的设计，名词，可能是落实下来的文档，也可能是我们脑中的若干决定。
已经存在的设计，它的结构，或它所遵循的计划。无设计的，完整的设计，之间存在着广阔的灰色地带，比如部分的设计，若干矛盾的设计，接近完成的设计等等。一些刻意而为的糟糕设计甚至比无设计还要差劲。
软件设计的科学就是为软件做计划，制定决策的科学，这些决定：
与下列问题无关：
程序员也是设计师：
在软件项目中，首席程序员负责设计程序的总体架构；高级程序员负责大的模块；普通程序员设计自己的那一小块，甚至只是某个文件的一部分。一行代码，也包含设计的因素。
身为设计师，必须时时愿意聆听建议和反馈。但是考虑了所有这些后，任何决策都必须由单独的个人而不是一群人来做出。
如果你是推翻决策的那个人，要教育别人。为什么新决策比原来好。让他们学习，如果从来也不学习，还是做出成堆的糟糕决策，这种人应该清理出团队。
软件设计的科学：
科学必须包含汇总而来的知识。必须包含事实而不是意见，且这些事实必须汇总起来。比如集结成书。
这些知识必须具有某种结构。知识必须能分类，其中的各个部分必须能够依据重要性之类的指标，妥善建立起与其他部分的联系。
科学必须包含一般性的事实或者基本的规则。
科学必须告诉你在现实世界中如何做一些事情。它必须能够应用到工作或生活中。
通常，科学是经由科学方法来发现或证明的。科学方法必须观察现实世界，提炼出关于现实世界的理论，通过验证理论，而且这些实验必须是可重复的。这样才能说明理论是普适的真理，而不仅仅是巧合或者特例。
一门学问要成为科学，必须符合下列标准：
软件领域，已经有了知识，有了结构，但忽略了最重要的部分：清楚表述出来的规则law。规则是恒常不变的事实，一旦掌握了它们，人就不会犯错。
不但要知道怎么做是正确的，而是为什么这么做，判断正确和错误的标准在哪里。
软件设计的基础规则是什么？
书中列出了关于软件开发的若干定义，事实，规则，定律，它们的着眼点大多在于软件设计。Definition，Fact，Rule，Law区别？
Definition定义告诉你事物是什么，应当如何使用。
事实是关于事物的真实陈述。每一点真实的信息都是事实。
条例是给你的确切建议，它包含某些具体的信息，用于制定决策。但是，条例并不能帮你绝对地预测未来，也不能帮你发现其他真理。它们通常会告诉你是否需要采取某些行动。
规则是永远为真的事实，它涵盖了很多领域的知识。它们帮你发现其他重要的真理，帮你预测未来要发生的事情。
若是你以为你这些都知道了，你这么想的时候应该问问自己：
我是否知道，某些特定的说法是否经过了证实
我是否清楚它的重要性
我是否可以向其他人清楚讲解，让对方彻底明白
我是否明白，在软件开发领域中，它与其他部分知识的关系如何
区分某些说法到底是科学，或者仅仅是想法的集合。
软件设计可以成为科学。咨询顾问要把软件设计新方法拿出去换钱。
软件设计是有章（规则）可循的，它们可以被认识，可以被理解。规则是永恒不变的，是基本的事实，而且确实可行。
检验这些规则，能否想到关于软件开发的，使用范围更广或者更基础，更深入的普适真理。真实基本的定律或规则。
之前为什么不存在软件设计科学？
今天计算机来源于数学家的设计，它最初纯粹是一种抽象的设备，数学家想用机器来代替人脑来解决数学问题。计算机科学正是对信息处理所做的数学研究。
不过，最早计算机是有计算机科学家指挥下，由经验丰富的电子工程师制造出来的。
@人月神话：项目延迟的情况下，增加更多的程序员，只能加剧延迟。对编程及软件开发管理的观察相当有价值。
之后涌现出了大量的软件开发方法：Rational统一过程，能力成熟度模型，敏捷软件开发，等等。它们是管理软件开发复杂性的手段，无一标榜自己是科学。
现状：方法众多，真正的科学却缺席。
软件管理的科学告诉我们的是，如何为程序员分派工作，如何制定发布计划，如何估量任务所需的时间，诸如此类。这是一门显学，上述的各种方法强调的正是这一点。在这个领域中，存在着彼此矛盾却各有道理的观点，这说明软件管理的基本规律尚未被认识。不过，大家已经关注到了这个问题。
但软件设计的科学在现实的编程中，却没有什么人关注。动手写代码吧！
本书要讲的并不是计算机科学，那属于数学研究。本书提供的是“实际干活的程序员”所需科学的入门部分---在任何语言中编写程序时都应当遵循的若干基础定律和规则。这种科学与物理和化学一样可靠，它告诉你如何编写程序。
软件设计的变化太逗了，无法用简单，基础的规则来描述，这是一种说法。还有人说，理解物理世界是不可能的，因为世界是神创造的，但神是不可知的。可是我们确实已经发现了物理世界的规律。
所以，除非你相信计算机是不可知的，否则，软件设计的科学是必然会存在的。
也有人说，编程纯粹是一门艺术，服从于程序员的个人爱好。这么说有点道理，在科学应用的任何领域，都存在着不少艺术的成分，但是他们背后必然有科学存在。只可惜，一片空白。
其实，软件复杂性的主要根源在于缺乏科学。如果程序员有科学指导，知道该如何开发简单的软件，就不会有这么多的复杂性问题，也不需要运用令人发狂的过程来管理这些复杂性。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$软件设计的推动力
在编写程序时，我们应当知道自己为什么要编程，最终目标时什么。
其实，全部软件都有一个相同的目标：帮助其他人。（这个目标比任何规则都重要）
具体软件有具体目标。有些软件是帮助特定人群的。服务于动植物，真正目的，还是帮助人类。
即使是程序库，也是为程序员服务，而不是为计算机。
帮助的定义：（让人）能更容易地做某事；帮忙；协助。特指完成部分工作，减轻或者分担工作量。
你可以帮很多忙，做规划，制订食谱等，想干什么取决于你。
赚钱，或炫耀智商，都是狭隘的帮助，是偏离目标的。无可厚非。
任何情况下，你所赚的钱都直接维系于你的软件能为他人提供多少帮助。事实上，决定软件公司收入的两个主要因素基本就是组织水平（包括行政，管理，推广，销售等方面），以及软件对他人的帮助。
一个人写出优秀软件的潜力，完全取决于他在多大程度上理解了“帮助其他人”的思想。
总的来说，在做与软件有关的决策时，指导法则就是判断能提升什么样的帮助，请记住，帮助有很多种，帮大忙，帮小忙，帮很多人，帮少数人。
各项需求也可以照这个标准排出先后顺序，哪项需求能为人们提供最大的帮助，就应当赋予最高的优先级。关于需求的优先级，还有很多可以补充，但在评估开发和维护软件系统的建议时，“它能给用户帮多少忙”绝对是一个重要而且基础的问题。
这样思考，有助于澄清功能描述或实现方式中的模糊之处。上面关于快捷键的描述说明，它的响应必须很快，因为快捷键的价值就在这里。
这样思考，有助于团队确认功能的价值。有些人可能不喜欢快捷键，但是每个人都应该认同上面关于其价值的解释。可能想出更好的办法。如果问题的答案可以引出更好的想法，就应该去实现。问题的答案告诉我们的是真实的需求，而不是用户以为的需求。
这样思考，某些功能会凸显出更重要的价值。这有助于项目领导分配优先级。
退一万步说，如果编辑器因为堆叠了过多功能而臃肿，可以根据这些答案决定删减哪些功能。
真实应用：如何才能把软件的目标落实到真正的项目中去呢？先决定软件的目的，要简单，不妨先定位“帮助程序员编辑文本”。若具体目标尚存分歧，且从最简单的形式开始吧。
目标定了，来看需要完成的功能。针对每一条功能，我们都要问自己，“这个功能怎么样帮助程序员编辑文本呢？”。检查过一遍之后，对剩下的每个需求，要写下一个短句作为答案。如果写下来显得多余，只要保证自己明白这一点就好了。
之所以要这样问自己，是因为还存在其他有价值的理由：
我们还需要列一张bug清单，方便检查和反思：这个bug如何影响程序员编辑文本，有时候答案很明显，那不需要写。
要把软件的目标落实到真正的工作中，还有很多办法，这里只给出了几个例子。
【软件设计科学的目标】
了解了软件设计的目标之后，就可以确定软件设计的科学的基本方向了。
目标是：确保软件能够提供尽可能多的帮助。
第二个目标是：确保软件能持续提供尽可能多的帮助。
在今天，编写和维护有帮助的软件的主要障碍在于设计和编程。如果软件很难开发或修改，程序员的主要精力就花在让软件能用上，而没有精力去帮助用户。如果系统易于修改，程序员就会有更多的余力去帮助用户，不必费心于编程细节。同样道理，软件的维护难度越低，程序员确保软件能持续提供帮助的难度也越低。
第三个目标：设计程序员能尽可能简单地开发和维护的软件系统，这样的系统才能为用户提供尽可能多的帮助，而且能持续提供尽可能多的帮助。
第一个和第二个目标的指引是非常重要的。推动实现第三个目标的，就是确保软件现在能提供帮助，将来仍然能帮助。
第三个目标很重要，否则就没法完成前两个目标。所以应该不会冲突。