如何快速掌握一门新技术/语言/框架

任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。

IT行业中的企业特点是都属于知识密集型企业。这种企业的核心竞争力与员工的知识和技能密切相关。而如果你在企业中扮演的是工程师的角色的话,那么你的核心竞争力就是IT相关的知识与技能的储备情况。而众所周知,IT行业是一个大量产生新知识的地方,就拿Web前端举例,短短的5,6年时间,Web前端已经经历了数次变革,就目前来看变革还将继续下去。从以前的div+css网格化布局到JavaScript的方兴未艾,然后是各种JavaScript框架的百家争鸣,HTML5和CSS3的落地,移动web冲击下带来的响应式设计,jQuery,AngularJs,RectJs等操作DOM元素截然不同的理念和方式,web component的标准化进程……为什么现在企业到处都在招前端工程师?好像突然之间,前端工程师成了稀缺资源。这里的原因之一就是很多前端工程师跟不上行业变化,无法达到目前市场上对前端工程师的能力和要求。在这种大环境下,工程师能够掌握快速学习的能力就变的至关重要。

笔者根据自身的亲身体会,以及结合对周围同事的观察,对如何快速掌握一门新技术(这里的技术包括一门新的IT技术,包括一门新的编程语言,抑或一种新的程序框架等)有着以下几点指导。

要想快速掌握一门新技术,首先有两个先决条件。

1. 首先思想要主动求变,敢于跳出的自己的舒适区,对任何技术都抱有开放的心态。贪图安稳是人的本性。而这种本性往往会阻碍你的发展。人所能了解的知识的多少,取决于自己的舒适区有多大,舒适区越大,与外界接壤的范围越大,就越感觉自己的无知。程序员至少要做到两点,不要对自己不了解的技术心存偏见,不要对自己不熟悉的技术心存恐惧。

2. 要化被动式学习为主动式学习。在中国很大一批程序员每天都是在被动式学习。什么是被动式学习?就是被人、事逼着去学习。今天新启动一个项目,技术调研不想采用新的技术,开发过程中碰到难题才会去查资料,整天就是把别人的、自已以前写的代码复制重用,复制以后出问题了也要花好长时间解决。举个例子,一个程序员使用了Spring好几年,都不知道Spring的核心理念,不知道Spring框架结构,不知道Spring各个组件功能,不知道Spring新版本的新特性。这是非常可怕的,因为你不知道这些东西,就无法采纳Spring的最佳实践,出现问题不知道如何快速定位,项目中的某些需求就无法使用Spring早已封装好的功能(因为你不知道Spring还能干这个)。主动式学习需要你未雨绸缪,不能临时抱佛脚。而且要把学习看做是对自己的积累和提高,看成是对自己的长期投资,不能抱有太强的功利性。

有人说,我就是喜欢舒适区,我就是不喜欢主动学习,有什么好的方式和方法改变这两点?说实话,我所能提供给你的帮助很有限。正如《后会无期》里的一句台词,“我听过很多大道理,可依然过不好这一生”。这两点还是更要靠你个人来实现。而接下来的一些点,我相信可以帮助到你。

1. 学习一门新技术前,先要搞清楚为什么要学习它?没这个技术前我们是怎么干活的?有了它以后我们又是怎么干活的?它带来了哪些改变?其实问这些问题,就是为了了解该技术解决或者简化了那个问题域的问题,又是采用了什么方式达到了这样的效果。就拿AngularJS为例,AngularJS最初是为了弥补HTML构建应用的不足。以前的HTML在设计时是为了展示多媒体信息,后来虽然拓展了一些动态功能,但是在应用web化的潮流下,HTML设计上的不足就越来越突出。比如DOM元素操控太繁琐、业务逻辑很难模块化、可测性低、开发效率底下等。而AngularJS采用了一种全新的设计来解决该问题,它提出了一系列概念,引入了数据绑定、标识符、路由、依赖注入等特性,大大简化了我们开发WEB开发的工作量。通过这样的方式能迅速建立起了对该技术的宏观认识,了解了其潜在的应用场景、应用方式以及一些局限性等。

2. 接下来就要实际使用一下该技术的核心的功能,强化对它的认识。方式就是参考该技术官网的Quick Start(快速开始)章节,一步一步来。*现在的程序员越来越珍惜时间,文档的简洁性、完备性、易上手都成了是否采纳某项技术的指标之一。尤其是现在的各种开源组件,连文档都是开源的。所以很多文档都是完全按照程序员的思维写的,读起来很清爽。再拿Spring来说,想学习Spring4.0推出的Spring boot组件,那么可以访问其官网http://projects.spring.io/spring-boot/,页面上最大的按钮就是Quick Start。点击学习吧。页面是一个简单的例子,可能花不了你五分钟。如果还没过瘾,右边又列出了更多的Getting Started Guides ,也是一步一步的教你进阶功能。有些人可能要问了,英语不好怎么办?请学英文。英文是一个优秀程序员的必备技能。可能也有人说,看文档时有各种杂音咋办。比如看Spring boot的start guide,需要之前对Spring有一定了解,需要知道tomcat、jetty是干啥的,需要有一定gradle或者maven使用经验…这些知识在演练Spring boot的那个小程序时都需要,但由于这些杂音的干扰,会拖慢学习的过程。摆脱这些杂音的唯一方式就是,对于那些不了解的知识点,也花时间去学习吧。所以学习是一个良性循环的过程,学的越多,就学的越快。

