技术的执念

知识漩涡

只需稍加留意,我们就会发现自己被各种技术、工具包围。ThoughtWorks的技术雷达差不多每半年就会更新一次,在项目中更会遇到很多已经从技术雷达上消失的技术,项目上的旧技术/旧框架还在服役,新的技术/工具/语言/框架又在迅速的出现,有些昙花一现、迅速被新的后来者所取代。有的留下来了,不过也都在不断的演化、改变(不兼容的API,不同的版本等随处可见)。

如果你不幸是一个前端工程师,那么这个更新速度还要更加迅速。三年前Backbone是主流,两年前是Angular.JS,去年是React,紧接着Flux、Reflux等作为React的扩展而成为了新的主流;Grunt流行过一段时间,很快被Gulp替代,而新的Webpack又依稀有大一统的趋势。几乎每周都能看到新的框架涌现,双向绑定、虚拟DOM、事件代理、同构、后端渲染、更友好的语法糖、更快的执行速度等等,几乎任何一个方向都有无穷无尽的变化。

1-technology

而后端也好不到哪里去,容器技术、Web框架、ORM、构建脚本、自动化测试工具、依赖管理、应用服务器等等,你总有很多的选项,却又无法在事先区分到底哪个技术/工具更靠谱、更适合项目。

置身其中,往往有眼花缭乱、应接不暇的感觉。知识工作者当然需要终身不断的学习,但是像目前这种节奏,我很怀疑这是否是一种健康的状态。周围经常有人抱怨,好不容易上手了一个前端的MVC框架,一看周围的项目,大家已经在spike另外的框架/工具了(这意味着你在项目上无法使用该框架了……)。仅仅从学习的速度上来讲,我们已经远远无法跟上科技演化的节奏了,这是人类自身的一种限制。

知识的陷阱

假设你在一个Ruby项目上,学习了Rails/ActiveRecord/RSpec/MySQL。如果下一个项目还是Ruby,同样的技术站,你会觉得这是一种重复,因为除了业务逻辑、业务对象变化了之外,并没有新的内容,还是同样的技术。如果下一个项目是Python,技术栈变成了Django/nose/PostgreSQL,你可能会觉得有所提升,因为学到了不同的技术、框架、共建工具、测试工具等等,其实仔细观察,这还是一种重复,古人云:“换汤不换药”者,是也。

在目前我们所处的时代,信息以远远超过人们能接受的速度不断的被创造出来,一方面信息传播的速度大大提升了,另一方面是信息传播的渠道也极具多样化。我们无时无刻不被过载的信息包围着,即使你不主动的去尝试获取新的信息,手机App里的微信、微博、Flipboard、Pocket、知乎、开发者头条、Feedly、果壳、丁香园等等的推送已经足以提供给你足够的信息(大部分甚至都来不及消费就变成了历史信息而被忽略)。

以我自己为例,从2015年10月到2016年2月,我学习了很多东西,看一下下面这张图:

2-tech-tree

图中灰色方框中的内容是项目要求的知识,另外的则是我根据自己的兴趣学习的,两者基本上各占一半。事实上有很多内容(尤其是根据自己兴趣学习的)在真正要使用时,可能还需要学一遍。这些内容可能让我产生了我学到了好多东西的错觉。其实这个在另一个角度显现了技术人员的一个误区:以为自己可以掌握所有软件开发相关的知识(或者说太过于纵容自己的好奇心和兴趣)。

过载的信息

身处这样的信息过载环境,我们很难不为自己对信息的缺乏而感到不安,担心自己错过了什么重要的信息,这种担心和焦虑会促使我们进一步将时间消耗在对信息的获取上,从而更无暇思考什么是真正重要的。

《如何阅读一本书》将书分为两类:一种是提供资讯/信息(known)的,一种是帮助你理解(understand)信息的。相对于理解来讲,资讯本身其实并不那么重要。我们大部分人目前采用的碎片化的阅读方式无法提供给我们足够的“理解力”。我们都有这样的体验,有些书特别耗费脑力,读起来很累,而另一些书则非常轻松,易于消费。碎片化的阅读方式易于消费,只需要很少的思考就可以读懂,但是危害严重,它们并不会帮助你提升理解力。

4-fragmentation

但是直觉上我们会选择容易的事情来做,虽然这种浅层次的阅读只对扩展信息/资讯有帮助,对提升理解力则几乎无用。而我们在处理日常工作中的问题时,能真正帮助的,只有理解了的那部分知识。我在2014年,曾经有几个月屏蔽了所有微信、微博等内容聚合类的应用,也尽量少的去技术论坛,每天就是写代码,读纸质书,除了最初几天的忐忑之外,整个过程的收获非常大(而且也没有漏掉任何重要的信息)。

