49技术干货那么多如何选.pdfVIP

2018/11/23 极客时间 | 程序员进阶攻略 讲堂 程序员进阶攻略 文章详情 49 | 技术干货那么多，如何选？ 2018-11-23 胡峰 49 | 技术干货那么多，如何选？ 朗读人：刘飞 12′49′′ | 5.87M 在我刚进入行业的早些年，也是互联网的早期，其实网上的信息都不算特别多，而技术干货类信 息更是少，所以就养成了一个习惯，遇到好的技术干货类文章就会收藏下来。这个习惯延续了多 年，后来某天我突然发现仅仅是微信收藏夹内保存的技术干货型文章就已经累积了半年之多，都 没时间去阅读和筛选。 收藏了如此多的干货，半年没读似乎也没缺了啥，那么还有必要读吗？2011 年时，我刚进入互 联网行业，那已是互联网时代的成熟期，移动互联网的孕育期，也肯定是信息爆炸的时代，但依 然是技术干货寥寥的时期。如今，却已是连技术干货也进入了爆炸期，那我们该如何挑选与应 对？ 循证与决策路径 为什么我们会去挑选和阅读技术干货文章？我想，循证大概是一个原始诉求，通过分析别人走过 的路径，来拨开自己技术道路探索上的迷雾。 /column/article/69394 1/6 2018/11/23 极客时间 | 程序员进阶攻略 循证方法，也是我早年刚接触 J2EE 开发时遇到的技术决策指导思想，记得J2EE Development w hout EJB一书的译序中有一段话，很好地阐释了 “循证” 方法： 任何一个从事 J2EE 应用开发的程序员或多或少都曾有过这样的感觉：这个世界充 斥着形形 的概念和 “大词”，如同一个幽深广袤的魔法森林般令人晕头转 向，不知道该追随这位导师还是该信奉那个门派。 这时，Rod Johnson 发出振聋发聩的一呼：尔等不必向泥胎偶像顶礼膜拜，圣灵 正在尔等自身 —— 这就是他在书中一直倡导的 “循证架构”。选择一种架构和 种技术的依据是什么？Rod Johnson 认为，应该是基于实践的证据、来自历史项 目或亲自试验的经验…… 所以，我们去阅读技术干货文章，想从别人的分享中获得对自己技术方案的一个印证。这就是一 种行业的实践证据，毕竟想通过听取分享去印证的，通常都是走过了一条与自己类似的道路。技 术道路的旅途中充满着迷雾与不确定性，我们不过是想在别人已走过的类似道路中获得指引和启 发，并得到迈出坚实下一步的信心。 这就是循证方式的技术决策路径。 多年前，我们刚开始做咚咚这个 IM 系统时，就是沿着这条路径一路过来的。 刚启动是 2012 年，一开始其实是完全不知道怎么迈步，专门花了三个月时间来研究业界的 IM 软件系统都是怎么做的。当时行业 IM 第一的当属 QQ，但那时腾讯公司的技术保持神秘而低 调，在互联网上几乎找不到任何公开的技术分享资料。 退而求其次，我们只好研究起开源的 IM 软件，也就是基于 XMPP 开放协议实现的一类开源 IM 服务端和客户端，并以此为基础去设计我们自己的 IM 架构，然后实现了一个最初的原型。 再后来，腾讯终于有一位即时通讯的 T4 专家出来分享了一篇关于 QQ 的 技术架构演进之 路，记得是叫《1.4 亿在线背后的故事 —— QQ IM 架构的演化与启示》。我仔细听了一 遍，又把分享材料翻过好多遍，思考并体会其中的架构演化道路。 数年后，微信在移动互联网时代崛起，并且在 IM 领域甚至还超越了 QQ，微信团队也分享了其 后端架构演进之路。此时，我们自身的架构也基本成型并运行一些年了。而我也注意到，关于 IM 类消息应用最核心的一个技术决策是：消息模型。微信的方式和我们并不一样。 微信的方式是基于消息版本的同步加存储转发机制，而我们则是基于用户终端状态的推送加缓存 机制。微信的机制从交互结构上更简洁和优雅一些，在端层面的实现复杂度要求更低，符合其重 后端、轻前端的设计思路和原则。 然而，循证的方式就是：即便你看到了一个更好的技术与架构方式，但也要结合自身的实际情况