3. 前面两步能够保证你对一门技术入门,那么如何进阶那?这个阶段就是读了。从官网上把该技术的详细文档扒拉下来,使劲读吧。通读这些文档能让你进入它的实现细节,以及各种使用方式与场景,甚至一些最佳实践。比如Spring boot官方文档,http://docs.spring.io/spring-boot/docs/1.3.0.M3/reference/htmlsingle/,详细到了牙齿。凡是你想到的、没想到的,文档都贴心的列了出来。如果你想学习Scala,那么请访问http://www.scala-lang.org/documentation/,各种文档应有尽有,读完就是大半个Scala专家。一门技术最好的文档必须是它的官方文档,如果不是,那么这门技术火不了。注意通读文档的过程中一定要在项目加以运用。如果在项目中没实践机会,自己可以写一些小的demo来实践。学习知识时实践与理论相结合的道理恒古不变。

4. 走完前三步,你对这门技术的理解已经比大多数人强了。你可以算掌握这门技术了。那么还有进阶方式没?当然有,那就是把你所学、所想讲出来,写出来,暴露在公众之下,接受批判,从而发现自己的不足,促使你进步。有空给大家做几个讲座,写几个系列文章,那么你在大家眼中就成了这门技术的牛人。你就有了各种机会来解决使用该技术遇到的各种疑难杂症,反过来加深和修正你的理解。没事上上StackOverFlow,回答别人几个问题,或者订阅该技术的问题列表,经常看一看。

5. 还可以再继续深入。加入国内/国际技术社区(国内没这样的社区咋办,机会来了,赶紧自己建一个),进一步发挥自己影响力。翻译、编写与该技术相关的书籍;如果该技术是开源的,那么有时间就提交修改把,自己就成了开发者一员了。这就是质的飞跃,从使用工具进阶到创造工具。

走完5步,你已经不是仅仅掌握这门技术了,你已经超神了好吧!有人可能又会问,能达到这五步的肯定要花很长时间,不是一般人能够到的高度。那当然了,这个过程肯定很难,但并非难到登天。至少我身边有很多这样的例子。其实你只要完成前三步,你就比50%的程序员牛了,完成第四步,你已经站在90%程序员的前面。

最后快速总结。重要的事情说三遍。

1. 主动学习很重要,主动学习很重要,主动学习很重要。

2. 官方文档很重要,官方文档很重要,官方文档很重要。

3. 实践很重要,实践很重要,实践很重要。

Share

公益IT的精益之路

 本文发表于《中华读书报》2015年8月12日,任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。

不止一位在公益机构工作的朋友对我说:现在大家都在谈数字化、谈“互联网+”,我们机构也想用互联网思维武装自己,你看我们是不是应该开发一个某某某系统……听他们畅想自己的数字化宏图,在这场对话中扮演“IT专家”角色的笔者往往却只能泼冷水地说:开发系统太贵了。笔者在一篇题为《开发软件有多贵》的文章里曾粗略估计,自行建设并拥有一个普通IT系统的成本可以轻易地达到上百万人民币。这个级别的开销对于普通的公益机构来说,无疑是难以承受的。

903-熊节-公益IT

应该看到,大多数组织、大多数人看待IT的方式,本来就是由少数几家大企业通过不懈的广告宣传给培养出来的。也就是说,“主流的”IT视角是为金融、电信、零售……这样的大型商业机构服务的,因为这些机构才是IT大厂商的主要顾客。这种视角的差异,决定了主流的IT话语未必适用于公益机构。1968年,一位名叫梅尔文·康威的程序员指出:IT系统的结构与组织机构的结构相匹配。按照“康威法则”我们不难明白,为什么传统上大家观念中的“企业应用”都是大规模、整体化、高复杂度、高定制度的软件系统,例如ERP、CRM等等——因为现代的大企业正是这样,由大批专门人才紧密结合成一个个部门、再组合成高度内聚的商业机构。

然而公益机构的结构并不经常像企业这样紧密内聚。很多时候,公益机构的运作是以少量全职员工加上捐赠者、志愿者、政府等各方力量共同构成的松散组织来进行。当组织结构的性质变化,照搬企业IT的建设思路自然会遭遇困难。且把定制IT系统高昂的成本放在一边不谈,公益机构既难像企业那样对志愿者进行高密度的IT培训,又难像企业那样严格约束志愿者,实施定制IT系统的难度可想而知。更不用说公益机构面对的问题域往往不像商业领域那样有清晰的定义,这又给IT建设增加不少变数。

面对成本受限又充满未知的领域,《精益创业》提供了一条切实可行的路径。以“开发-度量-学习”的循环快速迭代,精益创业方法提倡验证性学习、灵活调整方向、以及“快速地失败、廉价地失败”。作者介绍了一个创业者开始网上订餐业务的故事:这位创业者没有开发任何复杂的软件系统,只是手工把几家餐馆的菜单放上网,然后自己接电话收订单、自己到餐馆取餐、自己送货兼收款,以此验证自己的点子,随后在营业额上升、人手不敷的时候才开发软件来自动化。这种建设IT系统的方式,对于公益机构而言不无借鉴意义。

