最好的技术就是你现在做的技术

有读者今天问了我一个问题，觉得研究的技术在工作中都用不上，工作上主要都是写些 if else，跟那些高并发、分布式都不沾边，这种情况应该怎么办？

我想到了我早先刚参加工作没多久，那时候还在外包公司，在江苏某家银行驻场干活，做的项目就是用 ECharts 报表 + 几个前端页面写可视化大盘，前端用的是jQuery，后端还用的 Servlet，没用Spring，部署也没有什么 Jenkins 这种打包部署，直接Eclipse 编译成 war 包，丢到 Tomcat 的web目录，而且那时候还是单机部署，连主备都没用，因为就是可视化，从数据库查查数据，然后展示在页面上，前端写个每隔5 秒定时刷新，跟核心系统毫无关系。

当时我记得遇到的最大的技术挑战还是自己作死，不用成熟的框架，自己手写了个数据库线程池，发布之后运行一段时间就报数据库连接不够了，开始排查，那时候技术还是很青涩的，解决问题的办法就是百度，然后各种尝试，看代码数据库连接也都释放了，修改了之后重新发布，然后运行一段时间之后还是报连接数不够，最后费了很大劲，后来具体怎么解决的已经忘了，但是这个问题让我开始决心好好研究当时用的DB2数据库。

我就开始深入了解DB2 的原理，在网上找DB2 相关原理的资料看，我后来又自己写了一些跟DB2 打交道的代码, 自己有了一些常用的DB2 的工具包，非常简陋的需求，加上非常简陋的系统，但是还是有问题值得深入了解背后的技术原理。

讲这段经历的意思其实是想回答读者说的这个问题，很多人都喜欢研究一些看似高大上的技术，但是对自己日常工作相关的技术反倒理解还非常肤浅，比如我问过候选人几个问题：现在应用使用的容器的启动原理吗，现在系统模块为什么这么设计，有没有需要改进的地方？了解你系统单测使用的框架mock实现机制吗，日常遇到的一些项目上的问题，都是什么原因引起的？

我现在面试候选人，不太会对分布式高并发张口就来的有所青睐，喜欢安安静静的看候选人写写代码，一道中等难度的场景题，看逻辑是不是清晰，边界条件、异常case 是否都能考虑到，是不是在意细节处理，遇到问题会不会想要了解引发问题的根本原因。

原因也很简单，实际上在大厂做技术，尤其是我们业务技术，大部分的场景和业务问题都有很成熟的解决方案，比如大促高并发的一整套方案已经非常成熟了，大部分中间件也是自研的，有问题找对应的开发同学。

复杂的往往是业务场景和链路，现在都是微服务，你一个系统可能被几十个系统调用，接口出入参要考虑以后的升级维护，日常的技术方案要考虑逻辑的合理性，方案未来的可扩展性，所有可能出现的情况，边界条件、异常case 是否都能考虑到，这其实不是一件容易的事情，需要认真对待日常需求的一个个技术方案，是从一次次代码编码，重构优化、解决一个个问题，解决再优化的实践中总结出来的。

所以重视你手上的工作吧，从日常工作中学习技术，延伸技术。