①不熟悉的新类，在不了解之前不要随意使用
并发工具——CopyOnWriteArrayList，如果仅仅认为是ArrayList的线程安全版本，在不知晓原理之前将它用作大量写操作的场景，很可能会遇到性能问题
JDK或者各种框架随着时间的推移会推出各种特殊类，用于极致各种细化场景下的程序性能，在使用这些特殊类时，我们需要认清楚这些类的由来，以及这些类解决的问题，确认在自己场景符合的情况下去使用
越普适的工具类用起来越简单，越高级的类用起来越复杂，也更容易踩坑。比如代码加锁中锁工具类StampedLock就比ReenTrantLock或Synchronized用法复杂的多，很容易踩坑
②尽量使用更高层次的框架
偏底层的框架趋向于提供更多细节的配置，尽可能让使用者根据自己的需求来配置，而对最佳实践的问题较少去考虑；而更高层次的框架，则会更多的考虑如何方便开发者开箱即用
比如Apache HttpClient并发数限制的问题，如果使用Spring Cloud Feign搭配HttpClient，就不会遇到单域名默认两个并发连接数的问题，因为Spring Cloud Feign已经将这个参数设置为50了，足够应对一般场景了
③关注各种框架和组件的安全补丁和版本更新
比如我们使用的Tomcat服务器，序列化框架等，就是黑客关注的安全突破口。我们需要及时关注这些组件和框架的稳定大版本和补丁，并且及时更新升级，避免组件和框架本身的性能问题和安全问题带来的大坑
④尽量自己少造轮子，使用流行的框架
流行框架最大的好处就是成熟，在经过大量用户使用打磨之后，我们能想到、能遇到的问题几乎别人都遇到过，框架中也有解决方案。其实很多我们造轮子的初衷就是造出一款轻量级且满足条件的轮子，但是其实很多复杂的框架，一开始来说也是轻量的，只不过这类框架经过各种迭代之后解决了各种问题，做出很多可扩展性的预留才变得越来越复杂，并不一定是框架本身设计臃肿。
假如我们自己去开发框架，很可能踩到别人已经踩过的坑。比如说使用JDK NIO开发网络程序或者网络框架，我们可能遇到epoll的selector空轮询bug，最终导致CPU达到100%，但是使用netty开发NIO网络程序，可以规则这些坑，使用层面还更简单
⑤开发的时候遇到错误，除了搜索解决方案之外，更重要是理解原理
网络上给出的解决方案，可能只适合自己，不一定适合所有人，并且各种框架的迭代很频繁，今天有效的解决方案可能明天就失效了，今天有效的参数配置，新版本可能就不太建议使用甚至失效了，只有知其所以然，才能够从根本上避免踩坑
⑥多参考官方文档
网上各种资料，本来就是大家学习分享的经验和心得，不一定都是对的，这些资料中给出的小demo也不一定会面面俱到地考虑资源释放、并发的问题，不同需求背景都要不同的考虑
对于系统的学习某个组件和框架，还是参考官方文档，这些文档中一般会提到使用的最佳实践以及最需要注意的点
⑦做好单元测试和性能测试
单元测试，不管是在何种场景下，都是必须的，都是保证我们代码质量的必须流程，我们永远也不可能保证我写的代码不出错，即使逻辑万般简单
而像资源使用、线程安全这些问题只有在高并发的场景下才会产生。没有经过性能测试的代码，只能认为是完成了功能，还不能确保健壮性、可扩展性和可靠性
⑧做好代码评审和代码审查工作
人都会犯错，任何一个人的知识都有盲区。代码评审不仅仅是确保自己的盲区覆盖、更是在参加别人代码评审的时候，汲取别人代码优秀设计和警示自己不要重蹈覆辙的过程
比如对于熟悉IO的开发者来说，肯定知晓文件的读写需要基于缓冲区，如果他看到另一位同时提交的代码，是以单字节的方式来读写文件，就可以提前发现代码的性能问题
又比如，一些老资料仍然提倡使用MD5摘要来保存密码，但是现在MD5加密已经不安全了。如果在代码评审的时候经过公司内安全经验丰富的开发者和安全专家评审过，就可以提前避免安全漏洞
⑨借助工具避免踩坑
我们在犯很多低级错误的时候，可能并不是自己不知道，而是因为疏忽。比如使用YYYY进行日期格式化的坑、使用==进行判等的坑List.subList原list和子list相互影响的坑，都可以通过阿里规约插件扫描发现
此外在CI流程中对需要发布的代码在Sonarqube进行代码质量扫描，也是保证代码正确性的一大举措
日夜颠倒头发少 ，单纯好骗恋爱脑 ，会背九九乘法表 ，下雨只会往家跑 ，搭讪只会说你好 ---- 2050781802@qq.com
