即将三十，我不敢说我精通任何一项技术

[超级奶爸]

图片来源：http://www.imdb.com/title/tt0395699/

回顾自己的技术成长之路，具体技术真心没有一样敢说精通，对于一个像我这样工作6、7年的人来说，实在有些难以启齿。

现在中国整个的技术环境看重的是技术深度，而我从一开始就认为应该先广度再深度，自然在同行中被认为是异类。我没记错的话，大神左耳朵耗子的观点就是深度优先。

为什么要广度优先，而不是深度优先。我有自己理由：

• 技术变化太快，当你还没有深挖到某一个框架的本质，这个框架就可能已经过时了，特别是JS框架；
• 容易只见树木、不见森林：比如你花很多时间去研究如何分布式存储你业务应用中的文件，但是你可能不知道世界上还有AWS S3这样的东西；
• 手里有把锤子，全世界都是钉子：精通写bash脚本的人，所有的运维工作都倾向于写bash来解决运维问题，不知道世界上还有Ansible这样方便的东西，也不知道有时候根本问题不在运维，而在开发。

我说出这些理由，并不是说我们就不需要深入研究某个框架和技术，只是想说明我们的选择的优先级会决定，至少会影响我们的思维方式。

这几年，我开始输出一些体现我思维方式的文章，比如：

• 《耦合的本质》
• 《关于自动化配置还有什么好说的呢？》
• 《也许，这样理解HTTPS更容易》
• 《Puppet，Chef，Ansible的共性》 （根据自己的一次分享整理）
• 《信息检索中，索引的本质》

很少人发现这些文章的真正价值，因为看起来和他们的实际工作没有任何关系，这些文章不会告诉你怎么快速搭建好https环境，也不告诉你怎么用Ansible copy一个文件到所有的目标机器上。

在一次面试时一位老架构师两次问我：《耦合的本质》真的是你自己写的？显然他不相信写这篇文章的人30不到。确认之后，他说他不完全认同“耦合的本质是假设”，但是他欣赏这样的思维方式。

我头一回感觉到有人看懂这篇文章。

总的来说，这些文章体现出来思维方式是：

• 利用概念推导、还原事物的形成过程、找共性这3个手段来找到事物的本质，再从这个本质推导基于此事物的上层建筑。

比如我根据我们实际运维过程所要做的事情，推导出要实现自动化所要解决的问题，然后再通过“找共性”的方法，最终找到了这Puppet，Chef，Ansible 三款工具之间的共性。

但是有什么用呢？其实，找到共性后，当遇到第四种自动化运维工具Salt时，我们就很容易提问了：

1. Salt如何与受控机器通信
2. 如何组织机器的？
3. 使用什么DSL来描述这些机器的配置

最后根据这些问题进行深入地学习，这样我们就可以从被动学习变成主动学习，有方法论的学习方式。甚至找到这些工具的知识边界。

然而这只是我的个人学习方式，不一定适用于所有人。也不代表我的学习方式就是好的。

我只想说明：深度优先和广度优先的选择会改变我们的思维方式。

按道理，使用这样的思维方式（有点像方法论），任何一门技术都可以做到精通，但是我目前就是没做到精通。

因为我排斥用脑袋记东西。我认为记不了的东西或者能不记的东西，它就不值得记忆。比如如何将字符串ip转成一个整型数字、Ansible里某个module的具体用法。

而现实中，我对比其他的运维人员，我发现我用Ansible用得已经非常好了，Ansible里的概念我基本已经理解透了。但是我仍然不敢说精通Ansible。我实在记不了unarchive这个module的所有参数。

所以，即将三十了，我仍然不敢说我精通任何一项技术。这成为我的困境。

这时，很多人就会说了，你应该考虑转管理了。

但是，我要问了：为什么要转管理呢？

不少人的回答：

• 因为你老了，你没有精力去学习更多的新语言、新框架了，你拼不过小鲜肉了。

这个观点里有，有两个假设：第一，到三十后，你学不会，或学得慢新语言、新框架是因为没有精力；第二，小鲜肉没有能力做管理；

第一点假设不成立，因为那只是借口——不想做的人，会找理由，想做的人，会找办法。第二点假设只是概率性问题，小鲜肉也可以做管理。

转不转管理，决定于你是否真的Ready好了，是否真的喜欢做管理。和你年龄没有任何关系。

说到底，写不写代码，做不做管理，都是个非常私人的问题。我们没必要那么在意别人怎么看。

最后，我深爱着写代码。这不会因为我目前或将来是否精通某项技术而改变。