软件详细设计专题讲座课件

软件详细设计

讲座主讲人：软件详细设计

讲座主讲人：内容第二部分：软件设计第一部分：软件架构内容第二部分：软件设计第一部分：软件架构第一部分

软件架构内容第一部分

软件架构内容需求/架构/设计关系需求/架构/设计关系软件架构定义什么是架构？如果你问五个不同的人，可能会得到五种不同的答案。很多人都试图给“架构”下定义，而这些定义本身却很难统一。软件架构是一种无法以简单的一维方式进行说明的复杂实体。软件架构（softwarearchitecture）是一系列相关的架构视图，用于指导大型软件系统各个方面的设计。多重软件架构视图之所以必不可少，是因为各类型人员（用户、开发人员、测试人员、维护人员、操作人员）需要从各自的角度理解和使用架构。软件架构定义什么是架构？如果你问五个不同的人，可能会得到五种软件架构的实际意义做正确的架构正确的表达架构让别人能遵守架构软件架构的实际意义做正确的架构软件架构视图单一的视图无法完整的表达架构，因此需要具备完整的视图集。软件架构视图是从特定的视角出发，专注于该视角系统的结构、模块划分、基本组件职责和主要控制流。软件架构视图的四要素：图示化主要元素和元素之间的关系。具有明确的图例、定义和说明元素。每个元素具备明确的接口和行为规范。设计的原理和设计决策信息。。软件架构视图单一的视图无法完整的表达架构，因此需要具备完整的常见软件架构视图逻辑视图开发视图部署视图进程视图场景视图数据视图实现视图常见软件架构视图逻辑视图”4+1”模式逻辑视图开发视图进程视图部署视图场景视图”4+1”模式逻辑视图开发视图进程视图部署视图场景视图逻辑视图面向对象：客户/用户/开发组织管理者。视角：系统的功能元素，以及它们的接口、职责、交互等。主要元素：系统、子系统、功能模块、子功能模块、接口用途：开发组织划分，成本/进度评估逻辑视图面向对象：客户/用户/开发组织管理者。逻辑视图样例一系统框架图逻辑视图样例一系统框架图逻辑视图样例二软件结构图逻辑视图样例二软件结构图逻辑视图样例三前置子系统结构图逻辑视图样例三前置子系统结构图逻辑视图样例四监控子系统结构图逻辑视图样例四监控子系统结构图逻辑视图样例五防误子系统结构图逻辑视图样例五防误子系统结构图开发视图面向对象：开发相关人员/测试人员视角：系统如何开发实现主要元素：描述系统的层、分区、包、框架、系统通用服务、业务通用服务、类和接口、系统平台和相关基础框架用途：指导开发设计和开发实现开发视图面向对象：开发相关人员/测试人员开发视图样例一开发视图样例一开发视图样例二对象请求代理ORB开发视图样例二对象请求代理ORB开发视图样例三复制数据库技术架构开发视图样例三复制数据库技术架构开发视图样例四进程和服务管理开发视图样例四进程和服务管理开发视图样例五数据库专用平台开发视图样例五数据库专用平台开发视图样例六前置子模块间关系开发视图样例六前置子模块间关系部署视图也称物理视图面向对象：系统集成商/系统运维人员视角：系统逻辑组件到物理节点的物理部署、节点之间的物理网络配置主要元素：物理节点以及节点的通讯用途：指导系统采购以及网络、节点布局部署视图也称物理视图部署视图样例一部署视图样例一部署视图样例二部署视图样例二部署视图样例三部署视图样例三部署视图样例四部署视图样例四进程视图面向对象：性能优化/开发相关人员视角：系统运行时线程/进程的情况主要元素：系统进程/线程以及处理队列等用途：指导系统进程/线程分布进程视图面向对象：性能优化/开发相关人员进程视图样例进程视图样例场景视图也称用例视图面向对象：设计和开发人员视角：囊括了架构上最重要的场景（最典型或最有风险）及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素的运行方式。场景视图也称用例视图场景视图样例一场景视图样例一场景视图样例二场景视图样例二数据视图面向对象：数据架构师/开发相关人员视角：系统数据模型以及数据存储/存取方式主要元素：系统的核心实体模型以及相应的数据存储模型和存储方式系统的数据存储相关策略系统核心的数据流数据视图面向对象：数据架构师/开发相关人员数据视图样例一数据视图样例一数据视图样例二RAC模式数据视图样例二RAC模式数据视图样例三HA模式数据视图样例三HA模式数据视图样例四DataGuard模式数据视图样例四DataGuard模式总结架构设计以多视图的模式呈现多视图的目的是为了指导不同的团队思维和实现多视图是分而治之的多视图可以并行多视图可以组合总结架构设计以多视图的模式呈现第二部分

