1. SQL
2. 代码
3. 注释
4. bug与细节

SQL

1. 非后管系统尽量不要使用动态sql，当数据库或者前后端传递的参数没有绝对约束时，非分页查询的sql可能将给系统带来灾难级别的bug，或者更新语句一次更新了多条记录，这样做不好的地方就是需要多些一查询方法，代码量多一点
2. 在业务中尽量不要对某一条数据查询进行重复查询和更新操作，提升效率
3. 对sql中的语法，在效率问题上尽量了解后在使用
4. 禁止在递归中使用查询

 代码

1. 对简单的代码或者架构要合理使用抽象，避免过度抽象导致阅读和代码量花费的时间过多
2. 好的代码和架构是减少代码量的，配合文档减少开发者熟悉代码或者框架的时间，框架封装和发展的趋势是低代码和组件化
3. 必须使用面向对象的思想，在这里再次重申一下面向对象的思想。所有现实中的事物都可以看做一个对象，这个对象在java中就是类（抽象），类的成员变量即对应了事物的属性（抽象），类的成员方法对应的事物的行为（抽象）。可见抽象才是编程的核心思想，由抽象可以带来更多的编程思想与设计模式。

图灵奖-面向对象之父-阿伦·凯 之一 - wanderer - 博客园 (cnblogs.com)https://www.cnblogs.com/wanderer/articles/1648566.html事物是汽车（java类）；

汽车有属性（成员变量：颜色、品牌、 发动机型号）；

汽车有行为（成员方法：可前进、后退、驻车、左转、右转）；

在你调用这个类中的方法的时候，思考一下其他方法是否和你此次调用的方法是否是符合对象的行为，或者说对象的属性，而不是为了简化（解耦）而简化写的方法，尽量少些无意义的方法。

注释

1. 请提前确认好需求，不明确的需求开发是可以拒绝开发的，是程序员都会有这样的问题，在没有明确开发任务的时候先接下来，在实践中优化。我认为这样做其实没太大毛病，对于一般的中小型公司来说。但是开发者应该向往着明确且细节更清楚的需求去开发，并且确定好各自的岗位职责，需求清晰，明确了，则可以先写注释在写代码。注释不是利他行为，而是标志着一个程序员的水平和不断迈向进步的阶梯，工作是做给自己的，不是用来卖弄的，做好自己的事情，这样才能避免把其他人的事情做了，连自己的事情都做不好，那么你在领导眼中得不到重视，永远都只能做低级的事情并且同事一直做打杂的活（帮同事擦屁股），因为在领导的眼中你的水平只能配这个活。公司里面的技术大牛平时基本上都在摸鱼，甚至考勤对于他来说都是可有可无的东西，但是需要他的时候，他一定会站出来，技术的沉淀和工作的负责才是他们立足和得到重视的根本，所以他们才不会做别人的事情。

BUG与细节

根据墨菲定律---你越会害怕的事情越会发生

1. 测试的时候我们总觉得哪里会出问题，但是总想着先提交测试，按时完成再说。一旦我们有这样的心理出现，百分之百在测试的是会出问题，而且测试的时间会边长，会影响到开发人员的开发进度，在新功能和修改bug中反复横跳，最终自己偷懒还是自己受伤，所以自己多测几遍不要把明明知道有bug的需求给别人测试，如果功能没开发完，可以向领导要时间，如果你说开发完了可以提交测试了，那么往往等待开发者的是另一个新需求，这样才是保护自己的方法，让自己忙碌起来，并且是真的在忙碌。
2. 确保生产环境没有bug，谁也不想半夜三更去改bug，一分耕耘一分收获，平时偷懒，半夜起来拉会议改bug，哪个开发不想休息的时候痛痛快快的玩，所以工作的时候少写bug。