回顾自己的技术成长之路，具体技术真心没有一样敢说精通，对于一个像我这样工作6、7年的人来说，实在有些难以启齿。
现在中国整个的技术环境看重的是技术深度，而我从一开始就认为应该先广度再深度，自然在同行中被认为是异类。我没记错的话，大神左耳朵耗子的观点就是深度优先。
为什么要广度优先，而不是深度优先。我有自己理由：
- 技术变化太快，当你还没有深挖到某一个框架的本质，这个框架就可能已经过时了，特别是JS框架
- 容易只见树木、不见森林：比如你花很多时间去研究如何分布式存储你业务应用中的文件，但是你可能不知道世界上还有AWS S3这样的东西
- 手里有把锤子，全世界都是钉子：精通写bash脚本的人，所有的运维工作都倾向于写bash来解决运维问题，不知道世界上还有Ansible这样方便的东西，也不知道有时候根本问题不在运维，而在开发
我说出这些理由，并不是说我们就不需要深入研究某个框架和技术，只是想说明我们的选择的优先级会决定，至少会影响我们的思维方式。
这几年，我开始输出一些体现我思维方式的文章，比如：
- 《耦合的本质》：http://showme.codes/2015-12-29/the-nature-of-coupling/
- 《关于自动化配置还有什么好说的呢？》http://showme.codes/2016-08-12/automation-configuration/
- 《也许，这样理解HTTPS更容易》http://showme.codes/2017-02-20/understand-https/
- 《Puppet，Chef，Ansible的共性》http://showme.codes/2016-01-02/the-nature-of-ansible-puppet-chef/（根据自己的一次分享整理）
- 《信息检索中，索引的本质》https://my.oschina.net/zjzhai/blog/464446
很少人发现这些文章的真正价值，因为看起来和他们的实际工作没有任何关系，这些文章不会告诉你怎么快速搭建好https环境，也不告诉你怎么用Ansible copy一个文件到所有的目标机器上。
在一次面试时一位老架构师两次问我：《耦合的本质》真的是你自己写的？显然他不相信写这篇文章的人30不到。确认之后，他说他不完全认同“耦合的本质是假设”，但是他欣赏这样的思维方式。
我头一回感觉到有人看懂这篇文章。
总的来说，这些文章体现出来思维方式是：
利用概念推导、还原事物的形成过程、找共性这3个手段来找到事物的本质，再从这个本质推导基于此事物的上层建筑。
比如我根据我们实际运维过程所要做的事情，推导出要实现自动化所要解决的问题，然后再通过“找共性”的方法，最终找到了这Puppet，Chef，Ansible 三款工具之间的共性。
但是有什么用呢？其实，找到共性后，当遇到第四种自动化运维工具Salt时，我们就很容易提问了：
- Salt如何与受控机器通信
- 如何组织机器的？
- 使用什么DSL来描述这些机器的配置
最后根据这些问题进行深入地学习，这样我们就可以从被动学习变成主动学习，有方法论的学习方式。甚至找到这些工具的知识边界。
然而这只是我的个人学习方式，不一定适用于所有人。也不代表我的学习方式就是好的。
我只想说明：深度优先和广度优先的选择会改变我们的思维方式。
按道理，使用这样的思维方式（有点像方法论），任何一门技术都可以做到精通，但是我目前就是没做到精通。
因为我排斥用脑袋记东西。我认为记不了的东西或者能不记的东西，它就不值得记忆。比如如何将字符串ip转成一个整型数字、Ansible里某个module的具体用法。
而现实中，我对比其他的运维人员，我发现我用Ansible用得已经非常好了，Ansible里的概念我基本已经理解透了。但是我仍然不敢说精通Ansible。我实在记不了unarchive这个module的所有参数。
所以，即将三十了，我仍然不敢说我精通任何一项技术。这成为我的困境。
这时，很多人就会说了，你应该考虑转管理了。
但是，我要问了：为什么要转管理呢？
不少人的回答：
因为你老了，你没有精力去学习更多的新语言、新框架了，你拼不过小鲜肉了。
这个观点里有，有两个假设：第一，到三十后，你学不会，或学得慢新语言、新框架是因为没有精力；第二，小鲜肉没有能力做管理；
第一点假设不成立，因为那只是借口——不想做的人，会找理由，想做的人，会找办法。第二点假设只是概率性问题，小鲜肉也可以做管理。
转不转管理，决定于你是否真的Ready好了，是否真的喜欢做管理。和你年龄没有任何关系。
说到底，写不写代码，做不做管理，都是个非常私人的问题。我们没必要那么在意别人怎么看。
最后，我深爱着写代码。这不会因为我目前或将来是否精通某项技术而改变。
236
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