软件设计内容第二部分

软件设计内容内容软件设计金字塔软件设计的价值观优秀设计遵循的原则破窗效应和技术债务代码的坏味道重构技术内容软件设计金字塔设计金字塔设计金字塔关注软件维护成本软件系统维护工作量所占比重超乎想象！！！COST(total)=COST(develop)+COST(maintain)COST(maintain)=Cost(understand)+(理解)Cost(change)+(变更)Cost(test)(测试)Cost(depoly)(现场部署)关注软件维护成本软件系统维护工作量所占比重超乎想象！！！什么是好的设计?关注软件的可维护性和可复用性区分功能需求和非功能需求一个好的设计应该有如下性质：可扩展性、灵活性、可插入性可扩展性：新的功能可以很容易的加入到系统中灵活性：可以容许代码修改平稳，而不会波及到很多其他模块可插入性：可以很容易的将一个类抽出去，同时将另一个有同样接口的类加入进来什么是好的设计?关注软件的可维护性和可复用性软件的可维护性大家有没有注意到，原来我们自认为是很漂亮的设计随着时间的推移慢慢“发出腐化的臭味”，代码也会慢慢变成由一堆纠缠不清的函数和变量搅和在一起的“代码浆糊”，为什么？是什么原因导致的呢？--都是客户和老板的错！客户不断的改变需求。如果用户的要求仅限于他们最初所声明的，我们的设计就没有问题，错就错在用户改变了他们的需求。老板没有给我们充足的时间，进行充分的分析，使我们没有时间设计出一个完美的结构。软件的可维护性大家有没有注意到，原来我们自认为是很漂亮的设计软件的变更软件是应该不断变更的。我们认为,真实世界中使用的程序必须进行变更，否则它在环境中的作用就会原来越小。软件复杂增加性法则：随着一个不断演进程序的变更，他的结构会变得越来越复杂。软件是应该不断变更的，因为需求是不断变更的。难道变化的需求一定会导致系统“腐烂”吗？为什么一个系统的设计不可以为以后的变化留出足够的空间？如何实现一个优秀的设计？软件的变更软件是应该不断变更的。我们认为,真实世界中使用的程优秀设计原则优秀设计第一法则：开闭原则优秀设计第二法则：重构优秀设计原则优秀设计第一法则：开闭原则开闭原则开放-封闭原则（OCP）软件的组成实体（类、模块、函数等等）应该是可以扩展的，但是是不可修改的。即软件实体可以通过增加新代码实现扩展，但是不能修改已有代码。任何一个系统在其生命周期内都会发生变化。如果我们希望开发出的系统不会在第一版本后就被抛弃，我们就必须牢记这一点。开闭原则开放-封闭原则（OCP）发现变化并将其封装优秀设计精髓就是封装变化，就是将变化进行抽象，封装变化，这样才能保证软件的可扩展性以及模块间的松耦合。一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里。一种可变性不应当与另一种可变性混合在一起。发现变化并将其封装优秀设计精髓就是封装变化，就是将变化进行抽共性和可变性分析(CVA)找到变化的地点，称为“共性分析”然后找出如何变化，称为“变性分析”CVA分析步骤先寻找共性；从这些共性创建抽象；从共性的变化派生可变性实现；看共性与其他共性之间的关系如何；共性和可变性分析(CVA)找到变化的地点，称为“共性分析”CVA样例主板和插槽CVA样例主板和插槽开闭原则的代价100%开闭原则的代价：遵循开闭原则代价昂贵，正确的抽象（寻找共性并抽象）需要时间和精力，需求的不可预测性，给抽象增加了复杂度。对于应用程序中的每个部分都肆意的进行抽象同样不是一个好主意。应该对程序中呈现频繁变化的那些部分进行抽象。拒绝不成熟的抽象和抽象本身一样重要。开闭原则的代价100%开闭原则的代价：亡羊补牢-重构面对需求的不可预测性，设计师根据经验猜测程序可能遭受的变化，如果猜测正确，获得成功，猜测错误，遭受失败。随着需求的不断变化，软件的不断变更，“设计腐化”和“代码浆糊”的现象慢慢呈现出来。为了解决这个问题，我们需要应用优秀设计的第二法则：优秀设计需要不断重构。重构到优秀设计。亡羊补牢-重构面对需求的不可预测性，设计师根据经验猜测程序可拙劣设计的影响如果设计已经出现腐化，代码浆糊已经开始产生，我们最初的设计已经成为拙劣的设计了，我们不去重构的话，将会产生“破窗效应”和“技术债务”问题。拙劣设计的影响如果设计已经出现腐化，代码浆糊已经开始产生，我破窗效应破窗理论破窗效应(BreakPaneLaw)

