【文档说明】高级软件工程师详细设计.pptx，共(52)页，1.367 MB，由精品优选上传

转载请保留链接：https://www.ichengzhen.cn/view-290591.html

以下为本文档部分文字说明：

®Evolvebycase我们来看设计前言▪架构的输出=详细设计的输入（结构视图）▪一个菜鸟的代码成长过程▪什么是优秀的设计？▪做设计的一些基本法则？▪为什么要重构？如何重构？▪重构遇到的问题，如何去解决

我们所处的位置——需求/架构/设计关系架构的输出=详细设计的输入▪功能视图▪开发视图▪实现视图▪数据视图▪场景视图▪消费者：客户/用户/开发组织管理者▪视角：系统的功能元素，以及它们的接口，职责，交互▪主要元素：系统，子系统，功能模块，子功能模块，接口▪用途：开发组织划分，成本/进度的评估▪缺陷：

现有系统没有该视图。功能视图功能视图-实例开发视图▪消费者：开发相关人员/测试人员▪视角：系统如何开发实现▪主要元素：描述系统的层，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架。▪用途：指导开发组织设计和开发实现。开发视图-实例

实现视图▪消费者：开发相关人员/测试人员/实施人员▪视角：系统交付物结构形式和相关实现规范▪主要元素：创建可交付物的形式（网页、dll、可执行文件、源码）以及组织结构开发过程中必须遵守的相关规范和指南▪用途：实现

视图-实例数据视图▪消费者：数据架构师/开发相关人员▪视角：系统数据模型以及数据存储/存取等▪主要元素：系统的核心实体模型以及相应的数据存储模型和存储方式系统的数据存取相关策略系统核心的数据流▪用途：▪模型的选择会影响最终生产系统的灵活性和可重用

性▪MartinFowler数据视图-数据存储策略在159项目中，数据集成过程中就需要一个前期规划，其他项目是不是也有相关问题那？数据视图-处理流程场景视图▪消费者：设计和开发人员▪视角：概括了架构上最重要的场景（最典型或者最有风险）及其非功能性需求，通过这些场景的实现，阐

明了架构的广度或众多架构元素运行的方式。▪主要元素：▪用途：▪总结一下详细设计从架构那里可以榨取以上信息，前提条件是架构师在设计完后一定要排除技术风险，并且进行测试视情况而定，不是所有信息都必须榨取，适可而止架构方面大家有什么疑问，等到我们是架构的时候共同探

讨，谢谢！架构的输出暂时就这么多我们来看一下代码的成长过程-log系统概述▪项目背景开始使用java编程语言,是第一个面向对象项目,以前仅仅使用C语言,结构化思维方式▪需求项目经理,告诉编写一个Log类,进行打印输出系统log信息一条L

og包含时间,线程ID,log编号,Message信息(必须)输出到文件我们来看一下代码的成长过程-原始版我们来看一下代码的成长过程▪需求变化1_日志级别和两种输出方式一条log包含时间，线程id，log编号，级别，Message信息（必须）Log定义几个级别（debug，inform

ation，warining，error）两种输出方式：•1：level为info，debug的直接输出到console•2：其他级别输出到File中需求变更1对应代码状态我们来看一下代码的成长过程▪需求变化2_log输出有两种格式一种是原

来的直接文本格式新增一个专门格式，供后台的监控和分析系统进行及时分析，暂定为xml格式需求变更2对应代码状态需求变化3-输出目的地和日志格式化更复杂▪同一条Log可以输出到多种目的地▪同一条Log可以有多种格式化

▪输出目的地条件更复杂每一种目的地,都可能多种选择格式化的一种需求变更3对应代码状态这种做法如果需求变更会导致什么▪如果增加一种新目的地(比如SocketServer,JMS)▪如果增加一种格式化(比如固定化)▪如果条件变化会怎样?▪我

们想象一下代码现在长成什么样子了？你有什么好的想法去改变这种状态？它是不是应该减肥了？是不是管的太宽了？听听大家的意见设计和编码的关系▪边设计边编码，想法全在大脑内存中▪先设计后编码不拘泥设计表现形式（白板、草稿纸均可），目的让别人了

解你的想法。这个过程是迭代的。▪只做设计，编码留给开发人员什么是优秀设计？--关注软件的可维护性和可复用性▪好的设计目标可扩展性：新的功能可以很容易地加入到系统之中灵活性：可以允许代码修改平稳，而不会涉及到很多其他的模块可插入性：可以很容易

的将一个类抽出去，同时将另一个有同样接口的类加入进来。为什么这是优秀的设计？——背景篇▪看一些数据业内统计数据显示，一个软件系统从开始到最终消亡的整个生命周期，前期的总代价是20~40%.绝大部分的工作重点，还需要花费在系统正式上线以后的后续维护和在系统的升级上。但是我们往往忽略了后期的系统可

维护性。▪软件维护——残酷的现实程序员脑子里原先那些漂亮的设计随时间的推移会慢慢“发出腐化的臭味”。去年才构建好的漂亮小巧的系统，到了今年却变成了由一堆纠缠不清的函数和变量搅合在一起的“代码浆糊”。为什么会这样？迄今为

止人们构建出的几乎所有软件系统都遭遇了缓慢的，不可抗拒的腐化，这种现象如此普遍。。。为什么这是优秀的设计？——背景篇⚫什么原因导致的？⚫有时候我们把原因归咎为客户，责怪他们总是更改需求。我们自我安慰地认为，只要客户的需求仅限于他们最初的声明的，那么我们的设计就是

