程序员需要关注的四大技术趋势

现在是一个技术发展非常快的时代，对于技术人而言，面对层出不穷的新技术，怎么跟上节奏？怎样去学习？很多人对此可能无所适从。不光是个人，公司和组织也是如此，如何让组织跟上技术最新发展，保证组织竞争力？这是在这个第四次工业革命时代每个组织都在面对的挑战。

所以今天跟大家分享的是通过技术雷达捕捉到的技术世界的重要趋势。我2016年 6月 2号在深圳有一个技术雷达峰会，会更深入地解析最新技术趋势，分享我们的洞见和观点，大家有兴趣可以关注。

技术雷达

ThoughtWorks技术雷达大家可能有所了解，每年会发布两期，也有一个在线网站。雷达的内容是对当前技术发展的快照，覆盖了技术、平台、语言框架和工具。雷达的输入都是来自于我们一线技术人员的观察和实践。

坦白讲，这类技术趋势分析的报告在业界有不少，比较著名的有 GitHub和 Stackoverflow的年终的总结、Gartner的 Hypecycle等。但这类传统的报告要么是对历史数据的总结回顾，可能没有办法预测未来的趋势，而且要么来自远离实际技术工作的分析师和观察家，对一线技术人员来说有些遥远。

相比而言，我们更加相信优秀的一线技术人员通过实际工作中获得的经验和判断。我们做技术雷达的时候很重要的输入是前线技术人的声音，了解技术在真实的世界中是如何被采用。

四个技术趋势

Browser Bulks Up, Server Slims Down(浏览器增强，服务器式微)

第一个主题趋势叫做 Browser Bulks Up, Server Slims Down，我们发现很多的开发工作的复杂度会转移到浏览器端，而后端的复杂度在逐渐降低或者说得到控制。这个趋势已经持续了一些年。

曾经服务器端为王的时代，大部分时间我们希望把业务逻辑放到服务器端上，给前端留一些轻量的页面布局和表单验证工作。技术雷达从 10年提出将 Java作为一等公民语言，并在 13、14年的主题趋势强调了 Java生态的爆发。人们开始越来越多的意识到 Java也可以做主力语言 (Atwood Law)。你会看见在前端社区生态涌现了了非常多的工具。如今国内的一些互联网公司有着非常大的前端团队，并且出现了前端架构师这样的职位去管理前端的复杂度，这在以前是不可想象的。前端相关的工具也开始从最早的简单的 ajax类库，到 MVC/MVVM框架到现在的组件化趋势，甚至发展出很多的细分方向，比如像 Redux、Flux这样专门做 statement的库。

一方面前端的复杂度在增加，另外一方面后端的复杂度也在减少。过去很多人会以自己是后端程序员为豪，因为后端需要涉及到服务器端开发方方面面知识，但是这几年随着容器技术以及 PaaS相关技术的崛起，你会发现像认证授权、负载均衡、注册发现等越来越多的 cross concernerd的逻辑，包括把我的软件部署到不同环境中的工作，都已经被 PaaS平台本身接管了。

据我所知，很多公司正在建立一体化的数字化交付平台。这样的平台让代码从迁入到部署到生产环境变成完全一个自动化的过程，并且提供开箱即用的监控和运维支持。这个领域在自动化之上我们还看到了 AIOps和 ChaosEngineering等趋势。在有着一套非常完备平台的组织里面做后端应用程序开发，用微服务的架构方式写应用。你会发现你面对的都是一些 big clean的业务逻辑，以 API的方式呈现出来，输入输出都非常清晰明确。后端反而变成了一个相对比较简单的工作。

有人可能会问 Browser Bulks Up, Server Slims Down这个趋势已经持续很久了，这个趋势还会持续下去吗？我个人看来，至少在未来的六到十八个月，这个趋势仍然会继续。