没修复的破窗，导致更多的窗户被打破破窗效应破窗理论破窗效应(BreakPaneLaw)

破窗效应破窗效应：没修复的破窗，导致更多的窗户被打破所谓“破窗效应”，是关于环境对人们心理造成暗示性或诱导性影响的一种认识。“破窗效应”理论是指：一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙的被人打破；一面墙，如果出现一些涂鸦没有清洗掉，很快的，墙上就布满了乱七八糟，不堪入目的东西。一个很干净的地方，人们会不好意思丢垃圾，但是一旦地上有垃圾出现之后，人们就会毫不犹疑的拋，丝毫不觉羞愧。这真是很奇怪的现象破窗效应破窗效应：没修复的破窗，导致更多的窗户被打破技术债务“出来混，迟早要还的”技术债务“出来混，迟早要还的”技术债务(TechnicalDebt)开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案，但从长远来看，这种方案会带来更消极的影响，亦即开发团队所欠的债务技术债务类似于金融债务，它也会产生利息，这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多努力的后果。我们可以选择继续支付利息，也可以通过重构之前鲁莽的设计来将本金一次付清。虽然一次性付清本金需要代价，但却可以降低未来的利息技术债务(TechnicalDebt)开发团队在设计或架技术债务技术债务的种类无意的——由于经验的缺乏导致初级开发者编写了质量低劣的代码。有意的——团队根据当前而非未来进行设计选型，这种方式可能很快就能解决当前的问题，但却很拙劣技术债务技术债务的种类技术债务很多敏捷团队都能认识到技术债务相关的罪状。就跟财务上的负债一样，技术债务也会产生利息。要支付这些利息，就要付出额外努力维护和改进正在“腐化”或基础并不牢固的软件。诸多敏捷人士推荐尽早偿还技术债务。然而，大多数敏捷团队无法成功以金钱的方式计算技术债务，因此无法得到有价值的深入理解和思考技术债务很多敏捷团队都能认识到技术债务相关的罪状。就跟财务上技术债务技术债务代码的坏味道产生破窗效应和技术债务的一个原因就是代码产生了坏味道。代码坏味道是指在代码之中潜在问题的警示信号，并非所有的坏味道所指示的确实是问题，但大部分坏味道需要加以详细查看，并做出相应决定。代码坏味道是需要重构的症状。或者是潜在的问题，或者是缺陷。代码的坏味道重点在代码层次，与拙劣的设计相比是低的层次。代码的坏味道产生破窗效应和技术债务的一个原因就是代码产生了坏伟大程序员的标准-避免坏味道“我不是什么伟大的程序员，我只是一个有着很多好习惯的程序员”。任何一个傻瓜都能写出机器能读懂的代码，好的程序员应该写出人能懂的代码。我们不是要告诉别人什么才是好的程序的标准，而应该告诉别人不应该出现的错误。伟大程序员的标准-避免坏味道“我不是什么伟大的程序员，我只是22种常见的代码的坏味道重复代码过长函数过大类过长参数列发散式变化散弹式修改依恋情结22种常见的代码的坏味道重复代码22种常见的代码的坏味道数据泥团基本类型迷恋分支语句(switch)平等继承体系冗赘类夸夸其谈未来性令人迷惑的暂时值域22种常见的代码的坏味道数据泥团22种常见的代码的坏味道过度耦合的消息链中间转手人狎昵关系异曲同工的类不完美的程序库类纯粹的数据类被拒绝的遗赠过多的注释22种常见的代码的坏味道过度耦合的消息链代码静态分析代码静态分析工具是一种软件，可以利用它对程序的源代码进行分析，自动测试应用系统的很多方面。在软件测试中，静态分析工具并不执行所测试的程序，只是扫描所测试程序的正文，对程序的源代码进行分析，它类似于编译程序中的词法分析和语法分析，但工作量远不止于此。使用代码静态分析工具可以发现一些代码坏味道。但不会解决代码的坏味道。代码静态分析代码静态分析工具是一种软件，可以利用它对程序的源坏味道的解决之道-重构代码的坏味道-设计师必知代码坏味道-坏味道的名称症状-有助于找出问题的线索原因-对问题如何会发生的说明采取的措施-可能的重构收益-在那些方面有所改善不适应情况-在哪些情况下不适用坏味道的解决之道-重构代码的坏味道-设计师必知重构的定义名词定义：对软件内部结构的一种调整，目的是在不改变功能的前提下，提高其可理解性，降低其修改成本。动词定义：使用一系列重构准则，在不改变软件功能的前提下，调整其结构。重构的3次法则（事不过三）第一次做某事时尽管去做；第二次做类似的事情时会产生反感，但无论如何还是做了；第三次再做类似的事，你就应该重构。重构的定义名词定义：对软件内部结构的一种调整，目的是在不改变坏味道与重构重复代码:在一个以上的地方看到相同的程序结构同一个class内的两个函数含有相同表达式两个互为兄弟的subclass内含有相同的表达式一般重构方法：提炼方法、提取类、方法上移、替换算法、链构造方法。坏味道与重构重复代码:在一个以上的地方看到相同的程序结构坏味道与重构发散式变化:软件应该能够更容易的被修改。一旦需要修改，我们希望能够集中到系统的某一点，只在此处做修改。散弹式修改：如果每遇到某种变化，你必须在许多不同的class内作出许多小修改以响应之，即需要修改的代码四处散布，不但很难找到，而且容易遗漏。

