进去新项目，接手这样的代码怎么办

最近来到新的项目组，接手了一个离职员工的代码，阅读后感觉有较大的优化改进空间，于是乎着手调整，谁知，开始时调整的还挺有成就感，可是后面真的会越来越感觉到痛苦了，开始理解了为什么很多老员工宁愿哪里出问题去补哪里也不愿意做出大调整的心理了！

 

今天下了班，但是在想着那个模块的代码，怎么会写成这样？怎么简化/优化/优雅？

 

夜深了，在床上也就梳理下思想。

 

 细节的简化:

1.数据库交互相关方法简化

旧版:一个SQL操作需要一个方法，一个方法三四十行的一个大代码块，不同方法间代码重复率很高，整体看来代码非常冗余。

新版:抽出SQL语句，方法题重复的部分工具化，用的时候就传个SQL拿返回值。

2.分支判断内代码冗余

if块内和else块内有大量的重复代码，可以提出到判断外，判断块内只需要放不同条件的执行语句。

 

代码结构调整

 

模块化

旧版:All in One 几乎全部东西都在一个类里，没有分层化、模块化，在分析代码的时候，有时候从十几行跳到几十行，又跳到几百行，甚至两千行，又跳到第四五百行，不是太好阅读，不利于团队其他成员接手，不利于问题排查和维护。

 

文件操作，数据库操作，业务处理 柔和在一起，一个方法操作数据库的方法又带有去写文件的代码，耦合度相当高，代码分析、维护、他人接手都会带来一定的难度。

 

语义化

对于非直接暴露的变量名、方法名、类名，在命名上不至于要简洁到一两个字母代表一个含义吧😄，ge是啥？太简写了后面接手的人理解成本高啊，名字写全点通俗点可能会长一点，但是理解起来很方便。

特例？有些方法叫getxxxxxx，但是返回类型是void，方法里执行的效果是生成文件，叫createxxxxxxx不更好吗

 

简化

分层/分包/模块化/降低耦合/去除冗余: 

业务层 :主要业务的处理

数据层:与数据库交互，返回数据结果

工具包:文件类、时间类

 

总之，就是应该通过规范化，降低他人在代码理解上花的成本，通过规范化，降低问题排查，代码升级维护所需要的成本。

 

 

转 https://www.cnblogs.com/haola/p/15669919.html