【项目重构】第1次思考
回顾与反思
2022年~至今(2023年2月),一共重构了2个项目。
第1个项目在重构的时候,总是想着把别人的代码copy过来,改一改,这就算重构好了。这样做效率太低,原因是前人写的代码不一定有很多注释,有注释有可能写的也不清楚。还有一点比较重要的是,自己写的思路可能和前人不太一样,那么直接改他的代码就需要先看懂他的代码思路,这个过程是很花时间的。
第2个项目在重构的时候,还没有完全摸清楚项目整体架构,就直接动手开始写了。这样做也存在很多问题,比如写的过程中由于有的细节没有搞清楚,会出现写到这里的时候发现和前面的结构、逻辑不太一样,又重新改动,又或者是输入、输出、数据结构不统一等问题。
总结下来,自己的问题包括:
- 先从别人的代码入手,改别人的代码进行重构
- 没有完全弄清楚项目架构就开始重构
这些也是今后需要改进的地方。
改进方向
- 项目对接:首先最好要和项目前一个负责人对接好,搞清楚项目整体的框架。记住是只抓架构,切忌抠细节。这一部分要花大量时间,一定要耐住性子,搞清楚项目架构的每一步的作用,输入输出是什么。
- 开始重构:弄清架构后,就可以开始重构了。重构可以按如下步骤进行:
(1)先按架构搭建好整体流程,每一步用函数代替,函数体暂时空缺出来。在这个过程中,可能会有发现自己对项目的理解和原项目有一定的出入,比如每一步的作用、每一步的输入输出、每一步的输入输出的顺序等。这个时候要及时和前负责人讨论,证明自己的理解或者证伪自己的理解,然后完善理解,对流程反复做出调整,最后形成一个正确的框架。
(2)搭建好框架之后,再针对每个函数逐步实现细节。这个时候就可以参考,甚至是直接copy前负责人写的代码。
重构给我带来的思考
(重构让我知道代码写的不好维护看起来真的脑壳痛。。)
根据我个人的习惯,我觉得在写代码的时候可以从以下几点去注意:
- 函数参数不能太多,最多只能有3、4个
- 一行代码最好就是一个功能,多利用函数式编程,这样在调试的时候只需要注释一样,很方便
- 避免过多的嵌套,嵌套层数不要超过3层,可以利用抽离函数、
return
等方式减少嵌套次数 - 写的时候一定要边写边测试,测试的部分最好是一个最小单元