一般重构方法：提取类、转移方法、转移字段。坏味道与重构发散式变化:软件应该能够更容易的被修改。一旦需要坏味道与重构过多的注释:代码中常常看到一段很长的注释，然后发现，这些注释存在的原因是因为代码很糟糕。加入注释的目的是让大家能够知道我的代码是干什么的。如果我们找到这些代码的坏味道，并使用重构的方法把坏味道清除掉，就会发现注释已经变得多余了。坏味道与重构过多的注释:代码中常常看到一段很长的注释，然后发坏味道与重构不同的坏味道，其重构方法方法不尽相同。坏味道还可以使用模式的方法进行重构。在此我们不做具体说明。坏味道与重构不同的坏味道，其重构方法方法不尽相同。坏味道还可总结我们应该了解设计的金字塔。我们应该明确自己设计的价值观。是注重可维护性还是更注重性能。维护成本的计算。我们应该知道优秀设计的原则。我们应该知道怎样才是一个好的程序员。我们应该知道破窗效应、技术债务。我们应该知道代码中那些常见的坏味道。我们应该知道如何清除代码中的坏味道我们应该知道如何重构总结我们应该了解设计的金字塔。期望我们希望大家通过不同的架构视图为系统做出正确的架构设计。我们希望大家在设计时能够树立正确的设计价值观。我们希望大家都能做出优秀的设计。我们希望少出现或不出现破窗效应和技术债务。我们希望系统中的代码少出现或不出现坏味道。即使出现，我们也能通过重构将之清除。我们希望大家都能成为好的设计师和程序员。期望我们希望大家通过不同的架构视图为系统做出正确的架构设计。软件详细设计

讲座主讲人：软件详细设计

讲座主讲人：内容第二部分：软件设计第一部分：软件架构内容第二部分：软件设计第一部分：软件架构第一部分

软件架构内容第一部分

