有时候，丰富的经验的确能少躺很多坑，但实际上，很多经验也是躺了坑才有的。
1.根据实际情况确定是否在service层需要接口，没有必要遵循什么规范，用不上的就不要写，增加修改难度。
2.如果发现另一种实现方式更好，但是如果更新需要改动的代码很多，并且新实现并不是解决了上一套实现的存在的严重效率耗时问题，那么就额外写一套实现，不要去动原本的代码，没有必要耗费时间在这上面。
3.在vo层面通过重写get方法的确可以影响将BigDecimal转为前端显示需要的某种特殊格式，但如果后面需求修改涉及到了计算的话，虽然仍可以通过增加一个不同名的get方法返回原本的BigDecimal类型，但这样的实现未免有些？ 所以用不用dto作为中间类可以考虑下。最主要的问题还是我没有掌握Bean的频繁get和set是否对效率有很大影响。
4.变量取名的时候，不要半吊子。如果名称太长，那么就用关键的能描述特性的词，要不然就全翻译，不要翻译到一半，这样子后期会有很大影响。如果存在特别多的长单词，用拼音首字母也不是不可以，但是如果是一些拗口的次，用拼音首字母不能第一时间想到原本的中文，那还是写英文全拼吧。不太考虑全拼音，特别是半拼音和半英文。
5.整个项目共有一个实现比较好，可能多种实现都差不多，性能和其他方面都没什么太大差别，那么就只用一种。万一后期需要修改代码，这个样子比较方便。
6.某些参数最好单独用一个变量存放，然后命名要一致，且突出其性质。比如month，initMonth，calcMonth，shouMonth分别代码前端传入的month，经过处理后的month，用来参入计算的month，返回给前端显示的month。
7.比较可能需要debug的地方，不要把一大块代码一行就写完了，这个地方出了问题有点麻烦，虽然这么写的都是一些逻辑性而非计算性的代码，基本上没出问题。主要是那种debug测试需要看结果或者输出的代码，但是又放在某个语句里面。
8.excel和txt需要分别显示结果的东西，可以用map。
9.多掌握一些算法和数据结构，有些时候真的很有用。
10.用心写代码，不要老是出一些粗心的错误，浪费测试人员时间和自己的时间。
11.开发的时候遇到问题一定要记录下来，遇到某些重大需求模糊的地方，一定要给自己留后路，想想最坏情况下是否有什么好的方法解决使其不影响现在的代码实现。
12.注释写好一些，除非你觉得自己的命名可以使自己至少半年不会出现疑惑自己当初为什么这样写，这样写是为了什么。
13.保留当初开发时的需求，一定是要最新的。
14。涉及到计算逻辑，和甲方的测试人员对接的时候，确保自己的逻辑，确保单位换算，确保测试人员没有忽略什么条件。
15.和前端对接，如果是前端给数据找你接，那么一定要问清楚细节，并且自己修改数据试试效果。诸如传null和传empty是否有区别，前缀是否需要加"/"，某些地方的值是否上下不能一样，某些地方上下文的值是否又要一样，等等。今天真的是给我接吐血了，从来没想过数据这么难接。 又过了2个小时，想通了一半，发现还是自己太菜了。