背景
在公司写了将接近一年的业务代码，自己维护自己的代码，同时也接手过别人的代码，不断地重构过程中，自己也不断地思考和总结：如何写好代码？
为啥需要写好代码
可讲的理由太多，说两点：
- 这份代码不是只有你自己看，别人看到这份代码，如果写的太差，可读性很差，估计别人就不会认可的作者代码水平(要是个接盘侠，估计背地里也就开始骂娘了).
- 可维护性太差，谁敢改？全是坑。
一些原则
保持代码洁癖
代码风格严谨的团队，从代码的基本规范，代码的命名，函数的抽取，类的抽取，最后UT的覆盖率，OOP,以及设计模式的运用，都会有要求，本身在学生时代，或多或少接触过代码规范问题，
有些意识，但是在生产环境，就需要特别加强。
最近阿里的java代码规范的开源，还是比google的代码规范详尽很多，涉及了例如函数设计的经验，作为一个职场的新人，至少得把这份规范好好研读下
代码的可维护性是个长期的过程
业务代码就是这样，不断地随着业务在改，很多代码慢慢的就没用了，脏代码越来越多，慢慢这套代码就需要进行重构了
- 删除没用的代码
- 避免相同的代码（或相近）出现在3个或以上的类里面，注意提取
- 避免一个类写的太长，一个类大于300 line，我觉得就要拆了，业务代码嘛，就按业务功能拆开，提取公用的部分。
最近接手一个工程，看到一个service，写了1500 行，那感觉真是日了* 。
UT
- 至少覆盖静态类
工程的配置文件的配置常量问题
- 工程配置常量集中化管理
工程有很多的根据环境不同(生产环境，预上线环境，测试环境，本地环境)配置变量不同的情况，这些配置常量需要提取集中化到配置常量文件中，不能到处散落在各地，不好维护