软件架构内容需求/架构/设计关系需求/架构/设计关系软件架构定义什么是架构？如果你问五个不同的人，可能会得到五种不同的答案。很多人都试图给“架构”下定义，而这些定义本身却很难统一。软件架构是一种无法以简单的一维方式进行说明的复杂实体。软件架构（softwarearchitecture）是一系列相关的架构视图，用于指导大型软件系统各个方面的设计。多重软件架构视图之所以必不可少，是因为各类型人员（用户、开发人员、测试人员、维护人员、操作人员）需要从各自的角度理解和使用架构。软件架构定义什么是架构？如果你问五个不同的人，可能会得到五种软件架构的实际意义做正确的架构正确的表达架构让别人能遵守架构软件架构的实际意义做正确的架构软件架构视图单一的视图无法完整的表达架构，因此需要具备完整的视图集。软件架构视图是从特定的视角出发，专注于该视角系统的结构、模块划分、基本组件职责和主要控制流。软件架构视图的四要素：图示化主要元素和元素之间的关系。具有明确的图例、定义和说明元素。每个元素具备明确的接口和行为规范。设计的原理和设计决策信息。。软件架构视图单一的视图无法完整的表达架构，因此需要具备完整的常见软件架构视图逻辑视图开发视图部署视图进程视图场景视图数据视图实现视图常见软件架构视图逻辑视图”4+1”模式逻辑视图开发视图进程视图部署视图场景视图”4+1”模式逻辑视图开发视图进程视图部署视图场景视图逻辑视图面向对象：客户/用户/开发组织管理者。视角：系统的功能元素，以及它们的接口、职责、交互等。主要元素：系统、子系统、功能模块、子功能模块、接口用途：开发组织划分，成本/进度评估逻辑视图面向对象：客户/用户/开发组织管理者。逻辑视图样例一系统框架图逻辑视图样例一系统框架图逻辑视图样例二软件结构图逻辑视图样例二软件结构图逻辑视图样例三前置子系统结构图逻辑视图样例三前置子系统结构图逻辑视图样例四监控子系统结构图逻辑视图样例四监控子系统结构图逻辑视图样例五防误子系统结构图逻辑视图样例五防误子系统结构图开发视图面向对象：开发相关人员/测试人员视角：系统如何开发实现主要元素：描述系统的层、分区、包、框架、系统通用服务、业务通用服务、类和接口、系统平台和相关基础框架用途：指导开发设计和开发实现开发视图面向对象：开发相关人员/测试人员开发视图样例一开发视图样例一开发视图样例二对象请求代理ORB开发视图样例二对象请求代理ORB开发视图样例三复制数据库技术架构开发视图样例三复制数据库技术架构开发视图样例四进程和服务管理开发视图样例四进程和服务管理开发视图样例五数据库专用平台开发视图样例五数据库专用平台开发视图样例六前置子模块间关系开发视图样例六前置子模块间关系部署视图也称物理视图面向对象：系统集成商/系统运维人员视角：系统逻辑组件到物理节点的物理部署、节点之间的物理网络配置主要元素：物理节点以及节点的通讯用途：指导系统采购以及网络、节点布局部署视图也称物理视图部署视图样例一部署视图样例一部署视图样例二部署视图样例二部署视图样例三部署视图样例三部署视图样例四部署视图样例四进程视图面向对象：性能优化/开发相关人员视角：系统运行时线程/进程的情况主要元素：系统进程/线程以及处理队列等用途：指导系统进程/线程分布进程视图面向对象：性能优化/开发相关人员进程视图样例进程视图样例场景视图也称用例视图面向对象：设计和开发人员视角：囊括了架构上最重要的场景（最典型或最有风险）及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素的运行方式。场景视图也称用例视图场景视图样例一场景视图样例一场景视图样例二场景视图样例二数据视图面向对象：数据架构师/开发相关人员视角：系统数据模型以及数据存储/存取方式主要元素：系统的核心实体模型以及相应的数据存储模型和存储方式系统的数据存储相关策略系统核心的数据流数据视图面向对象：数据架构师/开发相关人员数据视图样例一数据视图样例一数据视图样例二RAC模式数据视图样例二RAC模式数据视图样例三HA模式数据视图样例三HA模式数据视图样例四DataGuard模式数据视图样例四DataGuard模式总结架构设计以多视图的模式呈现多视图的目的是为了指导不同的团队思维和实现多视图是分而治之的多视图可以并行多视图可以组合总结架构设计以多视图的模式呈现第二部分

