在软件开发中,存在许多常见的代码坏滋味(code smells),它们指示出潜在的规划或完成问题。下面是一些常见的代码坏滋味以及相应的重构办法:

  1. Duplicated Code(重复代码):
  • 坏滋味:代码中存在相同或非常相似的代码片段。
  • 重构办法:将重复的代码抽取为办法或函数,经过调用来避免重复。
  1. Long Method(过长的办法):
  • 坏滋味:办法过长,包括过多行数或杂乱逻辑。
  • 重构办法:将长办法分解为多个小办法,每个办法担任一个清晰的使命,进步代码的可读性和可保护性。
  1. Large Class(过大的类):
  • 坏滋味:类过于巨大,承当了过多的责任。
  • 重构办法:将类的功用分解为多个小类或模块,每个类只担任一个清晰的责任,进步类的可了解性和可保护性。
  1. Long Parameter List(过长的参数列表):
  • 坏滋味:办法的参数列表过长,增加了办法的杂乱性和调用的困难度。
  • 重构办法:将相关的参数封装为目标或数据结构,或许运用重构形式(如Builder形式)来简化参数传递。
  1. Primitive Obsession(根本类型偏执):
  • 坏滋味:过度运用根本数据类型,而不是创立专门的类来表明概念。
  • 重构办法:创立恰当的类来表明相关的概念,进步代码的可读性和可保护性,一起供给更丰富的行为和封装。
  1. Switch Statements(过多的switch语句):
  • 坏滋味:代码中存在很多的switch或if-else语句,难以扩展和保护。
  • 重构办法:运用多态、战略形式或工厂形式等技能,将条件逻辑转移到不同的类中,进步代码的灵活性和可扩展性。
  1. Lazy Class(无用的类):
  • 坏滋味:存在没有实践功用或用途的类。
  • 重构办法:移除无用的类,或许将其与其他类合并,以削减代码库中的冗余。
  1. Data Clumps(数据泥团):
  • 坏滋味:代码中多个当地呈现相同的参数组合,表明它们或许应该被封装为一个独自的目标。
  • 重构办法:创立一个新的类来封装这些相关参数,进步代码的可读性和可保护性。
  1. Feature Envy(眷恋情结):
  • 坏滋味:一个类对另一个类的办法有过多的调用,或许表明这些办法应该属于该类。
  • 重构办法:将被眷恋的办法移动到调用它的类中,改进代码的一致性和聚合性。
  1. Shotgun Surgery(散弹式修正):
  • 坏滋味:对一个功用的修正需求在多个不同的类或模块中进行很多的修正。
  • 重构办法:将相关的功用会集到一个类或模块中,以削减修正的规模。
  1. Message Chains(音讯链):
  • 坏滋味:代码中存在长串的办法调用,形成冗长的音讯链。
  • 重构办法:运用中间目标或办法来封装音讯链,简化代码的调用和保护。
  1. Middle Man(中间人):
  • 坏滋味:一个类只是托付给另一个类的办法,过度增加了类之间的耦合性。
  • 重构办法:消除中间人类,直接调用被托付的类的办法,简化代码结构。
  1. Speculative Generality(过度泛化):
  • 坏滋味:增加杂乱的笼统、接口或类层次结构,但实践上并没有真正的需求。
  • 重构办法:去除不必要的笼统,简化代码结构,只有在的确需求时才进行泛化规划。
  1. Parallel Inheritance Hierarchies(平行承继体系):
  • 坏滋味:存在两个类承继体系,彼此之间存在强耦合,导致扩展和保护困难。
  • 重构办法:运用组合联系替代承继,将同享的行为封装到独自的类中,削减承继的依靠。
  1. Comments(过多的注释):
  • 坏滋味:代码中存在很多冗长、无效或重复的注释。
  • 重构办法:重构代码,使其自我解说,并删除不必要的注释,使代码愈加清晰和易懂。
  1. Refused Bequest(回绝的遗赠):
  • 坏滋味:子类只运用了父类的部分办法,而其他办规律被回绝运用。
  • 重构办法:重新规划承继联系,使子类只包括需求的办法,或许将回绝运用的办法移动到其他类中。
  1. Lazy Initialization(推迟初始化):
  • 坏滋味:目标在第一次运用之前不会被初始化,导致额定的推迟和性能开销。
  • 重构办法:在目标被运用之前进行初始化,避免不必要的推迟和潜在的过错。
  1. God Class(上帝类):
  • 坏滋味:一个类担任过多的功用,成为体系中的中心点,导致类变得巨大且难以保护。
  • 重构办法:将类的功用分解为更小的、责任单一的类,进步代码的可读性和可保护性。
  1. Inappropriate Intimacy(过度亲密):
  • 坏滋味:两个类之间的交互过于亲近,相互依靠过多。
  • 重构办法:经过引进中间层或运用事件驱动的方式,削减类之间的直接依靠联系。
  1. Incomplete Library Class(不完整的库类):
  • 坏滋味:运用的第三方库或结构中的类短少所需的功用。
  • 重构办法:经过承继、组合或适配器形式,扩展库类以满意详细需求。
  1. Excessive Coupling(过度耦合):
  • 坏滋味:类之间的依靠联系过多,修正一个类或许导致级联的修正。
  • 重构办法:运用规划形式如依靠注入(Dependency Injection)或解耦合形式,削减类之间的紧耦合联系。
  1. Data Class(数据类):
  • 坏滋味:一个类只是用于封装数据,缺少行为和功用。
  • 重构办法:将数据类转换为具有行为和功用的类,遵从面向目标的规划准则。
  1. Feature Creep(功用延伸):
  • 坏滋味:体系的功用不断增加,导致代码变得杂乱且难以保护。
  • 重构办法:运用分解和重组的办法,拆分体系为更小的、高内聚的模块,简化体系的杂乱性。
  1. Magic Numbers(魔法数):
  • 坏滋味:代码中存在未经解说的详细数值,下降代码的可读性和可保护性。
  • 重构办法:将魔法数值提取为常量或枚举,增加代码的可读性和可保护性。