沿着精益创业的路径,公益机构不太可能建设出像企业应用那样高度集成的“IT系统”,更有可能建设出一系列简单IT工具组成的“IT生态”:用WordPress之类的工具搭建的简单网站用作机构介绍;微信订阅号用于传播内容;金数据用于收集捐赠者信息和招募志愿者;内部的捐赠者管理和志愿者管理则用有版本管理的Excel表单完成……有趣的是,这样的IT生态却恰好与公益领域多方协作的生态结构相匹配,又因为大量借用现有软件工具而降低了所有使用者的学习曲线,于是这样“生长”出的IT系统不仅成本较低,而且往往比以企业模式集中实施的IT系统更为使用者们接受。

借用现有软件、让IT生态“生长”,不表示公益机构的IT建设不需要规划设计,只是设计的重心不再是单一的IT系统,而是与公益生态对应的IT生态。《商业模式新生代》把听来高冷的“商业模式”放在一张纸上描绘出来,帮助设计者思考一个机构、一个“生意”最根本的要素:顾客、价值、渠道、客户关系、收入来源、核心资源、关键操作、重要合作、成本结构。虽然公益不是商业,但这种灵活而可视的方法同样有助于公益机构厘清生态系统中各方的关系与协作模式,进而定义与之匹配的IT生态。

媒介学家德布雷说,吸引人关注某一问题最好的方式是通过互动,“让观众参与”。在思考公益机构的IT规划与建设时,需要跳出企业IT内聚、内向的视角,纵观整个生态系统,设计各种IT工具在各方交互中扮演的角色。对于资金有限的公益机构而言,这可能是一条更实用且效果更佳的数字化路径。

Share

对微软技术的典型误解和偏见

901-陈计节-微软技术的误解

任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。

到目前为止,软件授权费用仍是微软的主要收入来源。微软自己的软件卖的很好,同时,在他造就的平台中,提供丰富多彩也高效好用的开发工具,也十分注重培养开发人员的培养。直至今日,企业解决方案仍是微软强有力的现金流。近来几年,微软的路除了企业市场仍持续的稳稳当当,云服务在中国的发展只能说平平淡淡,其设备与服务方面也一路坎坷;甚至由于移动设备上整个行业的发展惊艳夺目,与此相比成熟稳重的 Windows 却难以再给人们太多的惊喜。这样的情景之下,趋利、逐热的媒体会做的自然也就是煽风点火,起哄不怕事大了。不少人,使用盗版的 Windows 去到互联网上,喷着从没用过的 Windows Phone,却又不忘捧一下那个他从没访问成功过的搜索引擎。这样的状况,不免令人感到可悲。

互联网化、云化,以及长尾化发展只会越来越深入;伴随着新 CEO 的上任,微软本身也提出“移动为先,云为先”的理念。近几年,微软在开源社区中也一改以往低调的形象。可是,神奇的是,微软的开发技术在社区里是说不得的。别看博客园、CSDN 等网站起初都是由 .NET 技术人员社区贡献起来的,至今 .NET 背景的人在它们的用户中仍占据一大部分。但把目光转到杂一点的技术社区,或是线下活动,一听说你是 .NET 技术背景的,周围的气氛一下子就变得僵硬了。人们尴尬。尴尬的是,大家都用着 Windows,却又深深地嫌弃着微软的技术;却又不好那么直接地与对面的说话者袒露出自己的这种感受,好像自己也觉得自己的这种嫌弃不是那么上台面、值得怀疑。
对于微软这样一个庞大的企业来说,“微软技术”一词的涵义显然太丰富,而我仅希望谈论其有关 Web 开发和云相关的技术。不少人将 .NET 体系,以及 Windows Server 系列,甚至是 Azure 模糊不清地统称为微软技术,所以我也顺便这样引用一下(就像有些人将 HTML5 称为 H5)。对微软技术的误解与偏见在社区里是很微妙的,不少人对微软的开发技术栈有一些由来已久的偏见。在这里,我列举几点,并指出为什么这些误解与偏见是多么的谬误。

误解:使用微软的开发技术将被绑在微软的产品体系里

软件很复杂,一个大型的软件通常需要多个组件的通力合作才能正常运转。最典型地莫过于数据库、运算逻辑,以及界面或终端设备了。实际上,无论是从法律角度等客观因素还是从目前的现实来看,上面这个命题都是不成立的。
Windows Server 可以运行大量的编程语言平台,部署多种数据库系统,由 Windows Server 提供的服务也不会限制客户端的种类与提供商。在 IIS 上,在 ASP.NET 之外,我们当然也可以宿主 PHP、Java 应用程序,甚至是 Node.js 和 Python 应用程序。而 ASP.NET 作为一种应用程序开发框架,从来也不会限制你使用的服务器类型(Windows 或是其他),也不会限制你使用的数据库,更不会限制客户端浏览器或设备。Visual Studio 会让你觉得拘束,脱离了它不能够开发了?这就更假了,以前大多数人在使用盗版,就算微软提供了免费的 Express 版本;而现在,大家更可以免费地使用官方提供的社区版了。
人们另一个担心是如果跟随微软的脚步走下去,哪一天微软放弃一种技术,自己就跟着走进了死胡同。我的看法是,你就是你,你不必跟随谁的脚步而导致丢了饭碗——如果确实发生了,那你得考虑一下为什么如此盲从以至于失去了自己的方向呢?微软的技术可能由于微软公司的决策而前途未卜,但其他技术更会如此。与微软推行的技术相比,一个开源项目死掉,或者不向下兼容的可能性要大得多。从微软技术的角度来考虑,这些项目被抛弃的原因并非微软随意决策,而是由于它们将退出技术舞台而不再被人们需要,所以它们被抛弃是必然的。而从开源技术上来考虑,一个项目死掉的可能性更高:核心团队的解散,没有经费继续支撑,技术需求过少社区氛围不活跃,碎片化过于严重等问题比比皆是。当然有人会说,如果一种技术开源了,至少自己可以继续使用,或者组建团队维系它的生命。这种毫无水准、巧言诡辩的说辞,我也只好笑笑罢了。

