软件重构
- 格式：ppt
- 大小：1.26 MB
- 文档页数：141
下载文档原格式
合集下载
软件工程中的软件重构与代码重用
软件工程中的软件重构与代码重用在当今数字化的时代，软件如同构建起现代社会的基石，其质量和效率对于各种应用的成功运行至关重要。
软件工程作为一门致力于提高软件质量和开发效率的学科，其中的软件重构和代码重用是两个关键的概念和实践。
软件重构，简单来说，就是在不改变软件外部行为的前提下，对软件内部结构进行改善和优化。
这就好比给房子进行内部装修，虽然房子的外观和功能不变，但内部布局更合理、更舒适。
为什么要进行软件重构呢？随着时间的推移，软件会不断地被修改和扩展。
最初清晰简洁的代码结构可能会逐渐变得混乱和复杂，就像一个杂乱无章的衣柜，找东西变得越来越困难。
这时，重构就显得尤为重要。
通过重构，可以提高代码的可读性和可维护性。
清晰易懂的代码能让新加入的开发者更快地理解和上手，减少理解代码所花费的时间和精力。
同时，重构还能消除代码中的重复和冗余，使得代码更加简洁高效，降低了软件的维护成本。
另外，良好的代码结构还能提高软件的可扩展性。
当需要添加新的功能时，如果代码结构合理，那么新功能的实现会更加容易，也更不容易引入新的错误。
重构还能够发现和修复潜在的错误和缺陷。
在优化代码结构的过程中，一些隐藏在复杂代码中的问题可能会暴露出来，从而得到及时的解决。
那么，如何进行软件重构呢？首先，需要对现有代码进行全面的分析和理解，找出存在问题的部分。
这可能包括代码的复杂性过高、缺乏清晰的模块划分、函数过长等。
然后，制定重构的计划和目标，明确要改进的方向。
接下来，逐步对代码进行修改，可以采用一些常见的重构技术，如提取函数、重命名变量、优化算法等。
在重构的过程中，要进行充分的测试，确保修改后的代码没有引入新的错误，并且功能依然正常。
与软件重构密切相关的是代码重用。
代码重用是指在软件开发中，重复使用已经存在的代码来构建新的软件系统或功能模块。
这就像是搭积木，我们可以利用现有的积木块来搭建出各种不同的造型，而不必每次都重新制作积木。
代码重用带来的好处是显而易见的。
如何进行软件重构
如何进行软件重构引言随着软件技术的急速发展，各种功能不断加入，软件大小不断增长，代码十分庞大和复杂，这些因素不仅导致开发活动的时间和成本的增加，且使维护活动难以管理。
在这种情况下，软件重构成为了一项非常重要的技术。
软件重构的概念软件重构是指对现有软件系统的代码、设计、架构或软件产品的非功能属性等进行修改，以提高其可维护性、可操作性、可移植性以及其他非功能属性等的能力的过程。
“重构”最初由M.Fowler 在1997年正式提出，后经过多年实践，成为了一项非常有效的软件开发技术。
重构的类型在软件开发过程中，重构的类型可以分为以下几种：1. 代码重构：通过修改代码以提高软件的效率和可读性。
2. 架构重构：对软件系统架构及其相互关系进行重新设计，以提高软件的可靠性和可扩展性。
3. 非功能属性重构：重构不关注软件的功能，重点关注非功能属性，例如软件易用性、可移植性等属性。
4. 设计重构：对软件的设计进行重构，以提高其复用性、可扩展性、可维护性等。
如何进行重构下面是一些进行软件重构的最佳实践：1.明确重构目标重构的第一步应该是明确重构的目标，以确定修改的方向。
这些目标可能包括提高代码质量、提高性能、提高可维护性等。
2.基于单元测试进行重构单元测试是确保重构后代码的正确性的最佳方式。
在进行重构之前，先编写一些测试用例，并在重构之后对这些测试用例进行运行以确保代码的正确性。
3.使用源代码控制在重构过程中，使用源代码控制是非常重要的。
源代码控制将帮助开发人员跟踪代码的更改，撤消错误修改，以及回到之前保存过的代码版本。
4.保持简单在进行重构过程时要保持简单。
在修改代码时，尽量避免过于复杂的算法和设计，否则会让代码难以维护。
5.进行逐步重构重构代码时，不要一次性修改所有代码，而应采用逐步重构的方式。
逐步重构意味着对代码的不断修改和优化，以确保代码质量的逐步提高。
结论软件重构是一项非常重要的技术，它可以帮助软件开发人员提高代码质量、提高可维护性、提高性能等。
软件工程中的软件重构与重用
框架重用
组件重用
定义应用程序的整体结构 提供基本功能模块
降低开发难度
独立的可重用部件 提供特定功能
提高开发效率
重用挑战
软件重用面临的挑战包括组织文化、维护成 本、知识管理等问题。为了克服这些挑战， 需要建立适合的文化氛围，有效管理维护成
本，并建立良好的知识共享机制。
总结
软件重用的重要性
提高开发效率、提高软件质量、降低成本
团队C的重构经验
利用重构技术提高代码质量，减少bug数量，提升用户体验。
总结
重构与重用是软件工程中必不可少的重要环节。 通过合理的重构策略和重用策略，可以提高软 件系统的质量和可维护性，加速开发效率，降 低成本。在实践中，开发团队应该不断总结经 验，学习成功案例，不断优化和改进软件开发
过程中的重构与重用实践。
Confluence
团队协作文档工具
JIRA
敏捷项目管理工具
总结
软件重构与重用的工具支持在软件开发过程中 起着至关重要的作用。通过合理利用代码重构 工具、组件库管理工具、文档生成工具以及团 队协作工具，开发团队可以提高代码质量、减 少重复开发，提高团队协作效率，从而更好地
实现软件重构与重用的目标。
能性。
参考文献
Refactoring: Improving the Design of Existing
Code
Code Complete: A Practical
Handbook of Software
Construction
Design Patterns: Elements of
Reusable ObjectOriented Software
●06
LOGO 第六章 总结与展望
软件工程中的软件重构与代码重用
软件工程中的软件重构与代码重用在当今数字化时代，软件在各个领域都发挥着至关重要的作用。
从智能手机上的应用程序到企业级的业务系统，软件的质量和效率直接影响着用户体验和业务运营。
而在软件工程中，软件重构和代码重用是两个关键的概念，它们对于提高软件的可维护性、可扩展性和开发效率具有重要意义。
软件重构，简单来说，就是在不改变软件外部行为的前提下，对软件内部结构进行调整和优化。
为什么要进行软件重构呢？随着时间的推移，软件的需求可能会发生变化，代码可能会变得复杂和混乱，难以理解和维护。
就好像一个房间，如果长时间不整理，东西就会堆积如山，找东西变得困难，空间也变得狭小。
软件也是如此，如果不进行重构，代码的可读性和可维护性会逐渐降低，开发新功能会变得越来越困难，甚至可能引入新的错误。
软件重构的好处是显而易见的。
首先，它可以提高代码的质量。
通过重构，可以消除代码中的重复、优化算法、改进代码结构，使代码更加简洁、清晰、易于理解。
这样不仅有助于开发人员更快地理解代码的逻辑，也便于后续的维护和修改。
其次，重构可以增强软件的可维护性。
良好的代码结构和设计模式可以降低维护成本，减少错误的发生。
最后，重构有助于提高开发效率。
当代码质量提高，开发人员在开发新功能时可以更加专注于业务逻辑，而不是花费大量时间在理解和修复混乱的代码上。
那么，如何进行软件重构呢？这需要遵循一些原则和方法。
首先，要有明确的目标。
是要提高代码的性能，还是增强可读性，或者是改进架构？明确目标可以指导重构的方向。
其次，要进行充分的测试。
在重构过程中，要确保软件的外部行为没有改变，因此需要有完善的测试用例来验证。
此外，重构应该逐步进行，小步快跑，每次只对一小部分代码进行修改，避免一次性改动过大导致不可预见的问题。
代码重用则是软件工程中的另一个重要概念。
它指的是在不同的项目或同一项目的不同部分中重复使用已经存在的代码。
想象一下，如果每次开发一个新的软件都要从头开始编写所有的代码，那将是多么低效和浪费的事情。
代码重构与软件重构的区别分析
代码重构与软件重构的区别分析近年来，随着软件行业的发展，代码重构和软件重构这两个概念变得越来越受到关注。
在软件开发过程中，代码重构和软件重构都可以帮助开发者提高软件质量，降低维护成本。
那么，代码重构和软件重构有什么区别呢？一、重构的定义重构是一种软件开发技术，通过对代码进行调整和改进，从而使代码在不改变其外部行为的前提下，具有更好的结构、更易于维护和扩展。
重构旨在通过提高代码质量和可读性，从而提高软件质量和生产力。
二、代码重构代码重构是指修改已有的源代码，以改善其质量而不影响其行为。
代码重构不会导致软件行为变化。
代码重构的目的是优化代码的结构、提高代码质量、扩展其功能、减少代码的冗余和依赖。
代码重构的几个主要目标：1、简化代码2、提高代码可读性3、提高代码重用性4、提高代码的可维护性5、优化代码结构6、减少代码的冗余和依赖三、软件重构软件重构是指对软件系统整体进行重构，以增强其质量、可读性和可维护性。
软件重构通常包括三个方面：架构重构、代码重构和数据结构重构。
软件重构的几个主要目标：1、提高软件系统的质量2、改善软件系统的可读性和可维护性3、优化软件系统的架构组织4、减少软件系统的复杂度5、提高软件系统的灵活性和扩展性四、代码重构和软件重构的区别虽然代码重构和软件重构都可以帮助提高软件质量，但它们之间有着一些重要的区别。
1、范围不同代码重构是针对单个模块或单个函数的优化，而软件重构是对整个软件系统的优化。
2、目的不同代码重构是为了提高单个模块或单个函数的质量，而软件重构是为了提高整个软件系统的质量。
3、实现方式不同代码重构是基于代码本身的优化，而软件重构包括了多个方面的重构，包括架构重构、代码重构和数据结构重构。
4、影响不同代码重构只会影响到本身的代码，软件重构会影响到整个软件系统的质量。
代码重构和软件重构虽然有所不同，但两者在软件开发过程中都扮演着非常重要的角色。
只有在开发过程中及时进行代码和软件重构，才能有效地提高软件的质量和可维护性，降低维护成本，并使软件具有更高的可读性和可扩展性。
如何进行软件架构演进和重构
如何进行软件架构演进和重构软件架构是指在设计和开发软件系统时所采用的结构和组织方式，它决定了软件的整体性能、可维护性、可拓展性等方面的特点。
随着软件系统的不断变化和演进，软件架构也需要进行相应的演进和重构，以满足系统的新需求和改进。
为了进行软件架构的演进和重构，我们可以按照以下步骤进行：1.定义演进和重构的目标：首先，需要明确演进和重构的目标是什么。
可能是为了提高系统的性能、可维护性，或者是为了适应新的业务需求。
明确目标有助于指导后续的工作，并确保演进和重构的方向正确。
2.收集现有系统的信息：在进行架构演进和重构之前，需要对现有系统进行充分的了解和分析，收集相关的文档、代码和数据等。
这些信息可以帮助我们对系统的结构和组织方式有更清晰的认识，为后续的工作打下基础。
3.搭建框架和架构演进的路线图：根据目标和现有系统的信息，我们可以开始搭建框架和制定演进的路线图。
框架是指整个系统的大致结构和组织方式，路线图则表示系统演进的步骤和时间安排。
这些工作需要充分的讨论和协商，以确保最终的架构方案是可行和可接受的。
4.逐步演进和重构：在有了框架和路线图之后，我们可以开始逐步地进行架构的演进和重构。
这个过程可以分为多个阶段，每个阶段对应一个小的迭代周期。
在每个阶段中，我们需要明确具体的任务和目标，并进行相应的设计和重构工作。
同时，需要合理地划分工作的优先级和时间，以保证整个演进和重构的进度。
5.测试和验证：在完成每个阶段的设计和重构后，我们需要进行相应的测试和验证工作。
主要包括功能测试、性能测试、安全测试等。
通过测试和验证，我们可以验证系统是否满足设计目标，以及是否存在问题和风险。
6.监控和调整：在系统架构演进和重构的过程中，我们需要持续地进行监控和调整。
主要包括对系统的运行状态进行监控，以及对演进和重构的工作进行评估和调整。
通过监控和调整，我们可以及时地发现问题和风险，并采取相应的措施加以解决。
总之，软件架构的演进和重构是一个持续的过程，需要对现有系统进行充分了解和分析，并根据目标制定相应的框架和路线图。
软件设计模式与重构
软件设计模式与重构软件设计模式与重构是软件开发中两个重要的概念。
设计模式是一种在软件设计过程中经过验证的解决问题的方法论，它能够提供可重用性和灵活性。
而重构是一种对现有代码进行修改以改善其内部结构和可读性的过程，它可以提高软件的可维护性和可扩展性。
本文将首先介绍软件设计模式的基本概念和常见的几种设计模式，然后探讨重构的概念和目的，最后讨论软件设计模式与重构之间的关系。
一、软件设计模式软件设计模式是一种在软件设计中用于解决常见设计问题的方法论，它提供了一套通用的解决方案。
设计模式可以分为三种类型：创建型模式、结构型模式和行为型模式。
1. 创建型模式创建型模式主要关注如何创建对象，通过隐藏对象的创建细节，提供了一种更加灵活和可复用的对象创建方式。
常见的创建型模式包括单例模式、工厂模式、抽象工厂模式等。
2. 结构型模式结构型模式主要关注对象之间的组合和关系，通过定义对象之间的接口和关联关系，可以简化系统的结构，并提供一种更加灵活的对象组合方式。
常见的结构型模式包括适配器模式、装饰器模式、组合模式等。
3. 行为型模式行为型模式主要关注对象之间的通信和协作方式，通过定义对象之间的交互方式，可以提供一种更加灵活和可扩展的系统行为。
常见的行为型模式包括观察者模式、策略模式、迭代器模式等。
二、重构重构是指对现有代码的修改，以提高代码质量和可维护性。
重构的目的是通过修改代码的内部结构，提供更好的代码组织和可读性。
常见的重构技术包括代码抽取、代码重命名、类和方法的拆分与合并等。
重构的主要目的包括提高代码可读性、减少代码重复、提高代码的可维护性和可扩展性。
重构的过程中需要保证代码的行为不发生变化，并通过测试来验证重构的正确性。
三、软件设计模式与重构的关系软件设计模式和重构是紧密相关的概念，它们可以相互促进和补充。
软件设计模式提供了一种结构化的设计方法，可以帮助开发者更好地组织和设计代码。
而重构则可以在设计模式的基础上，对现有代码进行优化和改进。
如何进行软件架构重构和技术栈升级
如何进行软件架构重构和技术栈升级在软件开发领域，随着技术的不断发展和业务需求的变化，进行软件架构重构和技术栈升级是一项非常重要的任务。
通过优化架构和更新技术栈，我们可以提高软件系统的性能、可扩展性和可维护性，使其适应新的业务需求和技术趋势。
本文将介绍如何进行软件架构重构和技术栈升级，并提供一些建议和实施步骤。
一、分析现有架构和技术栈在进行软件架构重构和技术栈升级之前，首先需要对现有的架构和技术栈进行全面的分析和评估。
这包括以下几个方面：1. 功能需求和业务目标：了解当前系统的功能需求和业务目标，明确重构和升级的目的和优先级。
2. 架构评估：评估当前的软件架构是否能够满足系统的需求，是否存在性能、可扩展性和安全性等问题。
3. 技术栈评估：评估当前使用的技术栈是否适合系统的需求，是否存在过时的技术和框架。
4. 问题分析：分析当前系统存在的问题和瓶颈，例如性能问题、可维护性问题、安全问题等。
通过对现有架构和技术栈的分析，可以为后续的重构和升级工作提供有力的依据。
二、确定目标架构和技术栈在分析现有架构和技术栈的基础上，我们需要确定重构和升级的目标架构和技术栈。
这需要考虑以下几个因素：1. 业务需求：根据业务需求确定目标架构和技术栈，确保新的架构和技术能够支撑未来的业务发展。
2. 技术趋势：了解当前的技术趋势和发展方向，选择与之匹配的技术栈，避免选择过时的或不具备长期生命力的技术。
3. 可扩展性和可维护性：考虑目标架构和技术栈在可扩展性和可维护性上的优势，以便将来的扩展和维护工作更加方便。
4. 团队技术水平：评估团队成员的技术水平和熟悉度，选择能够快速学习和掌握的技术栈，以减少技术转型带来的风险。
确定目标架构和技术栈后，需要做好相应的技术调研和可行性分析，确保选择的技术能够满足系统的要求，并比较不同技术的优缺点，选择最适合的方案。
三、制定详细的重构和升级计划制定详细的重构和升级计划是确保工作顺利进行的重要步骤。
软件架构重构：优化现有系统的性能和可维护性
软件架构重构：优化现有系统的性能和可维护性软件架构重构是指对现有系统的架构进行优化，以提高系统的性能和可维护性。
软件架构是系统设计的基础，它决定了系统的结构、组织和行为。
一个优秀的软件架构能够提供良好的性能和可维护性，而一个糟糕的软件架构则可能导致系统的性能下降和维护困难。
在进行软件架构重构时，首先需要对现有系统进行全面分析，了解其功能、性能和可维护性等方面的问题。
通过对系统的性能进行监测和分析，可以找出系统中的性能瓶颈，进而有针对性地进行优化。
在优化性能方面，可以考虑以下几个方面：1.系统设计：在设计阶段就要考虑到系统的性能需求，合理规划系统的模块划分和通信方式，以提高系统的响应速度和处理能力。
2.数据库优化：对数据库进行索引优化、查询优化等操作，减少数据库访问的时间和开销。
3.缓存机制：使用缓存机制来减少对数据库的访问次数，提高系统的响应速度。
4.多线程和并发处理：通过多线程和并发处理来提高系统的并发性能，减少用户等待时间。
在提高可维护性方面，可以考虑以下几个方面：1.模块化设计：将系统拆分为多个独立的模块，每个模块负责特定的功能，提高系统的可复用性和可维护性。
2.规范编码：采用规范的编码风格和命名规范，提高代码的可读性和可维护性，减少bug的产生和修复时间。
3.单元测试：编写单元测试用例，保证系统的各个模块和功能的正确性和稳定性。
4.引入设计模式：使用设计模式来解决常见的问题，提高系统的可扩展性和可维护性。
此外，进行软件架构重构时还需考虑以下几个方面：1.成本和时间：重构软件架构可能需要花费较多的成本和时间，需要对项目进行评估和规划，确保重构的收益大于成本。
2.风险控制：重构可能引入新的问题，需要采取适当的风险控制措施，如进行精心的测试和备份。
3.团队协作：软件架构重构是一个复杂的过程，需要软件开发团队的密切合作和沟通。
总之，软件架构重构是提高现有系统性能和可维护性的关键步骤。
通过优化系统的设计、数据处理、并发处理等方面，可以大大提高系统的性能。
软件工程中的软件架构演化与重构策略
软件工程中的软件架构演化与重构策略随着时间推移，软件架构在软件工程领域中扮演着至关重要的角色。
软件架构的设计和演化对于软件系统的质量、可扩展性和维护性有着深远的影响。
本文将讨论软件架构的演化过程以及相应的重构策略。
一、软件架构的演化在软件开发过程中，需求的变更、技术的进步、业务的扩展等因素都可能导致软件架构的演化。
软件架构的演化过程可以分为以下几个阶段：1. 初始架构阶段：在项目开始之初，软件架构通常是根据需求和技术选型初步设计出来的。
这个阶段的主要目标是建立一个满足基本需求的初始架构。
2. 迭代增量阶段：随着项目的进行，新的需求和功能的添加可能会导致软件架构的调整和扩展。
根据实际情况，可以采取增量开发的方式，每一次迭代都对软件架构进行适当的调整和优化。
3. 成熟稳定阶段：当软件系统的功能基本稳定且满足用户需求时，软件架构可以进入成熟稳定阶段。
在这个阶段，主要关注的是优化性能、提升系统的可用性和可靠性等方面。
二、软件架构的重构策略当软件架构出现问题或需要优化时，重构是一个常用的解决方法。
软件架构的重构旨在提高软件系统的质量、可维护性和可扩展性。
下面介绍几种常见的软件架构重构策略：1. 分层架构重构：将单一的层次结构分解为多个逻辑层次，实现各个层次之间的解耦合。
这样可以提高系统的可维护性和可扩展性。
常见的分层架构包括三层架构和MVC架构。
2. 服务化重构：将复杂的单体应用拆分成多个独立的服务，各个服务之间通过接口进行通信。
这种方式可以提高系统的灵活性和可伸缩性，使各个服务独立进行开发和部署。
3. 模块化重构：将系统按照功能或业务划分为多个模块，每个模块都有清晰的职责和接口定义。
这样可以降低模块之间的依赖，提高代码的复用性和可测试性。
4. 数据库重构：对现有的数据库结构进行调整和优化，以提高数据库的性能和可维护性。
常见的数据库重构包括表拆分、表合并、索引优化等。
5. 微服务架构重构：将整个软件系统拆分成多个小型的、独立的服务，每个服务由专门的团队负责开发和维护。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
面向对象方法
之软件重构
1
目录
• • • • • 重构的定义 为什么需要重构 何时需要重构 代码的坏味道 重构的手法
2
重构的定义
• Refactoring (名词): 对软件内部结构的一种调整,
目的是在不改变软件外部行为的前提下,提高其可理 解性,降低其修改成本. • Refactor (动词): 使用一系列重构准则(手法),在不
•
•
17
Switch语句
• 症状：
– 代码使用了一个switch语句，尤其是对一个类型字段 – 代码在某一行上存在多个If语句，特别是对同一个值进行比较时 – 代码使用了instanceof或其等价形式来确定所处理的是何类型
• 措施：
– 如果针对相同的一条switch语句在多处出现，它通常会使用一个 类型码；将其代之以多态内置于对象中。要完成这种改变，需要 采用一系列重构技术：
15
数据泥团
• 症状： – 同样的两至三项数据频繁地一起出现在类和参数表中 – 代码声明了某些字段，并声明了处理这些字段的方法，然后又声明 了更多的字段和更多的方法，如此继续。 – 各组字段名以类似的子串开头或结束
• 措施: – 如果项是类中的字段，则使用抽取类将其取至一个新类中 – 如果值共同出现在方法的签名中，则使用引入参数对象（ introduce parameter object)以抽取新的对象 – 查看由新对象传递这些项的调用，以确定是否可以代之以使 用保持对象完整（preserve whole object) – 查看这些项的使用：通常可以利用移动方法等重构技术，从 而将这些使用移至新的对象中。
• 措施：
– 如果一个类的父类或者子类更适合于完成该类的行为，则通 过折叠继承体系将该类与其父类或子类合并。 – 否则，通过内联类将其行为合并至其调用者。
20
不确定的一般性
• 症状： – 存在未用的类、方法、字段、参数等。它们可能没有客户，或者仅 有测试作为客户 – 对于当前实现的需求，代码过于复杂 措施： – 对于一个不必要的类，可以：
改变起外部行为的前提下,调整其结构.
3
为什么需要重构?
• 改进软件设计 – 缺少重构,程序的设计将变的腐朽 – 缺乏设计的代码通常使用较多的代码做同样的事情 • 使软件易于理解 – 在大多数软件开发环境中,其他人将读你的代码 • 帮助发现缺陷 • 帮助提高编程速度
4
何时应该重构?
• 三次法则 – 第三次做类似的事情时,就要重构 • 增加新功能时 • 修改BUG时 • 代码评审时
• 症状： – 在一个继承体系中建立了一个新的子类，缺发现还需要在另 外一个继承体系中创建一个相关的类。 – 可能发现两个继承体系中子类有相同的前缀（命令可以反映 出协调继承体系的需求） • 措施： – 使用移动字段和移动方法类重新分配字段，从而可以去除某 个继承体系。
19
多余的类
• 症状 – 类并没有做什么工作，似乎是由其父类、子类或者调用者完 成了所有相关的工作，而在此类中却没有足够的行为，以至 于对其是否继续存在会产生质疑。
• 折叠继承体系 • 内联类
•
– 对于一个不必要的方法，使用内联方法或移除方法 – 对于一个不必要的字段，确保没有对它的任务引用，删除之 – 对于一个不必要的参数，使用移除参数（remove parameter) •
说明： – 不要过度设计
21
临时字段
• 症状：
–字段仅在某些时候得到设置，而在其余时间内为null（ 或未用）
23
二传手
• 症状： – 类的大多数方法都是在调用另一个对象的同一个（或类似的 ）方法：
F(){delegate.f();}
• 措施： – 可以通过令客户直接调用委托来移除中间人 – 如果委托由中间人所有，或者是不可变的，而且中间人还有 需要增加的行为，那么此中间人可以看作是委托的一个示例 ，如此则可以采用将委托替换为继承。
9
过大类
• 症状：
–存在大量实例变量 –存在大量方法 –存在大量代码行
• 措施：
–抽取类 –抽取子类 –抽取接口
10
过长参数列表
• 症状： – 方法的参数多于1个或2个
• 后果：
– 难以理解 – 难以记忆 – 容易造成前后不一致
• 措施： –将参数替换为方法 –保持对象完整性 –引入参数对象
11
12
霰弹式修改
• 症状：
–发生一次改变时,需要修改多个类的多个地方
• 措施：
–找出一个应对这些修改负责类，这可能是一个现有的类 ，也可能需要通过抽取类来创建一个新类。 –使用移动字段(move field)和移动方法（move method) 将功能置于所选的类中。如果未选中类足够简单，则可 以使用内联类将该类除去。
26
不完整的库类
• 症状： – 你正在使用一个库类，而且希望在该类上有某个特性，但是 却未能如愿。如果这是一个正常的类，就可以加以修改；但 是，由于这是库的一部分，因此可能无法修改也不希望对它 有所改变。 • 措施： – 查看类或库的所有者是否考虑将来增加你所需的支持。 – 如果仅仅是一两个方法，则可以对库类的客户应用引入外来 方法（Introduce Foreign Method) – 如果存在多个方法需要增加，则要应用引入本地扩展（ Introduce Local Extension）。再进一步使用这个新的扩展 类。 – 可能会决定引入一层来覆盖这个库
6
• • • •
重复的代码
• 症状： – 容易形式：两个代码段看上去几乎相同 – 困难形式：两个代码段都拥有几乎相同的作用 措施： – 抽取方法 – 抽取类 – 替换算法 说明： – 一次,仅仅一次原则
•
•
7
重复的代码
protected void queryBtn(object sender, EventArgs e) { //如果项目编号不为空时 if (this.xmbhText.Text.ToString().Trim(). Equals("") == false) { //对输入的查询条件－－项目编号 是否合法进行校验 Byte[] MyBytes = System.Text.Encoding.Default.GetBytes( this.xmbhText.Text.ToString().Trim()); if (MyBytes.Length > 10) { MessageBox.Alert("项目编号 不能超过10个字节！"); this.xmbhText.Focus(); return; } }
24
过度亲密
• 症状 – 一个类访问了另一个类的内部(本应是私有的）部分。 • 措施 – 如果两个独立的类彼此“纠缠”。使用移动方法和移动字段 ，将适当的部分置于适当的类中。 – 如果纠缠的部分看上去是一个被遗漏的类，则使用抽取类和 隐藏委托引入此新类 – 如果类互相指向对方，则采用将双向引用改为单向引用，使 之成为一种单向依赖 – 如果子类以一种非受控的方式访问其父类的字段，则使用自 封装字段 – 如果父类可以定义一个通用算法，而子类能够插入其中，则 使用构建模板方法 – 如果父类和子类需要进一步解耦合，则采用将继承替换为委 托
• 措施：
–抽取类，移除字段以及所有相关代码
22
消息链
• 症状： – 可能看到如下的调用形式：
a.b().c().d()
• 措施： – 如果处理实际上属于目标对象（即消息链最末的对象），则 使用抽取方法和移动方法将处理置于该对象中。 – 使用隐藏委托使方法仅依赖于一个对象（因此，不采用 a.b().c().d()的形式，而是将一个d()方法置于a对象中。这 可能还需要为b()和c()对象增加一个d()方法）。
//如果项目名称不为空时
if (this.xmmcText.Text.ToString().Trim().Equ als("") == false) { //对输入的查询条件－－项目名称是 否合法进行校验 Byte[] xmmccheck = System.Text.Encoding.Default.GetBytes(thi s.xmmcText.Text.ToString().Trim()); if (xmmccheck.Length > 40) { MessageBox.Alert("项目名称不 能超过40个字节！"); this.xmmcText.Focus(); return; } } //实现数据库绑定 GridView1_DataBind(); } 8
5
代码的坏味道
• • • • • • • • • • • Duplicated Code 重复的代码 Long Method 过长方法 Large Class 过大类 Long Parameter List 过长参数 列表 Divergent Change 发散式变化 Shotgun Surgery 霰弹式修改 Feature Envy 依恋情结 Data Clumps 数据泥团 Primitive Obsession 基本类型 偏执 Switch Statements Switch语句 Parallel Inheritance Hierarchies 平行继承层次 • • • • • • • Lazy Class 多余的类 Speculative Generality 不确定的 一般性 Temporary Field 临时字段 Message Chains 消息链 Middle Man 二传手 Inappropriate Intimacy 过度亲密 Alternative Classes with Different Interfaces 异曲同工的 类 Incomplete Library Class 不完整 的库类 Data Class 数据类 Refused bequest被拒绝的馈赠 Comments 过多的注释
之软件重构
1
目录
• • • • • 重构的定义 为什么需要重构 何时需要重构 代码的坏味道 重构的手法
2
重构的定义
• Refactoring (名词): 对软件内部结构的一种调整,
目的是在不改变软件外部行为的前提下,提高其可理 解性,降低其修改成本. • Refactor (动词): 使用一系列重构准则(手法),在不
•
•
17
Switch语句
• 症状：
– 代码使用了一个switch语句，尤其是对一个类型字段 – 代码在某一行上存在多个If语句，特别是对同一个值进行比较时 – 代码使用了instanceof或其等价形式来确定所处理的是何类型
• 措施：
– 如果针对相同的一条switch语句在多处出现，它通常会使用一个 类型码；将其代之以多态内置于对象中。要完成这种改变，需要 采用一系列重构技术：
15
数据泥团
• 症状： – 同样的两至三项数据频繁地一起出现在类和参数表中 – 代码声明了某些字段，并声明了处理这些字段的方法，然后又声明 了更多的字段和更多的方法，如此继续。 – 各组字段名以类似的子串开头或结束
• 措施: – 如果项是类中的字段，则使用抽取类将其取至一个新类中 – 如果值共同出现在方法的签名中，则使用引入参数对象（ introduce parameter object)以抽取新的对象 – 查看由新对象传递这些项的调用，以确定是否可以代之以使 用保持对象完整（preserve whole object) – 查看这些项的使用：通常可以利用移动方法等重构技术，从 而将这些使用移至新的对象中。
• 措施：
– 如果一个类的父类或者子类更适合于完成该类的行为，则通 过折叠继承体系将该类与其父类或子类合并。 – 否则，通过内联类将其行为合并至其调用者。
20
不确定的一般性
• 症状： – 存在未用的类、方法、字段、参数等。它们可能没有客户，或者仅 有测试作为客户 – 对于当前实现的需求，代码过于复杂 措施： – 对于一个不必要的类，可以：
改变起外部行为的前提下,调整其结构.
3
为什么需要重构?
• 改进软件设计 – 缺少重构,程序的设计将变的腐朽 – 缺乏设计的代码通常使用较多的代码做同样的事情 • 使软件易于理解 – 在大多数软件开发环境中,其他人将读你的代码 • 帮助发现缺陷 • 帮助提高编程速度
4
何时应该重构?
• 三次法则 – 第三次做类似的事情时,就要重构 • 增加新功能时 • 修改BUG时 • 代码评审时
• 症状： – 在一个继承体系中建立了一个新的子类，缺发现还需要在另 外一个继承体系中创建一个相关的类。 – 可能发现两个继承体系中子类有相同的前缀（命令可以反映 出协调继承体系的需求） • 措施： – 使用移动字段和移动方法类重新分配字段，从而可以去除某 个继承体系。
19
多余的类
• 症状 – 类并没有做什么工作，似乎是由其父类、子类或者调用者完 成了所有相关的工作，而在此类中却没有足够的行为，以至 于对其是否继续存在会产生质疑。
• 折叠继承体系 • 内联类
•
– 对于一个不必要的方法，使用内联方法或移除方法 – 对于一个不必要的字段，确保没有对它的任务引用，删除之 – 对于一个不必要的参数，使用移除参数（remove parameter) •
说明： – 不要过度设计
21
临时字段
• 症状：
–字段仅在某些时候得到设置，而在其余时间内为null（ 或未用）
23
二传手
• 症状： – 类的大多数方法都是在调用另一个对象的同一个（或类似的 ）方法：
F(){delegate.f();}
• 措施： – 可以通过令客户直接调用委托来移除中间人 – 如果委托由中间人所有，或者是不可变的，而且中间人还有 需要增加的行为，那么此中间人可以看作是委托的一个示例 ，如此则可以采用将委托替换为继承。
9
过大类
• 症状：
–存在大量实例变量 –存在大量方法 –存在大量代码行
• 措施：
–抽取类 –抽取子类 –抽取接口
10
过长参数列表
• 症状： – 方法的参数多于1个或2个
• 后果：
– 难以理解 – 难以记忆 – 容易造成前后不一致
• 措施： –将参数替换为方法 –保持对象完整性 –引入参数对象
11
12
霰弹式修改
• 症状：
–发生一次改变时,需要修改多个类的多个地方
• 措施：
–找出一个应对这些修改负责类，这可能是一个现有的类 ，也可能需要通过抽取类来创建一个新类。 –使用移动字段(move field)和移动方法（move method) 将功能置于所选的类中。如果未选中类足够简单，则可 以使用内联类将该类除去。
26
不完整的库类
• 症状： – 你正在使用一个库类，而且希望在该类上有某个特性，但是 却未能如愿。如果这是一个正常的类，就可以加以修改；但 是，由于这是库的一部分，因此可能无法修改也不希望对它 有所改变。 • 措施： – 查看类或库的所有者是否考虑将来增加你所需的支持。 – 如果仅仅是一两个方法，则可以对库类的客户应用引入外来 方法（Introduce Foreign Method) – 如果存在多个方法需要增加，则要应用引入本地扩展（ Introduce Local Extension）。再进一步使用这个新的扩展 类。 – 可能会决定引入一层来覆盖这个库
6
• • • •
重复的代码
• 症状： – 容易形式：两个代码段看上去几乎相同 – 困难形式：两个代码段都拥有几乎相同的作用 措施： – 抽取方法 – 抽取类 – 替换算法 说明： – 一次,仅仅一次原则
•
•
7
重复的代码
protected void queryBtn(object sender, EventArgs e) { //如果项目编号不为空时 if (this.xmbhText.Text.ToString().Trim(). Equals("") == false) { //对输入的查询条件－－项目编号 是否合法进行校验 Byte[] MyBytes = System.Text.Encoding.Default.GetBytes( this.xmbhText.Text.ToString().Trim()); if (MyBytes.Length > 10) { MessageBox.Alert("项目编号 不能超过10个字节！"); this.xmbhText.Focus(); return; } }
24
过度亲密
• 症状 – 一个类访问了另一个类的内部(本应是私有的）部分。 • 措施 – 如果两个独立的类彼此“纠缠”。使用移动方法和移动字段 ，将适当的部分置于适当的类中。 – 如果纠缠的部分看上去是一个被遗漏的类，则使用抽取类和 隐藏委托引入此新类 – 如果类互相指向对方，则采用将双向引用改为单向引用，使 之成为一种单向依赖 – 如果子类以一种非受控的方式访问其父类的字段，则使用自 封装字段 – 如果父类可以定义一个通用算法，而子类能够插入其中，则 使用构建模板方法 – 如果父类和子类需要进一步解耦合，则采用将继承替换为委 托
• 措施：
–抽取类，移除字段以及所有相关代码
22
消息链
• 症状： – 可能看到如下的调用形式：
a.b().c().d()
• 措施： – 如果处理实际上属于目标对象（即消息链最末的对象），则 使用抽取方法和移动方法将处理置于该对象中。 – 使用隐藏委托使方法仅依赖于一个对象（因此，不采用 a.b().c().d()的形式，而是将一个d()方法置于a对象中。这 可能还需要为b()和c()对象增加一个d()方法）。
//如果项目名称不为空时
if (this.xmmcText.Text.ToString().Trim().Equ als("") == false) { //对输入的查询条件－－项目名称是 否合法进行校验 Byte[] xmmccheck = System.Text.Encoding.Default.GetBytes(thi s.xmmcText.Text.ToString().Trim()); if (xmmccheck.Length > 40) { MessageBox.Alert("项目名称不 能超过40个字节！"); this.xmmcText.Focus(); return; } } //实现数据库绑定 GridView1_DataBind(); } 8
5
代码的坏味道
• • • • • • • • • • • Duplicated Code 重复的代码 Long Method 过长方法 Large Class 过大类 Long Parameter List 过长参数 列表 Divergent Change 发散式变化 Shotgun Surgery 霰弹式修改 Feature Envy 依恋情结 Data Clumps 数据泥团 Primitive Obsession 基本类型 偏执 Switch Statements Switch语句 Parallel Inheritance Hierarchies 平行继承层次 • • • • • • • Lazy Class 多余的类 Speculative Generality 不确定的 一般性 Temporary Field 临时字段 Message Chains 消息链 Middle Man 二传手 Inappropriate Intimacy 过度亲密 Alternative Classes with Different Interfaces 异曲同工的 类 Incomplete Library Class 不完整 的库类 Data Class 数据类 Refused bequest被拒绝的馈赠 Comments 过多的注释