怎样去构建一个可以维护的项目
前提
你要知道一个项目，当前存在什么问题，导致烂掉的。
小记录（前后端）
- this 传来传去
- 传大对象
- 底层和高层分离
- 拼写错误
- 长方法
- 没测试
- 可读性差
- magic number
- mutable
- 静态方法过多
好项目
传大对象
很明显违反了
最少知识原则。对于被调用方，通常知道的越少越好，这样被调用方，做的事情就会非常有限，方法就会变得很小。 如果给个大对象。。
底层和高层分离
底层抽象过高，使用层和低层要有一层类似于胶水层的东西。
对比前端
有个基础组建库的底层高阶抽象层， UI层和抽象的底层之间有一层抽象去让底层不那么抽象。通常是小组件。
对比后端
有人给你封装了一套数据库操作的接口， controller层直接用，没有service层去当胶水层。
拼写错误
这个问题，初看觉得问题不大，但是时间长了，「破窗效应」就出现了，随着时间越长，雪球也会越滚越大。
长方法
方法过大导致的问题，老生长谈了。 这里就不提了。
没测试
这是最要命的，这是导致项目快速烂掉的最佳方式。谁都不敢动，动了就有可能产生bug。
可读性差
这不就是烂代码的标准表现吗！
也是「破窗效应」的表现。
magic number
类似于
class SomeClass {
// 性别字段
// 1 代表男， 2 代表女
private Integer gender;
}
这种 magic number 是不是很痛苦，用个枚举不香吗？？？
「破窗效应」。。。
mutable 可变对象
面向对象的Java，一切皆对象，一切皆引用。一切皆可变， 一不小心就会修改对象的引用。
所有的方法都可以变成为返回值为 void, 然后去搞「骚操作」。
这么做是没有太大问题的，只是代码不太容易阅读而已。
但是又一个致命的问题，就是测试比较难写。
如何这个对象穿的层次比较深，传了两层以上。 测试只需要测试当前的一层，但是依赖的另一层对原始对象的修改，另一层又是mock的，因为当前测试不关心。
于是就没法写单元测试，只能写集成测试。
所以推荐修改对象方法只保证在当前层里，尽量不要去让修改对象引用传递超过两层及以上
静态方法过多
静态方法过多，并且静态方法干的事情，比较复杂，测试写起来也是比较难的。
总结
聊了一些自己在项目中遇到的问题，以及导致的后果，希望对别人有些帮助吧。