偏见:微软的技术不够开放

开放可以从两个方面来理解。其一,本身的内聚性,以及对关联产品的依赖;其二,开放源代码并且社区友好。第一个方面,在上一个误解里已经谈到。
对于不够开放的开发技术(框架或库),开发人员不敢过多地依赖,毕竟“难以了解它的运行细节,也不能对它进行按需修改”。这个理由是很充足的,开发人员确实在很多情况下,需要了解软件运行的细节,这对对开发框架的理解,解决问题时思路,以及调试程序等方面都有帮助。微软也意识到这一点,因此 .NET 框架的源代码很早就开放了,所有人都可以通过网络获取。不光可以查看源代码,还可以下载编译符号,从而直接调试 .NET 框架本身。
另外,从2014年宣布 ASP.NET vNext 之后,ASP.NET 的开源十分彻底。核心团队将代码迁移托管到了 GitHub 上,使用 Apache 协议授权使用,并接受代码提交。同时,微软还将 ASP.NET 5 及其周边的一系列工具打造成为能够跨平台运行的新型 Web 开发平台。
当然,对于绝大多数人来说,开不开放并没有什么区别。因为他只听说,不开源就是罪。

误解:用微软开发技术很贵

如果放在国外,这句话很真实。在中国的企业,说使用微软技术会贵的话,还是收回去吧,问问你买了几套 Windows,请问一套 Windows 8 Pro 多少钱?是的,微软的很多软件都是收费的,比如 Windows Server,Sql Server,Visual Studio 和 TFS 等。如果是企业里的应用平台,那么这些软件的授权费用确实不菲。微软的软件产品我不评论,自当有愿意购买它们的企业来买单。对于大型企业来说,花钱买软件和服务,还是花钱养人,这是一笔见仁见智的账。企业大了再想,也不迟。

如果是在互联网创业公司里,那么可以有更多选择来节省开支。但开发技术中,我们使用基于 C# 的 ASP.NET 应用程序框架的同时,可以使用 MySQL 和 PostgreSQL 等免费数据库,可以使用 GitLab 和 Trello 等免费的代码与项目管理工具,可以使用 GoJenkins 等免费持续集成工具。

偏见:.NET 开发人员只会拖拖控件

哦,这句话已经很老了,我甚至也不想提了。但这句话很可怕,它简单一句恶毒的话就试图形容一个巨大的群体。我还是不得不在这里说说对这句话,我如何看待。
首先,拖控件并是什么问题。拖控件也并非一种很低级的技术,而且也并不是只有 .NET 开发人员拖控件。相反,它是一种经过高度封装而存在的,非常高效的创建界面的技术。“所见即所得”是它的重要特性,直观而有效。问题出在“只会拖控件”上。如果一个人只会拖控件,那他根本还不能称之为开发人员,最多只能说是见过 IDE 而已。因此,.NET 开发人员只会拖控件这句话显然是不成立的。
微软一直致力于降低开发软件的难度:

  • 在本身就易用的操作系统中提供大量可编程的特性
  • 在提供的几乎所有的大型软件中提供可编程的接口和能力
  • 发明了多种编程语言,并支持多种设计风格与范式
  • 免费提供好用的开发工具
  • 足够大量的用户

这些因素让为微软的平台开发软件变得更容易的同时,也导致出现大量的技能低下的开发者。这是很自然的,也是再正常不过的。比如厨艺,只要有一个厨房,就可以开始,但显然并非所有人都是厨师。而人们总是自以为是的,以为自己会拖一个界面就成为了开发人员。那些井底之蛙们很自然地成为了大多数,顺便把另一批优秀的人代表了。

偏见:就因为它是微软的技术

微软有原罪。我终于无话可说了。
年轻人需要酷,这是容易理解的。微软的技术看起来好像没那么酷。微软并不是一家酷酷的公司,至少比不上另外那些看起来酷的。不过,酷能用来干什么?能吃么,能增加效率么?本质上,酷只是一种主观感受。而主观感受往往与了解它的多少而有所改变。看起 Mac 上的灯,以及整体银色的外表好像洁白无暇的公主般圣美,然而当你搬动它你会发现它笨重的惊人,它甚至还能将你烫伤。Windows 机器看起来中规中矩,却勤勤恳恳,随时为你效劳,帮助你把事情搞定。

结论