因为现在人们对客户端的用户体验有更多要求，现在浏览器也发展出来了很多 Native API，可以充分利用设备的能力，包括 mobile device的一些 sensor。再如比如这期技术雷达观察到随着 WebAssembly的引入可以进一步释放浏览器的潜力。

因此我认为在可见的六到十八个月内这个趋势仍然会继续。客户会持续要求更好的用户体验，产品的多设备、多平台战略会持续发展；而在后端开发上，你的数字化平台的自动化和 Devops能力在持续完善和优化，后端开发会投入更多精力在业务功能本身。

Creeping Cloud Complexity

另外一个比较有意思的趋势，我们叫做 Creeping Cloud Complexity，意思是云的复杂度会增加。其实很久以来，当我们说到云，可能只把它当成一个 IaaS，但随着虚拟化技术崛起，以及容器化技术的崛起，我们逐渐觉得云的作用不仅仅是把软件搬到企业的机房之外，它更多的能够实现云当初给我们的一些承诺，它可以做到弹性伸缩，按需使用，自助式服务。然而在使用云的过程中，尽管会有像 Docker这样的技术帮我们去 handle云的复杂度，我们也看到，随着很多企业采用云，云也遇到了一些挑战和问题。

我们观测到的一个趋势是：很多的企业采用云的时候会选择 Polly Cloud，即混合云的一个策略。Polly Cloud跟 Hybrid Cloud是有区别的，Hybrid Cloud是指公有云跟私有云相结合，但 Polly Cloud是指你去选用一个公有云的时候，你会去考虑不同的公有云在特定领域的差异化能力。

AWS、微软的 Azure、Google的 GCE、国内的阿里云，不同平台的通用能力是非常类似的，这个时候平台会去强调自己一些特有的能力，比如说 Google的 GCE会强调他们的 GKE服务来帮你托管你的 k8s，如果你想要，或者你已经在这个项目里使用了 k8s，你可以很轻松迁移到 Google的 paltform上。另外像微软可能跟以太坊等 Blockchain技术合作，建立起来一系列的 Blockchain as Service服务。你会发现不同的云，其实在一些通用的能力之外，都在试图建立自己差异化的优点。

面对这种情况，一些企业采用多供应商策略，一方面不想被某种云绑定，另一方面也出于对某种特殊能力的需求。这个时候云的复杂度是在上升的，因为你不光是要去了解使用平台本身，你还要能够去合理地管理不同的云平台，我们技术雷达也推荐了相关的一些条目，讲怎样管理多个云平台。

Trust but Verify和 things Evolve

我们接着讲两个话题，一个话题叫做 Trust but Verify；一个是叫做 things Evolve。

Trust but Verify是苏联的一个谚语，意思是相信但是要验证。最初是用在美苏争霸核威慑的语境下，这里指的是企业的信息安全策略。很多企业的安全策略会把世界当成非黑即白，觉得在我的企业的网络外部，我不做任何信任，但是在我的企业网络的内部就是绝对安全的，不做任何的检查。而 Trust but Verify就是说信任、但总是要验证。

比如 Google前段时间提出 BeyondCorp，推行一个叫做 Zero Trust的实践，员工在上网的时候，我可以不用在办公室，从一个未受信任的网络能够正常访问我的工作环境。这就意味着，这个用户可以访问哪些内容，有什么样的权限，并不由他所进入的网络决定。而不像传统的 IT安全策略，不信任域外的任何东西。

第二个事情是说，任何一个进入网络的用户，他都需要经过非常严格的身份跟授权认证，就是说我虽然 Trust，我并不会区分你的网络在哪里，但是我一定会去 Verify你的身份和权限。这跟传统 IT安全策略的不同是，传统策略在域内几乎不会做任何验证，可以为所欲为。我们建议 Trust but Verify，而不是基于非黑即白的域环境隔离来建立你的安全策略。

还有一个主题比较有意思，叫做 Things Evolve，我姑且翻译成万物演进，此处的 things是 IOT（Internet of things）里面 things。

