怎样去构建一个可以维护的项目 怎样去构建一个可以维护的项目

前提

你要知道一个项目，当前存在什么问题，导致烂掉的。

小记录（前后端）

• this 传来传去
• 传大对象
• 底层和高层分离
• 拼写错误
• 长方法
• 没测试
• 可读性差
• magic number
• mutable
• 静态方法过多

好项目

传大对象

很明显违反了最少知识原则。对于被调用方，通常知道的越少越好，这样被调用方，做的事情就会非常有限，方法就会变得很小。 如果给个大对象。。

底层和高层分离

底层抽象过高，使用层和低层要有一层类似于胶水层的东西。

对比前端

有个基础组建库的底层高阶抽象层， UI层和抽象的底层之间有一层抽象去让底层不那么抽象。通常是小组件。

对比后端

有人给你封装了一套数据库操作的接口， controller层直接用，没有service层去当胶水层。

拼写错误

这个问题，初看觉得问题不大，但是时间长了，「破窗效应」就出现了，随着时间越长，雪球也会越滚越大。

长方法

方法过大导致的问题，老生长谈了。 这里就不提了。

没测试

这是最要命的，这是导致项目快速烂掉的最佳方式。谁都不敢动，动了就有可能产生bug。

可读性差

这不就是烂代码的标准表现吗！

也是「破窗效应」的表现。

magic number

类似于

class SomeClass {
    // 性别字段
    // 1 代表男， 2 代表女
    private Integer gender;
}

这种 magic number 是不是很痛苦，用个枚举不香吗？？？

「破窗效应」。。。

mutable 可变对象

面向对象的Java，一切皆对象，一切皆引用。一切皆可变， 一不小心就会修改对象的引用。

所有的方法都可以变成为返回值为 void, 然后去搞「骚操作」。

这么做是没有太大问题的，只是代码不太容易阅读而已。

但是又一个致命的问题，就是测试比较难写。

如何这个对象穿的层次比较深，传了两层以上。 测试只需要测试当前的一层，但是依赖的另一层对原始对象的修改，另一层又是mock的，因为当前测试不关心。

于是就没法写单元测试，只能写集成测试。

所以推荐修改对象方法只保证在当前层里，尽量不要去让修改对象引用传递超过两层及以上

静态方法过多

静态方法过多，并且静态方法干的事情，比较复杂，测试写起来也是比较难的。

总结

聊了一些自己在项目中遇到的问题，以及导致的后果，希望对别人有些帮助吧。