知识框架

技术人员有时候会有一种想要把所有技术都掌握的「执念」,这在局外人来看是一种荒诞不经的想法,但是置身其中,你很难看出这一点。毕竟,有意思的东西实在太多了,各种范式的编程语言、编译器技术、人工智能、数据可视化、地理信息系统、嵌入式设备、软硬件结合、大数据、自动化测试等等,每一个方向都有无穷无尽的有意思的东西。

但是在知识规模如此巨大的今天,一个人是无法掌握所有技术的,更不用说新的技术还在不断的涌现出来!这就要求我们有节制的来聚焦在某些技术上,而视其他技术如无物。当然这需要很大的勇气和魄力,不过唯有如此,技术人员才可能有真正的长进和成就。

我基于自己的经验,绘制了一个「Web开发」方面的知识框架,这个框架上包含了一个比较全的技能/知识集合,也是我认为一个「Web开发」人员应该掌握的一些知识点。

3-knowledge-framework

在成为一个专家之前,你需要先对要学习的领域有一个全面的认识。也就是说,做Web开发,需要尽可能覆盖到这个框架上的所有点。一旦完成了这棵树上的所有节点,就不用再去做第二次了,这时候你可以尝试找到树上的某一个分支,深入下去。这个听起来好像和我之前文章中的观点有所矛盾,其实不然。我在《我们真的缺前端工程师吗?》一文中提到过,“工程师不应该将自己束缚在前端开发上,要了解整个软件开发的全生命周期。”这里的观点其实是一致的,即首先要了解软件开发全生命周期中的所有节点,然后再有所侧重的去找自己的兴趣点来发展,即:先建立广度,再建立深度。

应对方法

对于知识的陷阱

当因自己的兴趣(而不是项目驱动,也就是没有实际的土壤来验证)而想要学习一个新的知识时,对照知识框架,如果发现自己已经在历史上学过它了,那就强迫自己放弃这个念头。比如你很熟悉用rspec来编写测试,忽然有一天心血来潮,想要学习JUnit,正确的做法就是泡杯茶,等这种冲动自己过去。相信我,一旦有了Java项目,你可以非常快速的掌握JUnit,而且很快会找到对应的feature,就像一个长期工作在Java技术栈上的同事那样!

对于过载的信息

实践中,首先要令自己相信:你无法掌握所有的知识,即使仅仅在软件开发领域。有了这个大前提之后,你只需要采取先建立广度,再建立深度的原则即可:

  • 做减法(在建立了知识框架之后,有针对性的学习)
  • 主动、深度阅读经典
  • 为那些有趣但非自己关注方向的知识赋予较低的优先级

另外,还可以尝试将微信、微博关闭一段时间,或者至少可以不去点那些朋友圈里的《老X聊微服务》或者《12个你不知道的Sublime技巧》文章,保持专注,保持简单。

Share

提升女性在技术会议中影响力的三个想法

在上一篇文章里,我谈及了在IT领域获得更多的女性领导者的挑战。另外一个经常被忽略的问题是,技术会议如何能保证更多的女性讲师和参会者。与男性相反,很少有人跟我讨论在这个男性为主导的技术行业中,女性的上升瓶颈是什么。而我经常参加各种座谈会和讨论,内容则是关于领域特定语言、技术架构的进化和数据的角色以及数据科学在社会部门的应用等。抛开所有的先入之见,我一直在和我的技术同行平等交流。但为什么在技术大会中还是缺少强大的女性讲师阵容呢?

这要从会议的计划流程说起。有些技术大会是邀请制的。一旦你作为女性讲师进入了这个会议的圈子,常常被各种会议组织者邀请就不足为奇了,因为他们都想获得性别平衡。

遗憾的是,我们经常发现只有很少的女性会去提交演讲题目。其实大会的策划者已经趋向于对参会者和讲师进行完全匿名的审核,这样理论上摒弃了所有对讲师的偏见。实质性的反馈也会帮助所有的提交者改进他们的内容。但是,这些只是积极的步骤,调整审核的流程并不能解决提交者短缺的问题。更要解决的问题是如何扩大提交演讲的女性的数量。以下是一些关于提高这个数量的实际建议。

跳出舒适区

