代码的可维护、便于重构性

昨天写代码，思考了参数写死不写死的问题。路径参数，一般是有一个根据计算得到的绝对路径，然后再搭配相对路径。

为了便于维护、重构：

1.现实场景，现实中我需要修改某个函数功能。那么，我希望我的代码修改得越少越好。即我涉及到的功能，同一层级的都全部相对独立，不要互相干涉（第一层调用算第一层；调用函数再调用算第二层。最上层函数算0层）。

2.基本功能函数做到单一，不得以不要有交叉；（底层函数）；

3.函数要考虑被使用的场景，如果一个函数只为一个场景服务，那就写死；否则不要写死。

举例子，层层解压，并移动的小功能块。

第一步：划分为子功能：解压操作、移动操作；上层功能的构建，利用逻辑对某一个文件路径下的某个压缩包（包内可能还有压缩）进行解压；【此时需要考虑再加一个递归检索压缩包的子功能】。

第二步：考虑功能场景。

1.解压操作是要解压不同压缩格式的，所有可以考虑不写死，可以考虑让传入压缩格式（如果解压库函数需要指定的话）//也可以构建一个解压所有格式的函数，把对压缩包格式判断放解压函数内。我觉得放解压函数内好，因为它对外提供了一个尽可能简单的接口（让别人用的时候，不用考虑提取格式，少了一段代码，用起来舒服），同时实现的功能相同；2.可以考虑让提供一个解压目的地，因为解压人可能需要解压到不同的目的地。应该判断路径是否存在，不存在返回错误，不会生成路径？第一要考虑对方输入路径错误、第二，如果增加了生成路径的功能，解压操作就不纯粹了？

2.场景划分角度很重要。

将待处理文件划分为.7z 或者 非.7z，可能每一类内就会有特殊情况；按功能划分就会好点。

将待处理情况分类，尽量每一类内情况类似；且有个前提：各个类别可扩展性要好！

 

待思考

移动操作，如果永远移到根目录，就写死；有不同的目的地，就不写死。

代码书写过程中，我们往往根据直觉（某个库函数可以怎么用），这个函数返回是一个list就模糊着写了。还应该进一步思考，每一步中变量的类型；变量的维度。这又需要对一门语言，语法规则的详细了解而不是简单的入门说明。这样才能尽量减少代码bug

待续