软件设计内容第二部分

软件设计内容内容软件设计金字塔软件设计的价值观优秀设计遵循的原则破窗效应和技术债务代码的坏味道重构技术内容软件设计金字塔设计金字塔设计金字塔关注软件维护成本软件系统维护工作量所占比重超乎想象！！！COST(total)=COST(develop)+COST(maintain)COST(maintain)=Cost(understand)+(理解)Cost(change)+(变更)Cost(test)(测试)Cost(depoly)(现场部署)关注软件维护成本软件系统维护工作量所占比重超乎想象！！！什么是好的设计?关注软件的可维护性和可复用性区分功能需求和非功能需求一个好的设计应该有如下性质：可扩展性、灵活性、可插入性可扩展性：新的功能可以很容易的加入到系统中灵活性：可以容许代码修改平稳，而不会波及到很多其他模块可插入性：可以很容易的将一个类抽出去，同时将另一个有同样接口的类加入进来什么是好的设计?关注软件的可维护性和可复用性软件的可维护性大家有没有注意到，原来我们自认为是很漂亮的设计随着时间的推移慢慢“发出腐化的臭味”，代码也会慢慢变成由一堆纠缠不清的函数和变量搅和在一起的“代码浆糊”，为什么？是什么原因导致的呢？--都是客户和老板的错！客户不断的改变需求。如果用户的要求仅限于他们最初所声明的，我们的设计就没有问题，错就错在用户改变了他们的需求。老板没有给我们充足的时间，进行充分的分析，使我们没有时间设计出一个完美的结构。软件的可维护性大家有没有注意到，原来我们自认为是很漂亮的设计软件的变更软件是应该不断变更的。我们认为,真实世界中使用的程序必须进行变更，否则它在环境中的作用就会原来越小。软件复杂增加性法则：随着一个不断演进程序的变更，他的结构会变得越来越复杂。软件是应该不断变更的，因为需求是不断变更的。难道变化的需求一定会导致系统“腐烂”吗？为什么一个系统的设计不可以为以后的变化留出足够的空间？如何实现一个优秀的设计？软件的变更软件是应该不断变更的。我们认为,真实世界中使用的程优秀设计原则优秀设计第一法则：开闭原则优秀设计第二法则：重构优秀设计原则优秀设计第一法则：开闭原则开闭原则开放-封闭原则（OCP）软件的组成实体（类、模块、函数等等）应该是可以扩展的，但是是不可修改的。即软件实体可以通过增加新代码实现扩展，但是不能修改已有代码。任何一个系统在其生命周期内都会发生变化。如果我们希望开发出的系统不会在第一版本后就被抛弃，我们就必须牢记这一点。开闭原则开放-封闭原则（OCP）发现变化并将其封装优秀设计精髓就是封装变化，就是将变化进行抽象，封装变化，这样才能保证软件的可扩展性以及模块间的松耦合。一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里。一种可变性不应当与另一种可变性混合在一起。发现变化并将其封装优秀设计精髓就是封装变化，就是将变化进行抽共性和可变性分析(CVA)找到变化的地点，称为“共性分析”然后找出如何变化，称为“变性分析”CVA分析步骤先寻找共性；从这些共性创建抽象；从共性的变化派生可变性实现；看共性与其他共性之间的关系如何；共性和可变性分析(CVA)找到变化的地点，称为“共性分析”CVA样例主板和插槽CVA样例主板和插槽开闭原则的代价100%开闭原则的代价：遵循开闭原则代价昂贵，正确的抽象（寻找共性并抽象）需要时间和精力，需求的不可预测性，给抽象增加了复杂度。对于应用程序中的每个部分都肆意的进行抽象同样不是一个好主意。应该对程序中呈现频繁变化的那些部分进行抽象。拒绝不成熟的抽象和抽象本身一样重要。开闭原则的代价100%开闭原则的代价：亡羊补牢-重构面对需求的不可预测性，设计师根据经验猜测程序可能遭受的变化，如果猜测正确，获得成功，猜测错误，遭受失败。随着需求的不断变化，软件的不断变更，“设计腐化”和“代码浆糊”的现象慢慢呈现出来。为了解决这个问题，我们需要应用优秀设计的第二法则：优秀设计需要不断重构。重构到优秀设计。亡羊补牢-重构面对需求的不可预测性，设计师根据经验猜测程序可拙劣设计的影响如果设计已经出现腐化，代码浆糊已经开始产生，我们最初的设计已经成为拙劣的设计了，我们不去重构的话，将会产生“破窗效应”和“技术债务”问题。拙劣设计的影响如果设计已经出现腐化，代码浆糊已经开始产生，我破窗效应破窗理论破窗效应(BreakPaneLaw)

