1.获取数据的时候一定不要对数据进行额外操作，获取数据和操作数据一定要分开来，即使是显得有些复杂，也要分开。
2.数据类型一定要对应，例如：如果一个数据取出来既可以是BigDecimal也可以用String存储，那么就要判断它原本是用来存储什么的。如果一开始它的本质就是用来存储金钱或者数字这类的数据，那么一定要用BigDecimal存放进实体类中，而不要用String。因为它原本存取的是数据，那么就很有可能会在之后的业务中涉及到加减乘除，如果在这里就用了String存储，那么后面会不可避免的在String和BigDecimal之间频繁转换。大坑，已趟过。1和2说的都是同一件事。
3.在写判断的时候，一定要把拥有一票否决权的if写在最外面，避免后期进入多个if还需要进行同一个if的判断的情况。
4.写循环的时候，如果一个数据是大部分条件情况要用到，并且也不是只能在循环中获取到的数据，一律写在循环外。
5.如果分析业务的时候，有些情况没有弄清楚，那么就一定要给自己留后路，如果是可能写错方向的代码，自己加一个方便搜索的注释，方便后期真的需要修改的情况。注：不要在这里闲麻烦，因为后期如果真的要改，但是你此时不写清楚要改什么位置，那么到时候耗费的时间比现在多好几倍的，而且更麻烦，因为那个时候离这段代码写下去的时间已经相隔挺久了。
6.注释一定要写好。已躺。因为我自己的代码我一般都十分清楚到底写的是什么，所以碰到比较麻烦才能描述清楚的东西，我一般都不写注释，结果由于当时方法命名有歧义，时间比较紧迫，导致后期要修改方法的时候，我自己的搞不清楚该怎么改。因为方法里面到处都是截取字符串，我都不知道这个方法参数传过来的具体是什么个样子的，再要改方法，我只能慢慢debug去看参数传到该方法中是个什么样子，当初要是给方法写好注释，写个例子给方法参数做注释，能节省不少时间。
7.当发现业务可能有多种情况的时候，也就是业务没搞清楚， 那么一定要给自己留后路。例如：取值是数字，但这个是枚举的value，单同时下载txt和excel，之前就有个说明说金额的显示要求不同，那么此时到底是用枚举的value还是用枚举的key？两个都用Map存起来。
如果和对方讨论具体问题要消耗的时间太多，那么就想好退路，如果是自己想的另一种情况，代码应该是怎么个样子的，和现在这种情况有没有共同点，到时候真的是那种情况，代码好不好改？如果感觉没什么大问题，那么就可以把询问先忽略，因为交流的成本有时候真的是太高了。实在是走错路的情况下不好修改代码，那么一定要问清楚对方的需求，为什么呢？看第8点。
8.工作的任务和学习的作业最大的一个区别。客户要求你怎么做，你就必须注意任何细节的东西，不能说做个差不多相似度80%左右就可以，一定要98%以上。而自己的作业，只要功能实现没问题就可以了，代表自己会了。工作必须按时交差，不然就等着被开，而作业就比较轻松。