有些事儿，工程师可能今生仅此一次
郑昀 创建于2016/9/15 最后更新于2016/9/18
关键词：深度思考，碎片化阅读，做论文，深入研究，
早先在《技术高手如何炼成》一文中提到，我会问面试者，你日常如何构建自己的知识体系。有人会觉得你怎么就问出这么宏大的问题？知识体系，这是什么鬼？
面试时的交谈
工作之后你做过这样的事情吗？
面试是一个谁主张谁举证的过程，有时候需要面试者举出实例，自我证明。
而我认为问一些我们工作中遇到的难题和业务场景是在“欺负”面试者，所以我喜欢问开放型问题：
在你工作之后，你有没有像做毕业论文一样对某一个 Topic 做过深入研究？如果有，请举例，说得越详细越好。
为什么要问这个问题？
因为我和面试者之间经常会发生这样的对话：
我：平常看什么技术网站？
Ta：某某技术新闻站，某某博客网，某某微信公众号……
我：最近有什么觉得不错的文章，印象比较深，能给我讲讲吗？
Ta：……
我：#￥^&#讲个标题也行。
Ta：想不起来。
我（汗）：那你平常怎么学习的？你毕业之后通过哪些方式构建自己的知识体系，讲给我听听。
Ta：看书（经过追问发现最近几年其实没读完过几本书，甚至连书名都记不住几个）。看视频（网络教学视频）。看技术网站（多半停留在首页上……）。跟朋友聊天（QQ群，微信群，……，斗表情包，无比巨大的噪音）。
我：这样吧，你工作之后有没有针对工作中遇到的某一类问题，抽象出一个 Topic，有针对性地调研和做试验？
Ta：……有吧……
我：你说的这个事儿，其他公司是怎么解决的？
Ta：……
新员工的试炼
我会告诉面试者，你来了之后，除了做业务之外，还必须做一个技术预研课题，课题范围可大可小，你不仅仅要做试验，还要公开分享你的所思所得。
WHY？
因为微信里收藏10000+篇技术文章，
因为知乎里收藏10000+个答案，
因为云笔记里离线复制了10000+篇文章，
……
很快乐，但并没有什么卵用。
碎片化阅读是很舒服，但意义不大，看似每天收获满满，其实都成为过眼烟云。重复一下著名的学习金字塔留存率观点：我们读过的，知识留存率是10%。
我和面试者之间还经常会发生这样的对话：
我：这个思路/技术选型是谁提出来的？
Ta：技术经理/领导/项目经理……
我：有没有比较过其他实现思路？请讲一下各自的优缺点。
Ta：领导让这么干的，所以没比较过……
针对某一个课题，深入思考，多方调研，做试验证明，很多工程师可能今生仅此一次：他大学毕业时做毕业论文的那次…………
如果长期满足于东点点，西点点，今天可能是 Webpack、npm、Gulp，明天可能是 Spark、机器学习、流式计算，假设你过目不忘，知识的广度倒是有了，但缺乏深度，长此以往，可能彻底毁掉了深度思考的能力。
所以，我们要“训练”，强制性要求你从定义问题开始，训练自己主动搜索、主动链接、主动构建知识、主动试验、有始有终的能力。
定义问题
首先我们提出的问题，它必须是有重要意义、急需结果、目标是商用，但可能没有现成的、确定的解决方案，同时这个问题必须能够给整个团队创造学习机会，提供发展个人和组织技能的机会。
那么通过讲述我们看到了什么，想解决什么，通过你我不断的思考和讨论，直到你能清晰地抽象出一个明确具体的问题——这个时候，问题其实已经解决了一半。
举例。
我们的平台由数以百计的形形色色分布式服务构成，每一个请求一路走来，会经过多个业务系统并留下足迹，并产生对各种 Cache 或 DB 的访问。作为访问入口的 App 开发部门首当其冲会接到用户投诉，然而请求会被随机分配到集群的各个节点，所以找到对应的日志片段，理清调用关系，找到在哪里断的，成为一个令人生畏的工作。
如何解决？前提是先定义出一个好问题。
拿“分布式系统”、“集群”、“日志”、“排查”等等关键字，去搜索，去看各种顶级团队的博客，去看各种架构师演讲资料，终于把问题聚焦于“分布式跟踪（Distributed Tracing）”这个命题。
于是，问题被抽象为一个 Topic：
如何实现分布式跟踪：追踪每个请求的完整调用链路，收集调用链路上每个服务的调用参数和异常堆栈，统计每个服务的性能数据；可视化调用链，可视化服务质量。
主动构建知识
曾经看到过这么一句话：
只能不断地学习基础知识以及和这个技术（问题）关联的知识，就像 Wikipeida 一样，当你进入一个词条的时候，就会伴随一堆新词条，于是，当多年后，我看到 “知识广度是深度的副产品”这句话时，简直就是说到我的心里去了。
仍以上面的例子举例。
确定了分布式跟踪的大方向之后，我们可以收集整理出各个公司在这个 Topic 上的实践，Google的Dapper，淘宝的鹰眼，Twitter的ZipKin，京东商城的Hydra，eBay的Centralized Activity Logging (CAL)，大众点评网的CAT。
接下来我们还可以整理出它们的架构思路和优缺点，我们可以发现有的解决方案对工程侵入太重，给开发者造成了额外的负担，有的解决方案依赖于该公司特有的、闭源的技术体系。
主动做试验
怎么设计试验，通过什么数据，打算证明什么，这也是一种能力。
举例。
在实现实时数据大屏的时候，我们的一位工程师在 MySQL+Canal 后接入分布式消息队列时，试验了 Kafka 和 RocketMQ，目的是，第一求证能否确保严格的消息顺序，这是数据库变更订阅希望看到的，第二做一下压力测试，比较一下二者的性能。
有始有终
我这里说的有始有终，包含几个意思：
毕竟这是一个商业应用，是要上线的，前前后后都要考虑清楚。我们考虑哪些点？首要的就是监控报警。其次是线上数据如何迁移，线上应用如何接入。再次是性能。
公开分享你的所思所得，不仅做，还要写下来，还要说出来。你一定要输出你在这个问题上构建的知识结构，帮助自己，帮助大家，共同进步。
如是重复再重复，训练再训练，不妨试试看遵循 70-20-10 的学习法则：70%的学习时间放在针对现实生活和工作中遇到的任务、问题解决，20%的学习时间放在人与人之间正式的、非正式的反馈、辅导，10%的时间学习知识和信息（可能是碎片化的学习，也可能是读书）。
这样可能像把你装进一个沙袋里吊起来，从四面八方用狼牙棒打你，酣畅淋漓。
-EOF-
RT 王大神仙：你是开发，她是产品，你跟他PK了一天需求，她需求有了，你的代码呢？