一个解决方案是,确保对文章和报名的征集能够广泛的发布到整个技术社区。会议组织者可以寻找一些不同的影响圈(不要局限于常见的那些),这样就可以找到更多样化的目标群体,然后鼓励他们报名。研究表明,通常女性不愿意毛遂自荐,而这令人不安的趋势也影响了会议讨论的话题提交。

帮助和激励

会议方很难确保女性讲师的数量,因为资源池就是有限的。一种主动提升女性讲师数量的方式是,让她们第一次先和有经验的讲师结对,以获得支持和鼓励。这样的合作方式可以让女性分享这个舞台,减少压力并为其提供精神上的支持。公开演讲(特别是当听众大部分都是男性时)并不是件容易的事,但是提供一个有经验的肩膀去依靠,会极大地促进女性走向演讲台前的麦克风。我们的职责就是多去鼓励女性,促使她们迈出提交想法和专业知识的第一步。很多会议用的方法(开放对于议题的报名,然后等着大家报名)并不会产生一个多样化的候选人资源池。与其等待着报名,不如先去找到她们。

多样化的方法

例如,我即将参加的位于湾区的技术大会FlowCon,在他们的演讲者花名册里,女性演讲者达到了40%。组织者通过将特定邀请和公开提交两种方式有效的组合在一起实现了这份令人印象深刻的花名册。所以,最终的责任还是在会议组织者身上,要扩大搜索范围而不能只关注常见的地方。

解决方案就在我们面前,虽然需要更多的努力来实现。如果会议组织者关注且在乎多样性,那它就是可以实现的。如果我们共同激励和支持下一代女性讲师,将会拓展我们的领导力。新的解决方案、新的视角、新的思路以及新的思想者的声音等待着被我们听到。让我们一起伸出援助之手吧。

Share

2015.5 技术雷达 | 技术篇

点击这里可以下载最新中文版本PDF

2015-5 技术

