看起来毫无意义的一个问题，碰到线上异常/故障如何面对，排查解决了不就好了，但是这真的只是第一层。
最近在想“消防”这个词语很有意思，它其实是两层意思：
即“消防”这个词语表达的意思应该是
先消除问题再防止相同的问题再次发生
。
其实线上的异常/故障也是同样的道理，我们应当先及时止血，把问题处理掉，
然后深挖问题，探究根因，举几个例子：
-
假设是某段代码的空指针异常导致的，那么是否考虑加强 Code Review，或者使用 findbugs 插件去自动扫描代码中可能的异常？
-
假设是线上某个配置修改导致的，那么是否今后变更的修改必须有人双重检查一遍才可以修改？
-
假设是本地内存中某些值因为系统重启丢失导致的，那么是否引入定时任务，定时把值写入本地内存中？
-
假设是某段代码逻辑没测试到导致的，那么是否可以反思总结为什么这段逻辑没有测试到，未来的测试应该如何改进？
根据我过往的经验，太多公司、太多团队处理线上的问题
仅仅满足于把问题处理完就完事，忽略了对问题的复盘
，这对团队/对公司的发展都是不利的。
之前加了几个技术微信群，看到很多技术朋友在兴高采烈地讨论各种源码， spring 源码我彻底撸了一遍、最近深入学习了 dubbo 底层实现方式，当然曾经的我也是这样的，记得学习 volatile 的时候一直挖到了 volatile 在硬件层面上的实现方式，但是这真的说明技术能力强吗？
从今天的思考去看这个问题，我认为这更多反应的是
一个人的学习能力、钻研能力以及对技术的热情
，除此之外再体现不出太多其他东西了。
这个话题，可能是这一年思考的最多个的一个点，钻研是好事，但是实际上大多时候的深入钻研并不在实际工作中有用，且研究得越深，忘得越快，因为研究得越深，那么这个技术点关联的技术点就越多，边边角角的忘了，核心的东西不容易串起来。那么什么是真正的技术能力，我画一张图概括一下：
简而言之，技术能力 = 解决问题的能力，那么同样都在解决问题，大家之间的技术高低又有什么区分呢？我认为有以下几个层次：
其实从这个角度上来看，不同的技术能力，在工作过程中区分度是很明显的：
-
写的代码是否存在异常风险，多线程运行下是否存在线程安全问题，某段代码是否会导致内存泄露
-
写的代码是否优雅可复用，设计的框架是否足够符合开闭原则，代码结构层次是否清晰明了
-
针对特定的场景，技术选型、库表结构设计是否足够合理，今天你设计的框架是只能用一年，还是未来三年五年都可以持续使用
-
来了一个大的需求，就比如做一个 App 的会员体系功能好了，是否可以在充分分析需求后，精确将需求划分为几个特定的子模块并梳理清楚模块之间的关系
越厉害的人，在代码设计与开发过程中，越能看到想到一些别人看不到想不到的问题，这叫做
高屋建瓴
；当代码运行出现问题的时候，有人 1 小时排查出问题，有人1分钟发现问题，这叫做
举重若轻
。
因此我认为解决问题的能力才是技术能力的真正体现，这一年对技术的探究我也从研究源码更多的转变去学习设计模式、去学习分布式环境下各种 NoSql 的选型对比、去学习使用 Lambda 让代码更简洁，往真正在实际工作中解决问题的方向去努力。
另外，抛开这个点，这两天我在思考，还有一个体现技术能力的点，就是学习能力。现实中的全栈是很少的，互联网这个行业的程序员的方向通常有几类：
在同一类中，基础知识、基本概念、思维方向是一致的，更多可能差异在开发工具、语言上
，我精通 Java，但是如果明天有一个需求，使用 nodejs、scala、go 更好，那么是否可以快速学习、快速上手？甚至明天有一个需求需要写前端代码，是否可以快速开发、无 bug 上线？
所以，解决问题的能力 + 学习能力，是我认为真正的技术能力，不过说到底，学习能力某种程度上也只是为了解决问题而已。
曾几何时，当我们看着 GitHub 上这么多优秀的源代码的时候，默默立誓，这辈子我一定要写出一个牛逼的框架，开源在网上。
曾几何时，公司招聘的时候，技术负责人激情满满地介绍着公司内部自研了多少系统并在线上投入使用。
很多对技术有追求的朋友，进入一家公司可能时时刻刻在寻找机会去做一些自己造轮子的事情，但是就如同前面所说的，
衡量真正好技术的标准就是能否实实在在地解决问题，自己造轮子风险高、周期长
，且需要长时间的验证、排坑才能达到比较好的效果。
随便举几个例子，在互联网发展的今天：
只要你有的技术方面的需求，绝大多数业界已经有了成熟的解决方案了，根本不需要去专门自己搞一套。因此我认为轻易一定不要造轮子，如果一定要造轮子，那么请想清楚下面几个问题：
如果想清楚了这些问题，那么就去干吧。
过去有太多人在我的公众号或者博客下反馈了一个问题：在这个公司，整天做着增删改查的工作，对自己一点都没有提高。
对于这种看法，说难听点就是四个字 —— 目光短浅。我们看：
如果以普通的视角去看，那么一颗树那也就只是一棵树而已，但是如果跳脱出目前的视角，站在更高的角度去看，它其实是森林的一部分。你的主管并不是因为他是你的主管所以他就应该你比更高瞻远瞩，而是
因为他看问题的高度比你更高、想得更远、做得更深，所以才成为了你的主管。
把这个问题说得实际点：
今天与其在抱怨没有机会、抱怨公司对自己能力没有提升，为什么不去思考机会为什么降临在别人头上不降临在你头上？为什么别人可以从小公司写着一样的增删改查走向 BAT 而你年复一年还在小公司写着增删改查？
