代码大全2阅读笔记 9~1

第一部分 打好基础

第一章 欢迎进入软件构建的世界

 

软件构建是软件开发的核心活动;构建活动是每个项目中唯一一项必不可少的工作。

软件构建的主要活动包括:详细设计、编码、调试、集成、开发者测试(developer testing）(包括单元测试和集成测试）。

构建也常被称作“编码”和“编程”。
构建活动的质量对软件的质量有着实质性的影响。

 

第二章 用隐喻来更充分地理解软件开发

 

通过把软件的构建过程比作是房屋的建设过程，我们可以发现，仔细的准备是必要的，而大型项目和小型项目之间也是有差异的。

 

通过把软件开发中的实践比作是智慧工具箱中的工具，我们又发现，每位程序员都有许多工具，但并不存在任何一个能适用所有工作的工具，因地制宜的选择正确工具是成为有效编程的程序员的关键。 

 

第三章 三思而后行：前期准备

 

准备工作的中心目标就是降低风险：一个好的项目规划者能够尽可能早的将主要的风险清除掉，以使项目的大部分工作能够尽可能平稳的进行。目前，软件开发中最常见的项目风险是糟糕的需求分析和糟糕的项目计划，因此准备工作就倾向于集中改进需求分析和项目计划。

你所从事的软件项目的类型对构建活动的前期准备有重大影响--许多项目应该是高度迭代式的，某些应该是序列式的。

如果没有明确的问题定义，那么你可能会在构建期间解决错误的问题。（找到需要打的靶）

如果没有做完良好的需求分析工作，你可能没能觉察待解决的问题的重要细节。（瞄准靶，选择好箭的飞行路线）

如果没有做完良好的架构设计，你可能会在构建期间用错误的方法解决正确的问题。架构变更的代价随着“为错误的架构编写的代码数量”增加而增加，因此，也要确认“架构”已经到位了。（根据距离的远近以及环境，选择适合的弓箭，安排每支箭的力度角度策略，力求最少的箭枝射中靶心）

架构包括：程序组织（主要构造块）、主要类、数据设计、业务规则、用户界面设计（如果需求阶段没有）、稀缺资源管理、安全性、性能、可伸缩性、互用性、国际化本地化、输入输出、错误处理、容错性、架构的可行性、过度工程（部分代码健壮，部分不健壮）、关于买还是造的策略、关于复用的策略、架构的总体质量、需求变更策略。

（评价：系统分析--类图静态、业务顺序图状态；业务类图--数据存储；通用类业务--平台框架组件）

 

 

第四章 关键的“构建”决策

 

本章关注的焦点是程序员和技术带头人必须（直接或间接）负责的准备工作。在向工地进发之前，如何选择合适的工具别在你的腰带上，你的手推车里该装哪些东西。

在高质量的软件中，你可以看到“架构的概念完整性”与“其底层实现”之间的关系。“实现”必须与（指导该实现的）“架构”保持一致，并且这种一致性

 

 

是内在的、固有的。这正是变量名称、类名称、子程序名称、格式约定、注释约定等这些针对“构建活动”的指导方针的关键所在。

假如没有一种统一的规则，你创作出来的东西将会充斥着各种不同的风格，显得混乱而邋遢。这些不同的风格将使你的大脑承受沉重负担--而这仅仅是为了理解不同编程风格之间的（本质上是随意的）差异。 

 

大多数重要的编程原则并不依赖特定的语言，而依赖于你使用语言的方式。

 

在开始编程之前，做好一些约定。“改变代码使之符合这些约定”是近乎不可能的。 

 

 

第二部分 创建高质量的代码

第五章 软件构建中的设计

 

无论是以何种方式来进行设计，小型项目也能和大型项目一样从精心的设计之中获益，而如果能认识到设计是一项明确的活动，你就更会获益匪浅。

 

5.1 设计中的挑战

 

设计是一个险恶的问题。你必须首先把这个问题“解决”一遍以便能够明确的定义它，然后再次解决该问题，从而形成一个可行的方案。

设计是个了无章法的过程（即使它能得出清爽的成果）。因为在此过程中你会犯很多的错误。还因为优劣设计之间的差异往往非常微妙。还因为你很难判断设计何时算是“足够好”了。设计到什么细节才算够？有多少设计需要用形式化的设计符号完成，又有多少设计可以留到编码时再做？什么时候才算完成。

设计就是确定取舍和调整顺序的过程。

设计受到诸多限制。

设计是不确定的。

设计是一个启发式过程。

设计是自然而然形成的。他是不断的设计评估、非正式讨论、写试验代码以及修改试验代码中演化和完善的。

 

5.2 关键的设计概念

 

软件的首要技术使命：管理复杂度

作为软件开发人员，我们不应该试着在同一时间把整个程序都塞进自己的大脑，而应该试着以某种方式去组织程序，以便能够在一个时刻可以专注于一个特定的部分。

所有软件设计技术的目标都是把复杂问题分解成简单的部分。子系统间的相互依赖越少，你就越容易在同一时间里专注问题的一小部分。精心设计的对象关系使关注点相互分离，从而使你能在每个时刻只专注于一件事情。在更高汇聚的层次上，包（packages）提供了相同的好处。

保持子程序的短小精悍也能帮助你减少思考的负担。从问题的领域着手，而不是从底层实现入手去编写程序，在最抽象的层次上工作，也能够减少人的脑力负担。

一个程序中的设计层次。系统1首先被组织为子系统2子系统被进一步分解为类3然后类又被分解为子程序和数据4每个子程序的内部也需要进行设计

 

5.3 设计构造块：启发式方法

 

找出现实中的对象。在确定设计方案时，首选且最流行的一种做法便是“常规的”面向对象设计方法，此方法的要点是辨别现实世界中的对象以及人造的对象。

形成一致的抽象。

封装实现细节。当继承能简化设计时就继承。

隐藏秘密（信息隐藏）。信息隐藏中所说的秘密主要分为两大类：隐藏复杂度；隐藏变化源。问题“这个类需要隐藏些什么？”正切中了接口设计的核心。在设计的所有层面上，都可以通过询问该隐藏些什么来促成好的设计决策。

找出容易改变的区域。

预料不同程度的变化。

保持松散耦合。

查阅常用的设计模式。

下列的启发式方法有时也很有用：高内聚性、构造分层结构、严格描述类契约、分配职责、为测试而设计、避免失误、有意识的选择绑定时间、创建中央控制点、考虑使用蛮力、画一个图、保持设计模块化

 

5.4 设计实践

 

分而治之

自上而下和自下而上的设计方法

建立试验性原型

合作设计

要做多少设计才够

记录你的设计成果

要点

软件的首要技术使命就是管理复杂度。以简单性作为努力目标的设计方案对此最有帮助。

简单性可以通过两种方式获取：一是在同一时间所关注的本质性复杂度的量，二是避免生成不必要的偶然的复杂度。

设计是一种启发式的过程。固执于某一种单一方法会损害创新能力，从而损害你的程序。

好的设计都是迭代的。你尝试设计的可能性越多，你的最终设计方案就会变得越好。

信息隐藏是个非常有价值的概念。通过询问“我应该隐藏些什么？”能够解决很多困难的设计问题。 

 

 

 

 

 

   文章参考https://wenku.baidu.com/view/d856fb1ba8114431b90dd859.html#