没修复的破窗，导致更多的窗户被打破破窗效应破窗理论破窗效应(BreakPaneLaw)

破窗效应破窗效应：没修复的破窗，导致更多的窗户被打破所谓“破窗效应”，是关于环境对人们心理造成暗示性或诱导性影响的一种认识。“破窗效应”理论是指：一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙的被人打破；一面墙，如果出现一些涂鸦没有清洗掉，很快的，墙上就布满了乱七八糟，不堪入目的东西。一个很干净的地方，人们会不好意思丢垃圾，但是一旦地上有垃圾出现之后，人们就会毫不犹疑的拋，丝毫不觉羞愧。这真是很奇怪的现象破窗效应破窗效应：没修复的破窗，导致更多的窗户被打破技术债务“出来混，迟早要还的”技术债务“出来混，迟早要还的”技术债务(TechnicalDebt)开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案，但从长远来看，这种方案会带来更消极的影响，亦即开发团队所欠的债务技术债务类似于金融债务，它也会产生利息，这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多努力的后果。我们可以选择继续支付利息，也可以通过重构之前鲁莽的设计来将本金一次付清。虽然一次性付清本金需要代价，但却可以降低未来的利息技术债务(TechnicalDebt)开发团队在设计或架技术债务技术债务的种类无意的——由于经验的缺乏导致初级开发者编写了质量低劣的代码。有意的——团队根据当前而非未来进行设计选型，这种方式可能很快就能解决当前的问题，但却很拙劣技术债务技术债务的种类技术债务很多敏捷团队都能认识到技术债务相关的罪状。就跟财务上的负债一样，技术债务也会产生利息。要支付这些利息，就要付出额外努力维护和改进正在“腐化”或基础并不牢固的软件。诸多敏捷人士推荐尽早偿还技术债务。然而，大多数敏捷团队无法成功以金钱的方式计算技术债务，因此无法得到有价值的深入理解和思考技术债务很多敏捷团队都能认识到技术债务相关的罪状。就跟财务上技术债务技术债务代码的坏味道产生破窗效应和技术债务的一个原因就是代码产生了坏味道。代码坏味道是指在代码之中潜在问题的警示信号，并非所有的坏味道所指示的确实是问题，但大部分坏味道需要加以详细查看，并做出相应决定。代码坏味道是需要重构的症状。或者是潜在的问题，或者是缺陷。代码的坏味道重点在代码层次，与拙劣的设计相比是低的层次。代码的坏味道产生破窗效应和技术债务的一个原因就是代码产生了坏伟大程序员的标准-避免坏味道“我不是什么伟大的程序员，我只是一个有着很多好习惯的程序员”。任何一个傻瓜都能写出机器能读懂的代码，好的程序员应该写出人能懂的代码。我们不是要告诉别人什么才是好的程序的标准，而应该告诉别人不应该出现的错误。伟大程序员的标准-避免坏味道“我不是什么伟大的程序员，我只是22种常见的代码的坏味道重复代码过长函数过大类过长参数列发散式变化散弹式修改依恋情结22种常见的代码的坏味道重复代码22种常见的代码的坏味道数据泥团基本类型迷恋分支语句(switch)平等继承体系冗赘类夸夸其谈未来性令人迷惑的暂时值域22种常见的代码的坏味道数据泥团22种常见的代码的坏味道过度耦合的消息链中间转手人狎昵关系异曲同工的类不完美的程序库类纯粹的数据类被拒绝的遗赠过多的注释22种常见的代码的坏味道过度耦合的消息链代码静态分析代码静态分析工具是一种软件，可以利用它对程序的源代码进行分析，自动测试应用系统的很多方面。在软件