当多个独立开发的服务通过 API 交互的时候,API 提供端的改动会让它所有的消费端调用失败。消费端服务通常也不会直接去连接处于开发中的提供端服务来进行测试,因为这样的测试是缓慢且脆弱的(martinfowler.com/articles/ nonDeterminism.html#RemoteServices),因此最好的方式是采用测试替身(martinfowler.com/bliki/TestDouble. html),但这又引出了测试替身和实际的 API 之间失去同步的风险。消费端的开发团队可以通过使用集成的合约测试(martinfowler.com/bliki/IntegrationContractTest.html)来保护自己——其比较真实服务的响应和测试替身之间的一致性。这样的合约测试是非常有价值的,而更有价值的方式是消费端把它们的测试提供给 API 提供端——采用消费端驱动的合约(martinfowler.com/articles/consumerDrivenContracts.html),提供端可以运行所有消费端所提供的测试来验证自己的修改是不是有可能引起问题。这种消费者驱动的合约测试(consumer-driven context test)是成熟的微服务测试策略(martinfowler.com/articles/microservice-testing/)中非常核心的组成部分。

当我们需要一张描述当前系统的基础设施或物理架构的图形时候,我们通常会选用自己最喜欢的工具来绘制。但是当你使用云或者其他虚拟化技术的时候,这种方式却不再适用。我们可以使用这些平台本身提供 API 去查询实际的基础架构环境,并使用一些简单的工具比如 GraphViz(graphviz.org),一些可以输出 SVG 格式的工具,生成实时的,自动化的基础架构图(automated infrastructure diagram)。

离线优先 Web 应用程序(Offline first web applications)提供了基于缓存和更新机制来设计 Web 应用离线访问的能力。它的实现需要在 DOM 中设定一个标志来检查接入设备是否在线,离线则访问本地存储,在线则同步数据。现在所有的主流浏览器都支持离线模式,通过显示的指定 HTML 属性来使本地信息可访问,同时启动如 HTML, CSS,Javascript 或其他资源的下载和缓存。当前已经有一些工具使离线优先应用的实现变的简单,如 Hoodie(hood.ie),CouchDB(couchdb.apache.org),不仅如此它们还提供与本地部署的本地存储应用的集成能力。

大多数软件开发的心智模型都是做项目,在不同的档期内进行计划、执行和交付。敏捷开发极大的挑战了这种模型,通过与开发过程同时进行的持续需求发现,代替了预先的需求确定。精益创业的技术,如观察需求的 A/B 测试(martinfowler.com/bliki/ObservedRequirement.html),进一步削弱了这种心态。我们认为,大多数的软件开发工作应该遵循精益企业的引领(info.thoughtworks.com/lean-enterprise-book.html),将自己定义为构建支持业务流程的产品。这样的产品并没有所谓的最终交付,更多的是一个探索如何更好的支持和优化业务流程的过程,只要业务依然有价值就会不断持续下去。基于这些理由,我们提倡企业组织依照产品而不是项目(products rather than projects)的思路进行思考。

当前大多数开发团队都意识到编写安全软件并以负责任的方式处理用户数据的重要性。他们确实面临着陡峭的学习曲线和大量的潜在威胁,其范围从有组织的犯罪和政府的间谍活动到仅仅是为“玩笑或激怒什么人”而攻击系统的年轻人。威胁建模(Thread modeling)(owasp.org/index.php/ Category:Threat_Modeling)是一组技术,主要从防御的角度出发,帮助理解和识别潜在的威胁。当把用户故事变为“邪恶用户故事”时,这样的做法可给予团队一个可控且高效的方法使他们的系统更加安全。

Flux(facebook.github.io/flux)是 Facebook 为其互联网应用开发所采用的一种应用架构。它通常与 react.js 一同被提及,Flux 基于一个单向数据流,用户或外部事件对数据存储的修改会触发数据在渲染管道中向上流动。已经有好一阵子我们都没有看到任何古老的model-view-*架构的替代者了,Flux 拥抱这种 Javascript 前端应用与多个后端服务通信的现代互联网时代。

当前,大部分开发人员习惯使用 git 来管理源代码以及协作。但是,git 还可以为其他一些情况提供基础的实现机制,比如当人们需要使用基于文本化的文档进行协作的时候(这些文档可以被很容易的合并)。通过使用基于文本的可编辑格式,我们已经看到越来越多的项目把 git(git-scm.com)作为一个轻量化的 CMS 来使用。Git 有很多强大的功能,通过使用分布式的存储模型,Git 可以支持对变化的跟踪以及寻找替代品。然而,难于大范围采用 Git 的最大原因是 git 对于非编程开发人员来说并不容易学习,而我们期望看到更多的构建在 git 核心之上的工具的出现。这类工具可以为一些特殊听众简化他们的工作流程,如作为内容的作者。我们也欢迎更多的工具支持对比和合并非文本文档。

凤凰服务器(martinfowler.com/bliki/ PhoenixServer.html)的想法现在已经被很好的建立并且在被应用到一些正确的问题上时带来了很多好处。而我们要部署的服务器所依赖的环境,如在某些情况下需要等待网络配置、负载均衡、防火墙端口等等情况,却已逐渐成为修改配置时的主要瓶颈和限制。凤凰环境的概念可以帮助这种情况。它允许我们可以用自动化的方式创建整个环境并保证定期销毁和重建整个环境的流程正确,例如在AWS上使用CloudFormation。凤凰环境可以支持为测试,开发,UAT等等配置一个全新的环境。它也可以简化对灾难恢复环境的配置。由于凤凰服务器的模式并不总是可行的,我们需要小心地对待诸如状态和依赖,在蓝绿部署中用它对环境配置进行重置可以成为一种方式。

函数式反应型编程在过去的几年渐渐开始流行起来,同时这个概念越来越多被延伸到在分布式系统架构中。根据反应型编程宣言(reactivemanifesto.org),反应型架构(reactive architectures)主要基于通过一个网络下独立进程间的单向,异步的不可变事件流(可能具体实现为微服务)。在正确设置下,基于这种架构的系统容易扩展,具有弹性,也会减小了各个独立处理单元间的耦合。但是完全基于异步消息传递的架构同时会引入相应的复杂度,并且常常会依赖于一些专有的框架。所以我们推荐在选择这种架构风格前首先了解自己系统对于性能以及可扩展性的需求。

对于安全,传统的方式依赖于前期的需求规格以及最后阶段的验证。这种“安全三明治”的方式很难应用于敏捷团队,因为大部分设计都贯穿于整个过程,而且也没有持续交付所提供的自动化便利。公司或者组织应着眼于如何在整个敏捷开发周期中注入安全实践。这包括:正确评估当前威胁模型的级别以做前期设计;考虑何时将安全问题划分为独立的故事、验收标准、或全局的非功能性需求;在构建流水线中引入静态或动态的自动化安全测试;考虑如何将更深层次的测试,如渗透测试,引入到持续交付的发布过程中。正如 DevOps 的出现使得过去相互博弈的团队能够重新合作一样,同样的事情也正发生在安全人员和开发人员身上。(尽管我们并不喜欢安全三明治模型,但这也比根本不考虑安全要好得多,糟糕的是,这依然是一种非常普遍的状况。)

 

点击这里可以下载最新中文版本PDF

Share