没问题的，所以错就错在客户改变了需求。⚫有时候，我们也会埋怨老板，是他么没有给我们时间进行充分的分析。其实根本不存在充分分析这种东西。无论花费多少时间试图找出完美的软件结构，客户总是引入一个变化破坏这个结构，不存在完美结构，只存在哪些试图平衡当前代价和收益的结构。⚫软件变更基本法则⚫软件

不断变更的法则：真实世界中使用的程序必须变更，否则它在环境中的作用就会越来越小。⚫软件复杂增加性法则：随着一个不断演进程序的变更，它的结构会变得更复杂，除非通过积极的工作来避免这一现象。⚫公司的现状：⚫还没有考虑到软件的可维护性，以后应该多考虑考虑这点，不过目前的打捆式项目已经考虑到

了可复用性为什么这是优秀的设计？——解救篇▪软件的可维护性和可复用性这就成为我们程序员苦苦追求的境界。▪寻找万能的上帝前人经过不断总结，发现和这些变化进行斗争，如果遵循某些法则，过程会变的很有趣，程序员不会暗无天日，系统不会动

辄崩溃。我们找到了解救法宝——法则。为什么这是优秀的设计？——解救篇▪优秀设计第一法则——开闭原则何谓开闭原则？软件组成实体（类、模块、函数，等等）应该是可扩展的，但是不可修改的。（即软件实体可以通过增加代码实现扩展，但是不能修改已有代码）。如何实现开闭原则？——2个基本思想•共性和可变性分

析•正确的接受现实——重构为什么这是优秀的设计？——解救篇▪共性可变性分析实现抽象：在oopl中，可以创建出固定却能描述一组任意个可能行为的抽象体，这个抽象就像抽象基类或者接口，任意可能的行为就是可能的派生类。针对接口（抽象）设计：由于模块之间依赖一个固定的抽象，所以它对更改可以是关闭的。

注意抽象有度为什么这是优秀的设计？——重构篇▪正确的接受现实——重构面对复杂的领域多变性，设计师根据经验猜测程序可能遭遇的变化，如果猜测正确，获得成功；如果猜测错误，遭受失败。有时为了不必要的复杂性，我们会被愚弄（没有抽象）。但是当变化发生时，我们就应该创建抽象进行隔离以后的同

类变化。（题外话：我们设计人员应该积极地参与到需求过程，这样我们的预测才有可能正确！）即对软件内部结构的一种调整，目的是不改变功能的前提下，提高其可理解性，降低其修改成本代码的坏味道与重构▪代码的坏味道概述▪坏味道解决之道-重构技术坏味道▪代码坏味道(codesmell),是指在代码之中潜在问题

的警示信号.并非所有的坏味道▪所指示的确实是问题,但是对于大多数坏味道,均很有必要加以查看,并做出相应决定▪代码坏味道是需要重构的症状。或者潜在的问题（PotentialProblem）或者缺陷（Flaw）▪代码坏味道和拙劣设计相比是低的层次,重点在代码的层次生

病的症状21种代码坏味道-1▪DuplicatedCode重复代码▪LongMethod过长方法▪LargeClass过长类▪LongParameterList过长参数列表▪DivergentChange发散式变化▪ShotgunSurgery霰弹式修改▪Fea

tureEnvy特性依恋▪DataClumps数据泥团▪PrimitiveObsession基本类型偏执▪SwitchStatementsswitch语句21种代码坏味道-2▪DataClass数据类▪Refused

Bequest拒绝继承▪Comments注释过多▪TemporaryField临时字段▪MessageChains消息链▪MiddleMan中间人▪InappropriateIntimacy过度亲密▪LazyClass冗

余类21种代码坏味道-3▪ParallelInheritanceHierarchies平行继承体系▪SpeculativeGenerality理论上的一般性▪AlternativeClasseswithDifferentInterfaces接

口不同的等效类▪IncompleteLibraryClass不完整的库类21种代码坏味道_治疗手段软件重构—面临的困难⚫程序员方面⚫公司方面⚫如何改变现状⚫程序员方面⚫不知道如何去重构，认识没有达到一定程度。⚫程序员的认识有问题，认为别人写的垃圾都很垃圾不如自己

写的，还不如将此功能块重新开发。⚫个人误区，认为做新项目好，能学到新的东西，不喜欢维护旧项目，忽略了提高技能，而不是技巧。⚫公司方面⚫认为做出来东西才有价值，因为你做了两个月，可能界面和功能一点都没有变。⚫公司没有那

么多时间和精力让你去重构⚫对项目的工期评估有问题：根据业界统计：其中一个项目从设计到上线运行，前期的总成本和工时只占软件总成本和总工时的20%-40%，后期占60%-80%。⚫重构过程中，没有为公司带来直接的价格，不如新开发项目。⚫如何改变现状⚫尽量挤时间从设计开始就不断去重构，开发中更

要重视重构，不要等到项目都要上线了，再去想着重构⚫积极去面对重构⚫下面看一个实际项目中重构的例子回顾▪架构的输出=详细设计的输入（结构视图）▪一个菜鸟的代码成长过程▪什么是优秀的设计？▪做设计的一些基本法则？▪为什么要重构？如何重构？▪重构遇到的问题，如何去解决？谢谢！

！！