- 任何局部优化都是在浪费生命
不要仅凭感觉去做性能和代码优化或者是重构代码，一定要以性能测试和监控分析结果为依据，重点优化和改进关键代码和影响常用功能的代码。
需要认识到和牢记的是，局部的小改进对业务整体而言是毫无意义的，只有从全局角度所做的改进才是可感知且有价值的。
不要原地打转：开发工作不要阻塞在单一技术点上，以完成业务功能为首要目标，不影响整体架构的技术难点可利用空闲时间解决
出现任何问题都始终保持就事论事的态度，不要带有个人情绪，不要在未查明根本原因的情况下将问题归咎于个人能力、品行或态度，应优先考虑提升项目管理、工作分配、人员激励、运维管理等制度和服务
如果不知道或不确定如何处理异常，那就让它抛出，甚至是让程序崩溃，从而让问题尽早出现并提前修复掉。
将异常“吃掉”是不负责任的，至少也应该打印到异常日志中（日志级别为
ERROR），这样才有利于及时定位根源。为避免单例程序崩溃导致服务不可用，可同时部署多个实例，提供冗余服务机制，这样就可以不用想各种方法来避免程序崩溃了，有了服务冗余，就让它崩溃吧。
PS：确保崩溃的服务能够快速重启也是很重要的。
无论是开发最终应用，还是基础框架，切忌，不要向使用者（普通用户或开发人员）暴露底层细节，更不要向使用者强制灌输细节内容。确保使用者可安心地、无干扰地关注业务功能的开发和使用
尽可能避免让他人在解决与其业务不相关的问题上耗费不必要的时间，进而减少社会总体时间成本
- 命名清晰且与业务意义相关，太过随意的名称或简写对阅读和理解代码将造成极大阻碍，会提高他人以及未来的自己的时间成本
- 通过博客等向外界阐述、解释、提供案例/代码等，务必做到简洁、清晰、流畅、准确，不要让他人再耗费比自己更长的时间来理解文章内容、判断准确性等，应力求将读者的时间成本降至最低
确保IDE具有自动版本控制功能，保证误删除代码可准确恢复
不要纠结于文档或代码格式等细节问题，首先关注其内容，格式问题需逐步引导并规范
提供完整、详细、准确的注释，并说明接口的使用方式、适用场景、注意事项等开发者需注意和其真正所关注的内容
尽可能优先编写测试用例，并在业务逻辑修改后先跑测试用例，再检查业务功能
数据库字段名、字段别名、表别名以“_”结尾，以避免和数据库关键字冲突。同时，表名和字段名采用小写字母且字母间以下划线分隔，以提高可读性并减少编码时的按键次数
时间、日期以长整形进行前后端交互，避免格式化方式不同而造成的性能消耗和解析复杂
在后端统一拦截异常，并在前端针对
500错误做统一显示尽可能避免多应用、多线程共享数据或变量，应用之间操作数据需调用提供方的接口，严禁直接操作对方的数据
服务端API应支持模型的局部更新，即客户端仅向服务端发送需变更的字段及数据，未发送的字段不做变更
若SQL查询中需要限定包含二进制或文本列的数据行唯一性时，先通过子查询限定id的唯一性，再查出id在该子查询结果内的数据行
- Oracle中不支持
Clob/Blob等字段的distinct约束
- Oracle中不支持
避免在
if/else中包含过长代码，可将其提取为独立接口，或者，通过return提前返回，以使分支逻辑更加清晰在操作大量数据（以万及以上为单位）时，需尽可能避免使用递归，循环的效率比递归更高
避免使用Hibernate的级联更新，而应使用单独接口处理级联数据
尽可能为过程数据、临时数据、文件解析等创建对应的模型对象（Class），避免以Map等记录中间数据，从而保证代码的可读性，同时也有利于代码的自动化检查和处理
避免使用字符串字面量（Literal），应积极使用枚举类型来代表各类常量
将业务数据、消息数据、分析数据、日志数据等独立存储，并使用更合适的数据库或技术堆栈存储和查询
不要排斥
switch/case，在很多情况下，其比if/else更优雅