微软是一家商业公司,自然需要追求盈利。这并不是什么过错,也无需人们指责。但美好的事物存在了,从不因为他人喜恶而变化。工具也许并没有高下之分,只有适合与否。给你一根金箍棒,普通人也搬不动,更不谈降妖除魔;唯有孙长老才有能力将其发挥到极致。

可笑的人们却总是喜欢用自己那原本就是由屁股决定来的脑袋来教导别人,来宣扬那莫须有的己方,去抨击那空想出来的异已。

有空的时候,去读一读 C# 的代码,去看看 IIS 的管理能力,去试试 PowerShell 的魅力。你会讲一个比我更生动的故事。

Share

移动App测试的22条军规之“确定设备和平台再动手”

(ThoughtWorks洞见网站 获人民邮电出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。)

第一章

1军规:确定设备和平台再

在测试设计之初, 测试人员首先会考虑的是什么呢?没错,就是测试的环境,也就是确定app究竟需要运行在什么样的设备和平台上。

显然,在移动设备和平台碎片化的现实中,测试人员穷尽所有设备和操作系统的版本来实现全覆盖的测试是不可能的。那如何在有限的时间和精力投入下,从投入产出比的角度出发,达到尽可能多的测试覆盖呢?这里主要考虑以下几个方面:

  1. app的特性
    1. 如果app是针对心率监测,指纹识别,NFC(近场通信),红外线操控这些需要特殊传感器设计的,那对测试设备和平台的选择就相对少一些,只需要考虑那些拥有这些传感器的设备。 例如对于支持指纹识别的app,测试人员需要考虑的设备也就是iPhone 5siPhone 6iPhone 6PlusiPad Air2iPad mini3LG G3,三星Galaxy S5,三星Galaxy Note4HTC One Max,华为Mate7这些设备(不考虑市场占有率比较低的vivoOPPO的手机);而如果app支持心率监测, 测试人员就只能选择三星Galaxy S5Galaxy Note4了。

里推荐大家使用一个网站http://www.phonearena.com来做设备的查找工作。通过这个网站不仅可以查询到各种手机和平板设备的详细参数信息,还可以对它们进行横向对比,方便测试人员找到适合用来做测试的设备(如图1.1)。

样章-1

1.1 http://www.phonearena.com设备对比

    1. 如果app是针对某种平台所独有的功能设计的,或者是某种平台独占的,测试人员就只需要考虑相应平台下的设备。比如app是类似Android设备上层出不穷的“xx清理大师”,那在确定测试设备和平台时就不需要考虑iOS平台了;又比如之前Instagram选择只支持iOS平台,那作为Instagram的测试人员只需要关注与iOS设备就足够了。

或者,如果app选择不支持某种平台,相应地,测试人员也就不需要测试运行这些平台的设备了。比如WindowsPhone、黑莓BlackBerry以及塞班Symbian平台在市场上的占有率已经很低了(根据2014年第四季度的调查,详见图1.2),如果在开发时选择不支持这些平台,那在测试时测试人员就完全可以忽略相关的设备。

样章-2

1.2 2014年第四季度各操作系统市场占有率调查表数据来源: www.netmarketshare.com

    1. 如果app是面向大众的通用型app,测试人员就需要结合移动app的生命周期和测试设备的硬件参数来确定测试设备和平台了。
  1. app的生命周期
    1. 对于还处于开发阶段但准备不久之后投入市场的一款新app,鉴于并没有已经实际使用app 的用户,所以测试人员要“预测”真实的用户所使用的设备和平台。在这种情况下,首先需要了解使用app的主要用户是哪一类人群,比如说是发烧友,还是商务人士 。发烧友极有可能使用的是最新的设备和平台;商务人士更多使用的是成熟的平台,高端一些的设备;而如果用户是普通大众,就需要通过 AppleGoogle官方布的版本占有率数据来帮助测试人员进行有依据的“拍脑袋”了。

