本系列文章皆在从记录日常重构项目代码中发现的一些"丑陋的代码"，同时分享记录开发中容易忽视的问题和错误，带你规避Java开发中的各种"坑"。
思考，输出，沉淀。用通俗的语言陈述技术，让自己和他人都有所收获。
作者：毅航😜
前言
在前一章代码重构之路：编写方法时最易忽视的"问题"中，我们对方法编写过程中容易忽视的：长参数列表、长函数、重复代码、判断逻辑嵌套等问题进行总结和归纳。事实上，如果你有面向对象编程的相关经验的话，你应该知道，在面向对象编程中类是一个蓝图，它定义了一种对象的结构和行为。
而在这个蓝图中，我们可以包含变量、方法等。其中变量用来存储对象的状态信息，也就是对象的属性。而方法则用以描述对象可以执行的操作或行为。 本章我们将主要讨论类文件编写时容易忽视的几个问题。
类结构"庞大"
不知你见过的"大类"是什么样的，反正笔者迄今见到过进6000行的类信息 。其实所谓"大类"和我们之前分析的"长参数列表、长函数"一样，特指类内容过于臃肿，导致一眼望不到头 。在实际开发中，导致"大类"产生的原因可能是多种多样的，但总结下来无非以下两点：
- 类中存在过多的
长函数。 这些长函数导致类结构开始变得复杂，进而使得类结构信息显得臃肿； - 变量、方法不断的聚集。 可能类内每个函数可能都不算太长，但是将太多处理逻辑、变量信息都聚集在一个类中，导致类负责太多功能，从而使得类结构信息发生
膨胀,进而成为一个"大类"。
事实上，如果一个类里面囊括太多信息，不仅会导致类后期复用和维护的困难，而且导致类中业务逻辑的难于理解。由于我们对于东西的理解能力是有限的，所以为了降低我们理解一件事物的难度，在编写类文件时，应该尽可能秉持单一职责原则来编写类文件，即一个类或模块应该有且仅有一个引起它变化的原因。换句话说，一个类或模块应该只负责一个具体的功能，不应该承担过多的职责。
正如我们之前分析解决长函数解决之道那样，解决"大类"的问题的关键也在于分而治之。即尽可能保证一个类仅在某个单一的领域中提供服务。
至此，或许你已经发现，当面对"大类、长参数列表、长函数"这类问题时,分而治之的思想是最朴素有效的手段，而拆分的本质理念就是要保证类或方法的功能单一。
类中残留大量已注释代码或无用方法
就像阿里开发规范所建议的那样："我们应该及时删除类中的无用代码" 。然而，在日常开发中我们经常会有这样的经历，即有时候当我们会发现某个业务处理写错了，于是我们可能只是注释掉相关的代码，将错误的逻辑保留在类中。或者当某个功能需求已经废弃时，仍然将相关的代码保留在类中。而这样的做法只会干扰开发者对代码的理解，使得代码变得更加混乱和难以阅读。。进一步，未删除掉已注释或废弃代码将会增加类文件的体积，虽然单个注释或废弃代码可能不会占用太多空间，但积小成多，其实很多事情都是因为一开始不注意，导致后期维护变得越来越困难。
因此，为了代码的整洁，请务必及时删除类中的无用代码。
变量在类文件中随意赋值
众所周知变量在类文件中扮演着不可或缺的角色 。根据我们对变量的理解，可以将变量的生命周期分为两个关键步骤：声明和赋值 。然而，在我接手的工程项目中，我常常看到在一个类内部，变量的赋值到处都是。换言之，变量的赋值没有被统一集中到类的某个特定位置。这样所带来的问题就是变量的管理将变得非常困难。
通常情况下，变量一旦被赋值就代表着，就需要紧随其后一系列复杂的处理逻辑来使用这些变量。这样一来，我们就把业务逻辑和变量操作混杂在一起，导致在后期维护代码时，我们不得不费力地从复杂的逻辑中挖掘出变量初始化的时机。
有时候，代码之所以变得难以理解，很大程度上是因为类中的变量信息缺乏统一的管理。 换言之，由于我们无法准确掌握变量的初始化时机，因此在理清类的功能时，我们只能像摸黑一样，一行一行地进行代码调试。
总结
本章我们总结分析了类文件编写时最容易的几个问题。事实上，这些东西或许你也知道，但是知道和做到之间毕竟存在着某种鸿沟。代码重构本身就是一件推倒重来过程，既然代码能运行为何费尽心思去重构？不如花点时间享受时光，何必让自己那样劳累？
我也曾有过这样的疑惑，但今天我下班时听到的其他同事说了的一句话，我编程这么久了，第一次间有人数据库字段用中文命名 。这听着很搞笑是吧？但这种离谱事件可能就发生的在我们身边。
正如古语说的那样："求其上的其中,求其中得其下" 。人总是要不断向上攀登的，或许，你觉得这是所谓的"卷"。事实上，朝错误的方向不断费死劲称为卷，从而导致不断的内耗，损人不利己。而朝着正确方向不断努力，则只会让自己不断精进。
其实，编程考验的本身就是我们对于一件事物的抽象和统筹规划能力，如果不注重从小处能力的养成，那么当机会来临的那一天也只能与机会失之交臂。
共勉~