iOS中特有的坏滋味及重构办法

  1. Massive View Controller(巨大的视图控制器):

    • 坏滋味:视图控制器包括很多的事务逻辑和视图办理代码,导致代码巨大、难以保护和测验。
    • 重构办法:运用MVVM(Model-View-ViewModel)或MVC(Model-View-Controller)等架构形式,将事务逻辑和视图办了解耦,将代码分解成更小、可测验的组件。
  2. Massive Model(巨大的模型):

    • 坏滋味:模型类包括过多的特点和办法,违反了单一责任准则,难以了解和保护。
    • 重构办法:将大型模型类分解为多个更小的模型类,每个类担任一个清晰的使命。运用组合或承继来安排模型之间的联系。
  3. Massive Storyboard(巨大的故事板):

    • 坏滋味:故事板包括很多的视图控制器和视图之间的连接联系,导致故事板杂乱、难以保护和协作。
    • 重构办法:将故事板拆分为多个较小的故事板,根据模块、功用或视图层级进行划分。运用故事板引证和导航控制器等技能来办理不同故事板之间的导航。
  4. Massive XIBs(巨大的XIB文件):

    • 坏滋味:XIB文件包括很多的视图和视图之间的连接联系,导致文件巨大、难以了解和保护。
    • 重构办法:将XIB文件拆分为多个较小的XIB文件,根据视图层级或功用进行划分,运用代码或接口构建视图层次结构。
  5. Tight View-Controller Coupling(视图控制器紧耦合):

    • 坏滋味:视图控制器与特定的视图高度耦合,导致视图控制器难以重用和测验。
    • 重构办法:运用视图模型(ViewModel)将视图控制器与视图解耦,将视图控制器的责任限制在呼运用户交互和协调事务逻辑方面。
  6. Massive Networking Code(巨大的网络代码):

    • 坏滋味:网络请求和处理逻辑分布在运用的多个当地,导致代码重复和难以保护。
    • 重构办法:创立网络服务层或运用现有的网络结构(如Alamofire)来会集处理网络请求和呼应逻辑。将网络请求和处理逻辑封装为可重用的组件,并保证恰当的过错处理和成果处理机制。
  7. Lack of Error Handling(缺少过错处理):

    • 坏滋味:缺少对过错和异常情况的恰当处理和反应,或许导致运用溃散或不可猜测的行为。
    • 重构办法:在恰当的方位增加恰当的过错处理机制,包括过错捕获、过错传递、过错回调或运用Result类型等。经过杰出的过错处理机制,增强运用的稳定性和可靠性
  8. Overuse of Singletons(滥用单例形式):

    • 坏滋味:过度运用单例形式导致大局状况和同享状况的混乱,使代码难以测验和扩展。
    • 重构办法:运用依靠注入和面向协议编程等技能来削减对单例的依靠。将同享的状况封装在恰当的组件中,并经过结构函数或特点注入来访问这些组件。
  9. Massive View Hierarchy(巨大的视图层次结构):

    • 坏滋味:一个视图层次结构包括很多的视图和子视图,导致性能下降、内存占用增加和布局杂乱。
    • 重构办法:运用容器视图、自定义视图或视图组合来简化视图层次结构。
  10. Lack of Code Modularization(缺少代码模块化):

    • 坏滋味:代码在整个项目中重复呈现,缺少可重用性和可保护性。
    • 重构办法:将常用的功用和逻辑提取为独立的模块或库,并在需求时进行引证。运用模块化的规划准则和形式来进步代码的安排性和可重用性。
  11. Inefficient Data Fetching(低效的数据获取):

    • 坏滋味:数据获取和处理逻辑不高效,导致性能下降和用户体会差。
    • 重构办法:运用适宜的数据获取技能,如异步操作、缓存和批量加载,以进步数据获取的效率。优化数据结构和算法,削减不必要的网络请求和数据处理。
  12. Poor Memory Management(差劲的内存办理):

    • 坏滋味:缺少对内存的恰当办理,导致内存走漏、内存正告和运用溃散。
    • 重构办法:运用主动引证计数(ARC)机制来办理内存,保证正确地增加和释放目标的引证。避免循环引证和强引证,运用弱引证和无主引证来解决目标之间的引证联系。

重构是一个持续的进程,旨在改进代码的质量和可保护性。经过识别和纠正代码中的坏滋味,可以使代码愈加健壮、可读和易于扩展。