我们发现 IOT相关的一些生态和实践正在变得更加成熟，比如我们最近发现一些 IOT平台，以前你可能会选择自己去做 IOT，因为 IOT除了设备本身，更多的需要一个中央的平台去管理这些设备，你需要去收集设备的信息，你需要去下发指令，你需要去做监控，今天你可以很好地利用阿里云的 IOT平台、AWS的 IOT平台，你会发现云平台提供的 IOT的能力足够管理你的设备，你只需在设备上装一个非常简单的 SDK。

今天你如果再想做一个智能家居，是一件非常容易的事情，另外随着硬件的发展，今天你可以看到非常多智能硬件。在今年年初的一个 hackathon上，我们就用 IoT加 blockchain做了一个去中心化智能锁。锁是一个非常好的隐喻，它象征着对物理世界的所有权的访问控制。而通过 Blockchain，你在一个数字世界里可以对你财产的所有权进行声明和控制。

Block chain跟一个物理的锁结合，你可以给这个锁创建一个钱包，跟这个锁进行绑定，当你向这个锁支付一些以太币的时候，在这个锁上会跑一个智能合约，你可以把这个锁打开，获得这个锁一段时间的使用权限。这个有点像有很多自动储物柜，只不过你把这个锁跟这个 Blockchain的 smart contract连到一块的时候有非常多的可能性，你把锁放到房间里，就是一个去中心化共享租房，你把锁放到一个自行车，它就是一个去中心化共享单车，很有意思。

今天的 IOT的一些 Device、设备、工具链，包括它的一些平台发展的非常成熟，即使对硬件开发完全没有经验的技术人员，也能够通过一些 IoT设备的 SDK和平台，非常容易的 DIY一些你想做的应用。

微服务、AI和 Blockchain

最后讲几个大家比较关心的热点话题：微服务、AI和 Blockchain。这几个技术目前热度非常高，但这次没有进入我们的技术雷达，我会讲一下没有进入的原因。

微服务很火，但我们对微服务的采用一直持比较谨慎的态度，记得 16年左右，我们提出了一个条目叫做微服务的羡慕忌妒恨，意思是说，可能很多的项目和组织并不适合用微服务，微服务并不是银蛋。

我在咨询工作中看到有些项目，采用微服务的力度并不够，可能拆分力度过细，或者虽然拆成了微服务，但是并没有从合理的微服务划分中获得足够多的好处，它只是看起来变成了一个个的服务，但是它的数据库有可能耦合在一起，以前你可能在一个系统里面写完代码，发布上线就可以了，现在你每次业务变更都需要改好多个服务，而且在服务之间你需要去处理容错。

这就需要回到本质，微服务是一个架构风格，你还得为自己的架构决策负责，要根据自己的实际情况去检测考虑，这不光是一个技术和工具的问题，因为技术跟工具已经不是门槛了，更多的是我们人对业务的理解，以及设计问题。

我们再去讲一下 AI和 Blockchain，目前人工智能和区块链的话题很热，但也没有列入本期的技术雷达主题趋势里。其实我们在之前几期雷达趋势里做出对 AI和 Blockchain相关的主题趋势判断后，市场上很快迎来了爆发。但在目前非常大的喧嚣声下，我们并没有看到预期中那么多真正产生价值的应用。我们认为对 AI和 Blockchain的投入不应只炒热点，更应该是长期的对未来的投入。

关于技术雷达峰会

在即将举办的技术雷达峰会中，我们也将结合本期雷达内容进行多角度的分享，届时微服务概念提出者 James Lewis、微软（中国）CTO黎江、灵雀云 CTO陈恺以及 ThoughtWorks众多技术决策者都将参与其中，与大家共同分享技术选型中的经验与实践。其实做为一个开发者，有一个学习的氛围跟一个交流圈子特别重要这里我要推荐c++交流群648，778，840，不管你是小白还是大牛欢迎入住，大家一起交流成长。

学习思路：

学习资料：