以下是Apple官方布的iOS版本占有率数据(如图1.3: https://developer.apple.com/support/appstore/ Google官方布的Android版本占有率数据(如图1.4: http://developer.android.com/about/dashboards/index.html

样章-3

1.3 - 截止201515日,iOS各版本所占比例

样章-4

1.4 - 截止201515日,Android各版本所占比例

    1. 对于已经发布并且有稳定用户群的app,测试人员可以使用在桌面应用开发时用到的工具,例如Google AnalyticsOmniture SiteCatalyst(现在Omniture Adobe收购了,工具也改名叫做Adobe Analytics )来统计的信息,从而确定app支持和需要测试的设备及平台。这里对于app有一点要求,就是app需要联网对后台的服务器发送请求,从而能获取到用户信息。

Google AnalyticsGoogle分析,http://www.google.com/analytics )是Google的一款免费的网站分析服务,使用范围也很广泛。Google Analytics功能非常强大,只要在网站的页面上加入一段代码,就可以提供的丰富详尽的图表式报告。Google Analytics的特点是简单易用,但是相应的缺点就是不可定制化。

样章-5

1.5 Google Analytics

Omniture SiteCatalystAdobe Analytics http://www.adobe.com/solutions/digital-analytics.html )是一个进行网站基本指标的搜集,报告和分析工具。由此通过这个软件可以得到网站和app的访问量,浏览量,跳出率,转化率,来源等诸多指标。只要在app中对不同事件以及发送请求都添加相应的Omniture追踪,然后再登陆Omniture的网页就可以进行用户数据分析。Omniture SiteCatalyst不同于Google Analytics的一个特点是,它可以对数据进行高级细分,也就是说,可以对用户的各种操作打上不同的标签,在服务器端搜集到信息后进行统一的筛选和分析。

样章-6

1.6 Omniture SiteCatalyst

    1. 对于上面两种情况,有一种特例需要考虑,就是在有新的操作系统版本将要发布的时候,需要参考以前操作系统版本升级时用户更新的进度。正如图1.31.4所示,在 iOS 8发布三个月之内有68%的用户进行了升级,而使用iOS 7之前版本的用户只有4%;而Android 4.4 Kitkat发布一年后,市场占有率才刚刚达到39.1%,有超过52.7%的用户使用的还是4.04.3版本的Android,甚至还有8.2%左右的用户还在使用着Android 2.x的设备。

根据这些数据,测试人员在iOS操作系统版本升级时需要及早适配新的app版本;而对于Android发布新的操作系统时,测试人员主要还得关注当前市场占有率高的那些老版本。

  1. 设备的硬件参数
    1. 屏幕尺寸:现在手机越出越大,连坚持自己风格的Apple也开始跟风发布大屏手机了。屏幕大小除了会影响显示效果外,还会影响到用户的使用习惯。一般用户手持6寸屏幕的设备时,会采取双手操作的方式,所以app如果同时支持横纵屏显示会带来更好的用户体验(如图1.7所示)。
    2. 样章-7

1.7 - 双手持握设备的方式

而对于45寸这种可以单手持握的设备,如果app无论横纵向显示,按钮都最好不要放在屏幕四个角,以免用户很难点击(如图1.8所示)。

样章-8

1.8 单手操作范围。

49%的单手操作用户采用的是以上两种姿势(左手用户相反)。绿色代表容易点击区域,黄色为拇指伸展可到点击区域,红色区域超出单手可点击范围

    1. 分辨率:分辨率的大小会决定显示内容的多少,这对显示图片和视频时会有一定的影响(如图1.9所示)。样章-9

1.9 - 不同分辨率下显示内容的大小以及显示比例

还需要注意的是,有些厂商(比如说魅族)虽然标注的屏幕尺寸和通用产品一致,但由于显示比例的不同,分辨率和通用产品也会有差别(如图1.10所示魅族MX4采用的是15:9的屏幕比例,而非标准的16:9的屏幕比例)。

样章-10

1.10 魅族MX4的的屏幕比例

    1. 像素密度:屏幕大小和分辨率决定了像素密度。不同的像素密度对于显示也会有差别:在retina的屏幕上显示非retina的图片会很模糊,反之则会显得失真(如图1.11和图1.12所示)。如果需要同时支持retina和非retina的设备,那测试人员需要测试是否对图片尤其是app的显示图片提供retina和非retina两个版本的图片。样章-11

1.11 retinaretina的文字显示

样章-12

1.12 -非retinaretina的图片显示

选取了操作系统版本和测试设备之后,就可以设计矩阵来配对操作系统版本和测试设备了。具体可以参考图1.13的表格。

样章-13

1.13 - 测试设备和操作系统版本对照表

设计测试设备和操作系统版本对照表的原则是:让不同分辨率,不同屏幕尺寸大小的设备尽可能多地涵盖各个操作系统版本,另外,对于市场占有率很高的重点操作系统版本,可以使用多个设备来测试。

可以看到,对于同一种设备(图1.13中的iPhone 5s),由于市场占有率大,而且支持多个操作系统版本,所以在iPhone 5s上需要测试iOS 7.18.1这两个版本;由于iPhone 5siPhone 6Plus分辨率、性能等都不一样,所以同样对于iOS 8.1,两者都需要测试。

在设计Android设备和操作系统的覆盖时,可以看到对于类似的设备(HTC One XL和三星Galaxy S3硬件水平很接近),并没有要在它们上分别都测试覆盖Android 4.14.2,而是在HTC One XL测试Android 4.1,在三星Galaxy S3上测试Android 4.2Sony Xperia Z不仅在CPU、内存、屏幕大小和分辨率上都和三星Galaxy S3不同,所以在这两部设备上都需要测试Android 4.2

设计表格的过程中,测试人员还需要注意两点:

  1. 操作系的小版本升一般只是修复缺陷,不会引入新的功能,例如iOS8.0.1升级到8.0.2,以及Android4.4.1升级到4.4.4。这时,如果不是app恰好被这些缺陷修复所影响,测试人员不需要考虑覆盖这些小版本。至于中间版本的升级,例如从iOS 8.0.2升级到8.1,以及Android4.1升级到4.4,这时需要考察变动对app的影响,决定是否测试覆盖相应版本。就拿Android 4.14.4来说,因为Android 4.44.1新增了ART运行环境,所以针对这一点,测试人员需要准备设备安装Android 4.4,而不是仅仅在安装有Android 4.1的设备上测试。至于操作系统大的版本升级,就必须要进行测试覆盖了。
  1. 随着操作系统升级,既有的设备可能无法流畅地运行新的操作系统时,测试人员就需要考虑是不是还继续在新的操作系统上测试这些设备。比如,iPhone 4在升级iOS 7之后运行速度变得很慢,各种操作的延迟都会很长,固然有一部分用户还是强忍着会继续使用,但是很多用户会放弃在新的操作系统上使用运行很慢的老旧设备。当新的操作系统升级时,甚至有些旧的设备就不会被支持了,例如iOS 8就不再支持iPhone 4 。这时候如果确定这些旧的设备上的操作系统占比很小的话,测试人员就可以果断放弃这些设备。

所以测试人员需要从设备角度出发决定要测试的操作系统,以及从操作系统出发决定要测试的设备这两方面来考虑测试设备和操作系统版本对照表的制定。

明确了测试设备和操作系统版本,下面我们就来了解下在设计测试场景和用例中可以运用哪些具体的军规。

购买本书请点击链接:http://item.jd.com/11730286.html

Share

技术人员如何写一本书?

我在过去的几年中,写了4本书。有传统意义上的两本实体书:《JavaScript核心概念及实践》《轻量级Web应用开发》,还有两本电子书《3周3页面》《函数式编程乐趣》。当然对我而言,主职工作是软件开发,写作是个副业。

在写作的过程中,有一些有趣的心得。

  • 写作本身是一个很好的学习过程(至少是一个驱动你学习的动力)
  • 写书非常枯燥,特别是校对的时候
  • 写作不会让你变得富有,但是有时候会让你开心(不总是)

写文章 vs 写书

写博客/文章和写书还是有很大差别的,一个明显的差异是写文章会比较随意,而且应该尽量保持精简。一篇文章提供一些信息即可,应该尽量远离细节(如果写一篇教程,则另当别论)。而写书则应该尽可能的深入细节,尽可能可以让读者依书自修。

投入与回报

首先要明白的一点是,不要指望用写书来赚钱,至少前4本是这样的。粗略的算一下:我的第一本书卖了3000册,每卖一本我可以得到4元RMB,一共就是12,000元RMB。而这本书我断断续续写了三年。那是很多个周末,很多个假期,很多个夜晚的付出换来的,如果真正要计算投入产出比的话(纯粹金钱上),这显然是一个毫不合算的事情。

作为一个参考,IBM developerWorks的投稿,千字200元,一般写5,000字以内,也就是800元RMB左右。而要写一篇这样的文章,我只需要一天(当然需要数周/数月的积累)。12,000元RMB需要写15篇文章,如果每周写一篇,不到4个月就可以写完,而且写文章比写书容易多了,毕竟篇幅比较短小,易于校对。而且对于大部分开发者来说,固定在一个主题上的难度要比15个独立的主题简单的多,因为无需特别深入。

所以根据经验,要抱着公益的情怀来写书。也就是说为了让知识更好的分享,让你学习到的先进科学技术来帮助更多的开发者,提高他们的开发效率,让他们可以在周末多休息一天。而至于翻译技术书籍,那基本上就是免费的了,完全是一个公益活动(耗时数月,斟酌字句,推敲表达方式,但是价格极为低廉:千字60元RMB),所以下次见了技术书籍的译者,就多少给他捐点吧,他们才是在为人民服务

知识的诅咒

“知识的诅咒”是指人们在获得了某种知识之后,就无法想象没有这种知识的情况了。这种现象随处可见,比如一个你到了一个从未去过的陌生城市,遇到以为当地人,然后向他问路。当地人觉得已经说的很清楚了,但是你还是不知道该怎么走。另一个例子是:假设你不认识泰文,然后你打开任何一本泰文写的小说,你只能依稀感觉到这是一种文字,除此之外你并不能从中获取任何的信息。但是当你学习了一段时间泰文之后,再来看这本小说,之前的那种感受就再也没有了。

curse-resized

写书的时候,你首先需要具备某种知识。但是写书的目的是将这些知识传递给那些不具备此知识的人,而根据“知识的诅咒”,你又无法确知那些初学者会遇到哪些问题!解决这个问题的方法就是找初学者来试读。而且为了保险起见,还应该找尽可能多的人来试读。

写作方式

一种方式是自下而上的,写一些独立的文章,最后发现可以串起来,然后形成一本书,另一种方式是自上而下,但是又会逐步调整。根据经验,不论是写一篇简单的博客,还是写一本书,都需要按照自上而下的方式。随心所欲的写下去,基本上都收不住,而且整个文章支离破碎,貌似有很多内容,但是不成章法,读者也无法轻松的获取知识。

先列出大的章节,然后逐步细化,但是未必是按照顺序来写。先编写自己最熟悉的部分,然后逐步完善。例子的选取需要精妙而恰当,最好有图例来说明。

配图制作

一般而言,我在书中会使用两种图:流程图和一些截屏。截屏通常使用Mac OSX自身的功能就已经足够,而流程图我会采用一些额外的工具如:

  • graphviz
  • keynote/sketch

cgi

用Graphviz画图的好处就是可以将图像代码一样放入版本库来管理。

除此之外,我还学习了一些设计软件的基本用法,事实上只需要用一些简单的元素就可以做出非常专业的配图:

  • 字形/字体(大小,粗细的变化)
  • 颜色(基本的配色理论就可以做出很舒服的配色)
  • 层次(尺寸,位置,颜色的深浅)
  • 阴影

mock-server-resized

代码格式

书中实例需要很多代码来说明,如果是制作电子书的话,可以使用Markdown预处理器自带的功能来高亮。另外如果需要RTF格式,可以使用这些工具:

  • highlight工具
  • intelij中的插件copy on steriod

这里有一篇博客来说明如何将你的代码带着格式拷贝到剪贴板中,拷贝之后,就可以将这些内容粘贴到Word或者Keynote中了。

jest.dontMock('../components/headline.jsx');

describe('Headline', function() {
  var React = require('react/addons');
  var Headline = require('../components/headline.jsx');
  var TestUtils = React.addons.TestUtils;

  it('#render', function() {
    var text = "this is a title";
    var headline = TestUtils.renderIntoDocument(<Headline title={text} />);
    var title = TestUtils.findRenderedDOMComponentWithTag(headline, 'h4');
    expect(headline.getDOMNode()).toBeDefined();
    expect(headline.getDOMNode().textContent).toEqual(text);
  });
});

一些潜在的坑

在写作的过程中,会有一些潜在的坑。这些所谓的坑是新人可能无法想到的。相对于言之无物,不知如何下笔,最痛苦的其实在于平淡。大部分时候,你可能很容易就能写出开头,但是很难坚持到最后。即使好不容易写完了第一版,后续的重读和修改,会让你苦不堪言。

内容写好之后,样式是下一个重要的问题,好的内容需要有与之匹配的排版。在中国,作者不但要负责内容,还要负责一些排版的事情。这一点非常奇葩,但是又是实情。这也是我更推荐电子版的原因(排版更加美观,选择更加多样,而且一旦有问题可以更容易的修改)。

另外一个问题是错别字检查!检查错别字对于作者来说,是一件非常困难的实情。而对于读者来说,则是一件很容易的事情。这跟知识的诅咒的道理一样。

typo

发布方式

实体书

传统的出版方式有一些明显的问题,这些问题已经和现代的知识传递方式产生了冲突:

  1. 时滞性(新技术的更新速度远远超过审批,印刷等流程的时间)
  2. 排版(如何低成本做到语法高亮,或者彩图)
  3. 更新频率(当技术更新之后,如何更新,是传统纸质书无法解决的问题)

传统的出版方式有点像传统的软件开发,一本书从开始写作到最终出版,要经过很多环节。忽略掉写作过程,从交稿到出版会经历很多次审核和校对,可能会历时4-8个月,着这个过程中,很多东西都可能发生了变化,一个典型的例子是《用AngularJS开发下一代Web应用》,原版为英文版,翻译成中文版再到出版之后,书中的很大一部分内容已经过时。读者拿到书之后,会发现书中的内容已经和当前的版本/文档不匹配了。这种现状随着技术的更新速度和频率还会再加剧。

第二点是排版。我听说国内有些出版社已经开始接受Markdown作为稿件的格式,但是大部分还采用Word或者WPS等格式,这样排版就变成了一个大问题。以我自己为例,我的原稿用Markdown写,但是写了几章之后不得不切换到Microsoft word上,而我自己的Mac OSX下的排版到编辑的Windows下就会变样,而且还会涉及字符集,字体,Word版本等等问题的影响,最后导致印刷出来和原始稿件出入很大。

最后一点是更新频率,如果发现了错别字或者错误的地方(即使之前检查过多次,仍然会有漏网之鱼),由于实体书的特殊性,一般需要等到再次印刷才能解决。这意味着先购买的读者会承担一些风险,更新后的版本又如何让读者看到呢?总不能又买一本吧。

但是这些问题都可以通过电子书来很好的解决。首先,电子书可以随时更新,最低限度的降低时滞性。排版上来说,作者可以使用Markdown来编写,而展现则可以应用一些预定义的模板来完成。最后,更新频率完全可以控制,对读者来说风险更低,因为电子版书籍的可以很容易的追踪交易记录,从而得到免费的更新过的版本。

电子书

目前已经有很多的渠道可以发布电子书,比如gitbook知笔墨。这些应用的出现,大大降低了发布书籍的成本,我的《函数式编程乐趣》,用了3天就完成了草稿,而发布只需要数秒。

另外一个问题是书籍的价格和作者的收入。一本书定价50元RMB,出版社给作者的版税是8%,也就是说,没卖出一本,作者可以得到4元,如果你的书非常畅销,这还是一个不错的价格。但是可能90%的书籍都不会是畅销书(就好比每个班级都会有优等生,但是他们仅占全班人数的10%一样)。这对作者是一种浪费:你需要耗时数月甚至数年来写一本书,然后市场的反馈又非常慢(毕竟你无法出版一本未完成的书)。

我在selfstore.io上有两本电子书:《3周3页面》《函数式编程乐趣》《3周3页面》定价为16元,每卖出一本,扣除掉交易费之后,我可以得到14.7元。

对我来说,这样可以得到更多的回报,对于读者则可以更加快速的得到更新,而且由于有预览版和一系列的其他信息,还可以在很大程度上降低读者的风险(更不用说快递费,等待时间等问题)。我在gitbook上的统计显示,《3周3页面》已经被累计下载了28,861次,实际的读者也将近5,000。而且没有任何的审核流程,也没有排版的时间浪费,我只需要关注内容即可。

Share