675d5d27jw1f3bnbao1dbj20z80jujyu

游戏 |《奥利与黑暗森林》

07 | 07 | 2017

希望是光芒,爱把它点亮。

奥利与黑暗森林》是博主今年在steam夏促上买的一款游戏,游戏发行时间是2015年,steam原价¥68,半价折扣。

QQ20170707-160700

目前博主已经通关了,耗时12小时17分24秒,死亡523次 ((٩(//̀Д/́/)۶)),steam排名13万,没有什么值得骄傲😂

QQ截图20170707153735

剧情概要

故事发生在一片叫做Nibel的森林,森林中有个守护神,“灵魂树”。灵魂树孕育了很多精灵。

9daf5144f0689d96d27ac7f46bec9da5

一天夜里,暴风雨吹走了灵魂树的孩子Ori,Ori被一只黑暗生物Naru认养(博主刚开始以为这货是公的,看体型不像是母的啊喂),快乐地生活。

9daf5144f0689d96d27ac7f46bec9da5副本9daf5144f0689d96d27ac7f46bec9da5副本19daf5144f0689d96d27ac7f46bec9da5副本2

灵魂树派其他孩子寻找Ori,但是损兵折将,不得已之下放了个大招,黑夜中照亮天空,召唤Ori。Ori看到了光,但不明白是什么意思。

9daf5144f0689d96d27ac7f46bec9da5副本3

从那以后,森林渐渐枯萎,Naru找寻食物受伤,当Ori抱着食物回到Naru身边发现她再也醒不过来。(这里被虐的不要不要的,老夫的少女心啊)

9daf5144f0689d96d27ac7f46bec9da5副本49daf5144f0689d96d27ac7f46bec9da5副本6

 

孤单的Ori独自踏上流浪的道路,当希望失去方向,世界以沉寂回应哭泣,生命之火渐渐消散;疲惫的Ori终于忍受不住沉沉是睡去,精灵树用最后的法力复活了Ori,新的故事就这样开始了。

接下来游戏正式开始,Ori为了使森林恢复原貌踏上了寻找真相的路,后面就不剧透了,游民星空上有免安装版的链接(咳咳,请大家支持正版),B站也有这个游戏的视频攻略,大家如果感兴趣可以切身感受下这个游戏。

附上游戏的原声音乐辑,同学们自己感受下吧

5532f9_5792712

2017-Steam夏季促销

05 | 07 | 2017

steam的夏季促销结束了,亲们你们的钱包还好么。反正up主的状态是这样的

df1bef58ly1fgv88x6q2og205004rkct

好心塞有木有,明明知道是个坑还是往面跳

93e30d0828381f301fc0bf14ae014c086c06f0fa

好吧,其实我也是今年刚玩steam,还算是个新手玩家呢,总共才31款游戏(大多是今年夏促买的)

QQ截图20170705221602

感兴趣的小伙伴们要不加个好友先

前端组件化开发方案及其在React Native中的运用

02 | 07 | 2017

随着SPA,前后端分离的技术架构在业界越来越流行,前端(注:本文中的前端泛指所有的用户可接触的界面,包括桌面,移动端)需要管理的内容,承担的职责也越来越多。再加上移动互联网的火爆,及其带动的Mobile First风潮,各大公司也开始在前端投入更多的资源。这一切,使得业界对前端开发方案的思考上多了很多,以React框架为代表推动的组件化开发方案就是目前业界比较认可的方案,本文将和大家一起探讨一下组件化开发方案能给我们带来什么,以及如何在React Native项目的运用组件化开发方案

一、为什么要采用组件化开发方案?

在讲怎么做之前,需要先看看为什么前端要采用组件化开发方案,作为一名程序员和咨询师,我清楚地知道凡是抛开问题谈方案都是耍流氓。那么在面对随着业务规模的增加,更多的业务功能推向前端,以及随之而来的开发团队扩张时,前端开发会遇到些什么样的问题呢?

1. 前端开发面临的问题

(1)资源冗余:页面变得越来越多,页面的交互变得越来越复杂。在这种情况下,有些团队成员会根据功能写自己的CSS、JS,这会产生大量的新的CSS或JS文件,而这些文件中可能出现大量的重复逻辑;有些团队成员则会重用别人的逻辑,但是由于逻辑拆分的粒度差异,可能会为了依赖某个JS中的一个函数,需要加载整个模块,或者为了使用某个CSS中的部分样式依赖整个CSS文件,这导致了大量的资源冗余。

(2)依赖关系不直观:当修改一个JS函数,或者某个CSS属性时,很多时候只能靠人力全局搜索来判断影响范围,这种做法不但慢,而且很容易出错。

(3)项目的灵活性和可维护性差:因为项目中的交叉依赖太多,当出现技术方案变化时,无法做到渐进式的、有节奏地替换掉老的代码,只能一次性替换掉所有老代码,这极大地提升了技术方案升级的成本和风险。

(4)新人进组上手难度大:新人进入项目后,需要了解整个项目的背景、技术栈等,才能或者说才敢开始工作。这在小项目中也许不是问题,但是在大型项目中,尤其是人员流动比较频繁的项目,则会对项目进度产生非常大的影响。

(5)团队协同度不高:用户流程上页面间的依赖(比方说一个页面强依赖前一个页面的工作结果),以及技术方案上的一些相互依赖(比方说某个文件只能由某个团队修改)会导致无法发挥一个团队的全部效能,部分成员会出现等待空窗期,浪费团队效率。

(6) 测试难度大:整个项目中的逻辑拆分不清晰,过多且杂乱的相互依赖都显著拉升了自动化测试的难度。

(7) 沟通反馈慢:业务的要求,UX的设计都需要等到开发人员写完代码,整个项目编译部署后才能看到实际的效果,这个反馈周期太长,并且未来的任何一个小修改又需要重复这一整个流程。

2.组件化开发带来的好处

组件化开发的核心是“业务的归业务,组件的归组件”。即组件是一个个独立存在的模块,它需要具备如下的特征:

  • 职责单一而清晰:开发人员可以很容易了解该组件提供的能力。
  • 资源高内聚: 组件资源内部高内聚,组件资源完全由自身加载控制。
  • 作用域独立: 内部结构密封,不与全局或其他组件产生影响。
  • 接口规范化: 组件接口有统一规范。
  • 可相互组合: 组装整合成复杂组件,高阶组件等。
  • 独立清晰的生命周期管理:组件的加载、渲染、更新必须有清晰的、可控的路径。

而业务就是通过组合这一堆组件完成User Journey。下一节中,会详细描述采用组件化开发方案的团队是如何运作的。

在项目中分清楚组件和业务的关系,把系统的构建架构在组件化思想上可以:

(1) 降低整个系统的耦合度:在保持接口不变的情况下,我们可以把当前组件替换成不同的组件实现业务功能升级,比如把一个搜索框,换成一个日历组件。

(2) 提高可维护性:由于每个组件的职责单一,在系统中更容易被复用,所以对某个职责的修改只需要修改一处,就可获得系统的整体升级。独立的,小的组件代码的更易理解,维护起来也更容易。

(3) 降低上手难度:新成员只需要理解接口和职责即可开发组件代码,在不断的开发过程中再进一步理解和学习项目知识。另外,由于代码的影响范围仅限于组件内部,对项目的风险控制也非常有帮助,不会因为一次修改导致雪崩效应,影响整个团队的工作。

(4) 提升团队协同开发效率:通过对组件的拆分粒度控制来合理分配团队成员任务,让团队中每个人都能发挥所长,维护对应的组件,最大化团队开发效率。

(5) 便于自动化测试:由于组件除了接口外,完全是自治王国,甚至概念上,可以把组件当成一个函数,输入对应着输出,这让自动化测试变得简单。

(6) 更容易的自文档化:在组件之上,可以采用Living Style Guide的方式为项目的所有UI组件建立一个‘活’的文档,这个文档还可以成为业务,开发,UX之间的沟通桥梁。这是对‘代码即文档’的另一种诠释,巧妙的解决了程序员不爱写文档的问题。

(7) 方便调试:由于整个系统是通过组件组合起来的,在出现问题的时候,可以用排除法直接移除组件,或者根据报错的组件快速定位问题。另外,Living Style Guide除了作为沟通工具,还可以作为调试工具,帮助开发者调试UI组件。

二、组件化开发方案下,团队如何运作?

前面大致讲了下组件化开发可以给项目带来的好处,接下来聊一聊采用组件化开发方案的团队是应该如何运作?

在ThoughtWorks,我们把一个项目的生命周期分为如下几个阶段:

组件化开发方案主要关注的是在迭代开发阶段的对团队效率的提升。 它主要从以下几个方面提升了开发效率:

1. 以架构层的组件复用降低工作量

在大型应用的后端开发中,为了分工、复用和可维护性,在架构层面将应用抽象为多个相对独立的模块的思想和方法都已经非常成熟和深入人心了。但是在前端开发中,模块化的思想还是比较传统,开发者还是只有在需考虑复用时才会将某一部分做成组件,再加上当开发人员专注在不同界面开发上时,对于该界面上哪些部分可以重用缺乏关注,导致在多个界面上重复开发相同的UI功能,这不仅拉升了整个项目的工作量,还增加了项目后续的修改和维护成本。

在组件化开发方案下,团队在交付开始阶段就需要从架构层面对应用的UI进行模块化,团队会一起把需求分析阶段产生的原型中的每一个UI页面抽象为一颗组件树,UI页面自己本身上也是一个组件。如下图:

通过上面的抽象之后,我们会发现大量的组件可以在多个UI界面上复用,而考虑到在前端项目中,构建各个UI界面占了80%以上的工作量,这样的抽象显著降低了项目的工作量,同时对后续的修改和维护也会大有裨益。

在这样的架构模式下,团队的运作方式就需要相应的发生改变:

(1) 工程化方面的支持,从目录结构的划分上对开发人员进行组件化思维的强调,区分基础组件,业务组件,页面组件的位置,职责,以及相互之间的依赖关系。

(2) 工作优先级的安排,在敏捷团队中,我们强调的是交付业务价值。而业务是由页面组件串联而成,在组件化的架构模式下,必然是先完成组件开发,再串联业务。所以在做迭代计划时,需要对团队开发组件的任务和串联业务的任务做一个清晰的优先级安排,以保证团队对业务价值的交付节奏。

2.以组件的规范性保障项目设计的统一性

在前端开发中,因为CSS的灵活性,对于相同的UI要求(比如:布局上的靠右边框5个像素),就可能有上十种的CSS写法,开发人员的背景,经历的不同,很可能会选择不同的实现方法;甚至还有一些不成熟的项目,存在需求方直接给一个PDF文件的用户流程图界面,不给PSD的情况,所有的设计元素需要开发人员从图片中抓取,这更是会使得项目的样式写的五花八门。因为同样的UI设计在项目中存在多种写法,会导致很多问题,第一就是设计上可能存在不一致的情况;第二是UI设计发生修改时,出现需要多种修改方案的成本,甚至出现漏改某个样式导致bug的问题。

在组件化开发方案下,项目设计的统一性被上拉到组件层,由组件的统一性来保障。其实本来所有的业务UI设计就是组件为单位的,设计师不会说我要“黄色”,他们说得是我要“黄色的按钮……”。是开发者在实现过程中把UI设计下放到CSS样式上的,相比一个个,一组组的CSS属性,组件的整体性和可理解性都会更高。再加上组件的资源高内聚特性,在组件上对样式进行调整也会变得容易,其影响范围也更可控。

在组件化开发方案下,为了保证UI设计的一致性,团队的运作需要:

  1. 定义基础设计元素,包括色号、字体、字号等,由UX决定所有的基础设计元素。
  2. 所有具体的UI组件设计必须通过这些基础设计元素组合而成,如果当前的基础设计元素不能满足需求,则需要和UX一起讨论增加基础设计元素。
  3. UI组件的验收需要UX参与。

3. 以组件的独立性和自治性提升团队协同效率

在前端开发时,存在一个典型的场景就是某个功能界面,距离启动界面有多个层级,按照传统开发方式,需要按照页面一页一页的开发,当前一个页面开发未完成时,无法开始下一个页面的开发,导致团队工作的并发度不够。另外,在团队中,开发人员的能力各有所长,而页面依赖降低了整个项目在任务安排上的灵活性,让我们无法按照团队成员的经验,强项来合理安排工作。这两项对团队协同度的影响最终会拉低团队的整体效率。

在组件化开发方案下,强调业务任务和组件任务的分离和协同。组件任务具有很强的独立性和自治性,即在接口定义清楚的情况下,完全可以抛开上下文进行开发。这类任务对外无任何依赖,再加上组件的职责单一性,其功能也很容易被开发者理解。所以在安排任务上,组件任务可以非常灵活。而业务任务只需关注自己依赖的组件是否已经完成,一旦完成就马上进入Ready For Dev状态,以最高优先级等待下一位开发人员选取。

在组件化开发方案下,为了提升团队协同效率,团队的运作需要:

(1)把业务任务和组件任务拆开,组件的归组件,业务的归业务。

(2)使用Jira,Mingle等团队管理工具管理好业务任务对组件任务的依赖,让团队可以容易地了解到每个业务价值的实现需要的完成的任务。

(3) Tech Lead需要加深对团队每个成员的了解,清楚的知道他们各自的强项,作为安排任务时的参考。

(4) 业务优先原则,一旦业务任务依赖的所有组件任务完成,业务任务马上进入最高优先级,团队以交付业务价值为最高优先级。

(5)组件任务先于业务任务完成,未纳入业务流程前,团队需要Living Style Guide之类的工具帮助验收组件任务。

4.以组件的Living Style Guide平台降低团队沟通成本

在前端开发时,经常存在这样的沟通场景:

  • 开发人员和UX验证页面设计时,因为一些细微的差异对UI进行反复的小修改。
  • 开发人员和业务人员验证界面流程时,因为一些特别的需求对UI进行反复的小修改。
  • 开发人员想复用另一个组件,寻找该组件的开发人员了解该组件的设计和职责
  • 开发人员和QA一起验证某个公用组件改动对多个界面上的影响

当这样的沟通出现在上一小节的提到的场景,即组件出现在距离启动界面有多个层级的界面时,按照传统开发方式,UX和开发需要多次点击,有时甚至需要输入一些数据,最后才能到达想要的功能界面。没有或者无法搭建一个直观的平台满足这些需求,就会导致每一次的沟通改动就伴随着一次重复走的,很长的路径。使得团队的沟通成本激增,极大的降低了开发效率。

在组件化开发方案下, 因为组件的独立性,构建Living Style Guide平台变得非常简单,目前社区已经有了很多工具支持构建Living Style Guide平台(比如getstorybook:https://getstorybook.io),开发人员把组件以Demo的形式添加到Living Style Guide平台就行了,然后所有与UI组件的相关的沟通都以该平台为中心进行,因为开发对组件的修改会马上体现在平台上,再加上平台对组件的组织形式让所有人都可以很直接的访问到任何需要的组件,这样,UX和业务人员有任何要求,开发人员都可以快速修改,共同在平台上验证,这种“所见即所得”的沟通方式节省去了大量的沟通成本。此外,该平台自带组件文档功能,团队成员可以从该平台上看到所有组件的UI,接口,降低了人员变动导致的组件上下文知识缺失,同时也降低了开发者之间对于组件的沟通需求。

想要获得这些好处,团队的运作需要:

(1) 项目初期就搭建好Living Style Guide平台。

(2) 开发人员在完成组件之后必须添加Demo到平台,甚至根据该组件需要适应的场景,多添加几个Demo。这样一眼就可以看出不同场景下,该组件的样子。

(3) UX,业务人员通过平台验收组件,甚至可以在平台通过修改组件Props,探索性的测试在一些极端场景下组件的反应。

5. 对需求分析阶段的诉求和产品演进阶段的帮助

虽然需求分析阶段产品演进阶段不是组件化开发关注的重点,但是组件化开发的实施效果却和这两个阶段有关系,组件化方案需要需求分析阶段能够给出清晰的Domain数据结构,基础设计元素和界面原型,它们是组件化开发的基础。而对于产品演进阶段,组件化开发提供的两个重要特性则大大降低了产品演进的风险:

  • 低耦合的架构,让开发者清楚的知道自己的修改影响范围,降低演进风险。开发团队只需要根据新需求完成新的组件,或者替换掉已有组件就可以完成产品演进。
  • Living Style Guide的自文档能力,让你能够很容易的获得现有组件代码的信息,降低人员流动产生的上下文缺失对产品演进的风险。

三、组件化开发方案在React Native项目中的实施

前面已经详细讨论了为什么和如何做组件化开发方案,接下来,就以一个React Native项目为例,从代码级别看看组件化方案的实施。

1. 定义基础设计元素

在前面我们已经提到过,需求分析阶段需要产出基本的设计元素,在前端开发人员开始写代码之前需要把这部分基础设计元素添加到代码中。在React Native中,所有的CSS属性都被封装到了JS代码中,所以在React Native项目开发中,不再需要LESS,SCSS之类的动态样式语言,而且你可以使用JS语言的一切特性来帮助你组合样式,所以我们可以创建一个theme.js存放所有的基础设计元素,如果基础设计元素很多,也可以拆分位多个文件存放。

然后,在写具体UI组件的styles,只需要引入该文件,按照JS的规则复用这些样式属性即可。

2.拆分组件树之Component,Page,Scene

在实现业务流程前,需要对项目的原型UI进行分解和分类,在React Native项目中,我把UI组件分为了四种类型:

  • Shared Component: 基础组件,Button,Label之类的大部分其它组件都会用到的基础组件
  • Feature Component: 业务组件,对应到某个业务流程的子组件,但其不对应路由, 他们通过各种组合形成了Pag组件。
  • Page: 与路由对应的Container组件,主要功能就是组合子组件,所有Page组件最好名字都以Page结尾,便于区分。
  • Scene: 应用状态和UI之间的连接器,严格意义上它不算UI组件,主要作用就是把应用的状态和Page组件绑定上,所有的Scene组件以Scene后缀结尾。

Component和Page组件都是Pure Component,只接收props,然后展示UI,响应事件。Component的Props由Page组件传递给它,Page组件的Props则是由Scene组件绑定过去。下面我们就以如下的这个页面为例来看看这几类组件各自的职责范围:

(1)searchResultRowItem.js

(2)SearchResultsPage.js

(3)SearchResultsScene.js

3.Living Style Guide

目前社区上,最好的支持React Native的Living Style Guide工具是getstorybook,关于如何使用getstorybook搭建React Native的Living Style Guide平台可以参见官方文档(https://github.com/kadirahq/react-native-storybook)或者我的博客(http://www.jianshu.com/p/36cbd8393288)。

搭建好Living Style Guide平台后,就可以看到如下的界面:

接下来的工作就是不断在往该平台添加UI组件的Demo。向storybook中添加Demo非常简单,下面就是一个关于SearchPage的Demo:

从上面的代码可以看出,只需要简单的三步就可以完成一个UI组件的Demo:

(1)import要做Demo的UI组件。

(2) storiesOf定义了一个组件目录。

(3) add添加Demo。

在构建项目的storybook时,一些可以帮助我们更有效的开发Demo小Tips:

(1)尽可能的把目录结构与源代码结构保持一致。

(2) 一个UI组件对应一个Demo文件,保持Demo代码的独立性和灵活性,可以为一个组件添加多个Demo,这样一眼就可以看到多个场景下的Demo状态。

(3) Demo命名以UI组件名加上Demo缀。

(4) 在组件参数复杂的场景下,可以单独提供一个fakeData的目录用于存放重用的UI组件Props数据。

4.一个完整的业务开发流程

在完成了上面三个步骤后,一个完整的React Native业务开发流程可简单分为如下几步:

(1)使用基础设计元素构建基础组件,通过Living Style Guide验收。

(2)使用基础组件组合业务组件,通过Living Style Guide验收。

(3)使用业务组件组合Page组件,通过Living Style Guide验收。

(4)使用Scene把Page组件的和应用的状态关联起来。

(5)使用Router把多个Scene串联起来,完成业务流程。

四、总结

随着前后端分离架构成为主流,越来越多的业务逻辑被推向前端,再加上用户对于体验的更高要求,前端的复杂性在一步一步的拔高。对前端复杂性的管理就显得越来越重要了。经过前端的各种框架,工具的推动,在前端工程化实践方面我们已经迈进了很多。而组件化开发就是笔者觉得其中比较好的一个方向,因为它不仅关注了当前的项目交付,还指导了团队的运作,帮助了后期的演进,甚至在程序员最讨厌的写文档的方面也给出了一个巧妙的解法。希望对该方法感兴趣的同学一起研究,改进。

转自:前端之巅

CHROME开发者工具的小技巧

20 | 04 | 2017

Chrome的开发者工具是个很强大的东西,相信程序员们都不会陌生,不过有些小功能可能并不为大众所知,所以,写下这篇文章罗列一下可能你所不知道的功能,有的功能可能会比较实用,有的则不一定,也欢迎大家补充交流。

话不多话,我们开始。

代码格式化

有很多css/js的代码都会被 minify 掉,你可以点击代码窗口左下角的那个 { }  标签,chrome会帮你给格式化掉。

强制DOM状态

有些HTML的DOM是有状态的,比如<a> 标签,其会有 active,hover, focus,visited这些状态,有时候,我们的CSS会来定关不同状态的样式,在分析网页查看网页上DOM的CSS样式时,我们可以点击CSS样式上的 :hov 这个小按钮来强制这个DOM的状态。

 

 

动画

现在的网页上都会有一些动画效果。在Chrome的开发者工具中,通过右上角的菜单中的 More Tools => Animations 呼出相关的选项卡。于是你就可以慢动作播放动画了(可以点选 25%10%),然后,Chrome还可以帮你把动画录下来,你可以拉动动再画的过程,甚至可以做一些简单的修改。

 

直接编辑网页

在你的 console 里 输入下面的命令:

1
document.designMode = "on"

于是你就可以直接修改网页上的内容了。

P.S. 下面这个抓屏中还演示了一个如何清空console的示例。你可以输入 clear() 或是 按 Ctrl+L(Windows下),CMD + K (Mac下)

 

网络限速

你可以设置你的网络的访问速度来模拟一个网络很慢的情况。

 

复制HTTP请求

这个是我很喜欢 的一个功能,你可以在 network选项卡里,点击 XHR 过滤相关的Ajax请求,然后在相关的请求上点鼠标右键,在菜单中选择: Copy => Copy as cURL,然后就可以到你的命令行下去 执行 curl 的命令了。这个可以很容易做一些自动化的测试。

 

友情提示:这个操作有可能会把你的个人隐私信息复制出去,比如你个人登录后的cookie。

抓个带手机的图

这个可能有点无聊了,不过我觉得挺有意思的。

在device显示中,先选择一个手机,然后在右上角选 Show Device Frame,然后你就看到手机的样子了,然后再到那个菜中中选 Capture snapshot,就可以抓下一个有手机样子的截图了。

我抓的图如下(当然,不是所有的手机都有frame的)

 

设置断点

除了给Javascript的源代码上设置断点调试,你还可以:

给DOM设置断点

选中一个DOM,然后在右键菜单中选 Break on … 你可以看到如下三个选项:

给XHR和Event Lisener设置断点

在 Sources 面页中,你可以看到右边的那堆break points中,除了上面我们说的给DOM设置断点,你还可以给XHR和Event Listener设置断点,载图如下:

关于Console中的技巧

DOM操作
  • chrome会帮你buffer 5个你查看过的DOM对象,你可以直接在Console中用 $0, $1, $2, $3, $4来访问。
  • 你还可以使用像jQuery那样的语法来获得DOM对象,如:$("#mydiv")
  • 你还可使用 $$(".class") 来选择所有满足条件的DOM对象。
  • 你可以使用 getEventListeners($("selector")) 来查看某个DOM对象上的事件(如下图所示)。

  • 你还可以使用 monitorEvents($("selector")) 来监控相关的事件。比如:
1
monitorEvents(document.body, "click");

Console中的一些函数

1)monitor函数

使用 monitor函数来监控一函数,如下面的示例

2)copy函数

copy函数可以把一个变量的值copy到剪贴板上。

3)inspect函数

inspect函数可以让你控制台跳到你需要查看的对象上。如:

更多的函数请参数官方文档 – Using the Console / Command Line Reference

Console的输出

我们知道,除了console.log之外,还有console.debugconsole.infoconsole.warnconsole.error这些不同级别的输出。另外一个鲜为人知的功能是,console.log中,你还可以对输出的文本加上css的样式,如下所示:

1
console.log("%c左耳朵", "font-size:90px;color:#888")

于是,你可以定义一些相关的log函数,如:

1
2
3
4
5
6
console.todo = function( msg){
  console.log( '%c%s %s %s', 'font-size:20px; color:yellow; background-color: blue;', '--', msg, '--');
}
console.important = function( msg){
  console.log( '%c%s %s %s', 'font-size:20px; color:brown; font-weight: bold; text-decoration: underline;', '--', msg, '--');
}

关于console.log中的格式化,你可以参看如下表格:

指示符 输出
%s 格式化输出一个字符串变量。
%i or %d 格式化输出一个整型变量的值。
%f 格式化输出一个浮点数变量的值。
%o 格式化输出一个DOM对象。
%O 格式化输出一个Javascript对象。
%c 为后面的字符串加上CSS样式

 

除了console.log打印js的数组,你还可以使用console.table来打印,如下所示:

1
2
3
4
5
6
7
var pets = [
  { animal: 'Horse', name: 'Pony', age: 23 },
  { animal: 'Dog', name: 'Snoopy', age: 13 },
  { animal: 'Cat', name: 'Tom', age: 18 },
  { animal: 'Mouse', name: 'Jerry', age: 12}
];
console.table(pets)

 

关于console对象

  • console对象除了上面的打日志的功能,其还有很多功能,比如:
  • console.trace() 可以打出js的函数调用栈
  • console.time() 和 console.timeEnd() 可以帮你计算一段代码间消耗的时间。
  • console.profile() 和 console.profileEnd() 可以让你查看CPU的消耗。
  • console.count() 可以让你看到相同的日志当前被打印的次数。
  • console.assert(expression, object) 可以让你assert一个表达式

这些东西都可以看看Google的Console API的文档

其实,还有很多东西,你可以参看Google的官方文档 – Chrome DevTools

关于快捷键

点击在 DevTools的右上角的那三个坚排的小点,你会看到一个菜单,点选 Shortcuts,你就可以看到所有的快捷键了

如果你知道更多,也欢迎补充!

转自:酷 壳 

e98534b3331ebfc70a25

2016年崛起的JS项目

17 | 04 | 2017

近几年 JS 社区创新和演化的速度是有目共睹的,几个月前比较时髦的技术很可能现在已经过时了。2016 已经过去,你有没有担心错过了什么重要的内容?在这篇调查报告中我们会为你解读社区的主流趋势。

我们将从数量上来分析哪些项目 2016 年获得比较多的关注,具体的做法是比较各项目 2016 年在 Github 上新增 star 的数量。

回顾 2015 年:React 无疑占据了统治地位,而 Redux 则在众多牛毛的 Flux 实现中脱颖而出。那么 2016 年哪些项目最受开发者关注呢?

目录

  1. 最受欢迎项目
  2. 前端框架
  3. Node.js 框架
  4. React 项目模板
  5. 移动开发
  6. 编译工具
  7. 构建工具
  8. 测试框架
  9. IDE
  10. 静态网站生成器

1. 最受欢迎项目

仔细观察 2016 年排名前 10 的项目,你就能对 WEB 社区的演化方向有个直观的把握,概括如下:

 

上面这些项目覆盖的领域,无疑证明了 JS 的通用性,印证了那句话:能被 JS 编写的,迟早都会被 JS 编写

2016 年的最佳项目是… 🏆

Vue.JS 2016 年新增超过 25000 个 star,意味着平均每天新增 72 个 star,超过了所有同类项目的流行速度,比如 React 和 Angular。 采用 Virtual DOM 来增强性能的 Vue.JS v2 于 2016 年 10 月发布。

Vue.JS 已经被不少大公司用在了生产环境中,比如中国最大的电子商务网站里巴巴,所以你可以将 Vue.JS 作为一个安全的选择。

围绕着 Vue.JS 的社区生态也日趋成熟,包括路由库(vue-router)和状态管理库(Vuex)。 Vue.JS 兼具了 ReactAngular 1 两者的优点,其中 React 的基本思想是组件式开发,而 Angular 1 是模板增强。

2. 前端框架

前端框架的百花齐放也许是出现 JS 疲劳 的原因所在,新的框架、工具和库层出不穷,把创新的车轮推向前进。

概括来讲,前端框架可以分为两大类:

  • 大而全的框架,包括创建现代 WEB 应用的所有功能特性,比如路由、数据获取、状态管理,典型项目有:Angular 1Angular 2EmberAurelia
  • 小而美、聚焦在 UI 层面的解决方案,典型项目有 ReactVue.JSInferno

前文中我们已经探讨了排名第 1 的项目 Vue.JS,下面来看看其他竞争者:

React 及其竞争者

React 排名第 2,所有开发者都知道 React 有着庞大的社区和完整的生态系统。

React 设计思想非常流行,受 React 启发而诞生了大量类 React 项目,这些项目继承 React 优点的同时有非常大的改进,比如各种能提高性能和缩短构建时间的瘦身版本。

Inferno 在类 React 项目中是最受欢迎的,它自己则标榜是所有竞争者中性能最快的。

Preact 也是一个非常不错的选择,它也有不错的生态,比如各种脚手架、路由,甚至还有一个 compact 模块让任何能在 React 环境运行的库在 Preact 中运行。

 

Angular 1 和 Angular 2

Angular 项目已经被拆分成两个仓库,因为 Angular 2 几乎是 Angular 1 的全面重写,虽然两者在部分概念上是相同的。

Angular 2 全部用 TypeScript 编写,这样它利用 ES6 语法特性提供了现代的、全面的 WEB 框架。

Angular 1 (在 Github 上称作 “AngularJS”) 目前仍然被大量的项目使用,目测会持续流行一段时间。

此外,不得不提的 Ember, 虽然社区和生态都很大,但是没有排到前 10 名。

整体来看,相比于那些开箱即用的大而全的框架,开发者更青睐自己组合使用那些小而美的轻量级解决方案,因为这样给了他们更大的自由度。

3. Node.js 框架

2016 年创建和部署 Node.js 应用变得空前的容易,比如下面这些解决方案:

类似于 Gomix 的项目则把 Node.js 的门槛降到不能再低,只要通过浏览器简单的点击拖拽就都能轻而易举的编写分享 Node.js 代码。

那么,如果想创建一个 WEB 应用,我们该选哪个框架呢?

Express

Express 已经成为开发 Node.js WEB 应用的标准框架,大多数工程师都很熟悉他的设计思想(极简的内核,但能让你用各种中间件来扩展他的功能)。

Koa

Koa,设计思想非常类似 Express,区别在于它是使用 ES6 中的 generator 编写的,这种写法解决了大家所熟知的回调地狱 问题。

Feathers

Feathers,是用来实现面向服务架构的一种灵活的解决方案,非常适合创建 Node.js 微服务。

Nodal

Nodal,用来创建基于 PostgreSQL 的无状态的、分布式的服务。

Keystone

Keystone,是我所知的快速搭建基于 MongoDB 的管理后台的最佳解决方案,Keystone.js 基于数据模型的定义即可自动生成后台界面,支持常见的增删改查操作和灵活的数据过滤。

Sails

Sails,是一个全能的 MVC 框架,主要是受到 Ruby on Rails 启发,他已经存在很长时间,支持各种数据库,不管是 SQL 还是 No-SQL。

Loopback

Loopback,内置了很多特性的成熟框架,支持基于 token 的认证,支持各种数据库。 Loopback 的“杀手锏”功能是 API 浏览器,该功能能让开发者用非常直观的方式查看所有的 API 接口,如果你需要创建 API 服务的话,它无疑是个很好的选择。

4. React 项目模板

React 是非常棒的 UI 库,但是基于现代 WEB 应用开发工作流创建 React 应用时仍然需要大量的配置才能把所有的部分拼凑到一起,如何创建一个“真实”的 React 应用呢?各种 React 项目模板(boilerplates)和启动工具箱(starter kits)就是来解决这个问题的,典型的有下面几个:

Create React App

Facebook 开源的,轻量级的解决方案,使用 Create React App 创建 React 应用非常的简单。Create React App 的作者 Dan Abramov (也是 Redux 的作者,目前供职于 Facebook) 在功能丰富和简单可靠之间取得了很好的平衡,没有酷炫的样式解决方案 (仅需纯粹的 CSS) ,没有服务端渲染,但是 React 应用开发的其他方面都浑然一体,开发者体验也非常棒。

相比于同类工具,如果你使用了 Create React App,它会成为你项目的依赖,所有的黑科技都是不可见的,你只能看到你自己的应用代码,你可以随时更新这个依赖。

React boilerplate

React boilerplate 则包含了 React 应用所需的一切,包括 Redux 以及基于 Web Worker 实现的离线功能。使用它可以创建“渐进式 Web 应用”(亦称“PWA”),如果想了解更多 PWA 的知识,可以阅读 Nicolás Bevacqua 的 这篇文章

Next.js

Next.js, 由来自 Zeit 的 busy folks 创建,支持服务端渲染,可以用来创建 universal 应用(或者“同构应用”),直白点说,这种应用的前后端可以运行相同的代码。

5. 移动开发

JS 的通用性是毋庸置疑的,现如今可以用 WEB 工程师非常熟悉的技术(HTML、JS、CSS)构建 Native 移动应用。下面是几个典型的解决方案:

React Native

使用 React Native,可以用类似于 React 思路,用同一份代码构建出支持 iOS 和 Android 平台的、真正的 Native 应用,想了解如何构建跨平台的更多内容?建议阅读这篇教程。

其他基于 Cordova 的方案多使用 Webview 来渲染页面,相比于 Native 应用运行时性能会大打折扣,不过,开发者那种 “Write Once Run Everywhere” 的梦想终于成真了!

Ionic

Ionic 是 “hybird” 应用开发领域的先锋,底层基于 Cordova 来访问移动设备的系统功能,社区和生态系统非常成熟。

NativeScript

NativeScriptReact Native 的目标是相同的,即基于 WEB 技术构建 Native 应用,其核心分为两部分:NativeScript 内核,NativeScript + Angular 2。

展望未来…

Weex 是 2017 年需要密切留意的项目,他是基于 Vue.JS 的、用来创建跨平台移动应用的框架。

6. 编译工具

我们这里讨论的是把其他语言或者 JS 变体编译(Compiler)或转换成(Transpiler)标准 JS 代码的工具,这些工具生产出来的代码可以在浏览器或者 Node.js 环境中执行。

最常见的场景是,这类编译工具能够让开发者使用 ES6 语法编写代码,而不用担心浏览器支持情况。

TypeScript

最具潜力的编译工具可能是 TypeScript 了,它为 JS 带来了类似于 Java 和 C# 的静态类型,而 Angular 2 完全使用 TypeScript 的事实让他看起来更诱人,当然关于在 JS 使用静态类型的讨论有很多,建议阅读下面这两篇文章来做出自己的决定:

Babel

Babel + webpack 已经成了 ES6 代码转换、React 模板编译的标准工具组合,Babel 最初是用来编译 ES6 的,但得益于他的插件系统,如今俨然已经演化成一个用途广泛,几乎能实现各种代码转换的工具。

 

Flow

Flow 并不是一个编译工具,它只是一个基于 JS 代码标记的静态类型检查工具,也就是说,使用 Flow 时需要在代码中添加各种注释来注明需要的数据类型,关于 Flow 的使用,可以阅读这篇文章

Flow 在很多 Facebook 项目的源代码中都有使用,而 Facebook 已经成为开源社区的重要玩家,开源了 ReactReact NativeFluxImmutableJest 等众多的项目,相信你明白这意味着什么。

CoffeeScript

CoffeeScript 的简洁语法大量借鉴了 Python 和 Ruby 的语言特性,过去几年曾经是最受欢迎的编译器,但 2016 年很多开发者从 CoffeeScript 转向了 ES6 + Babel 组合。

 

7. 构建工具

2016 年“构建过程”似乎成了 WEB 项目的标配,如果一个 WEB 应用没有构建过程则是难以想象的事情,在构建过程中通常你需要做编译模板、静态资源合并压缩之类的事情,以为生产环境做好准备。

Webpack

Webpack 是构建单页应用(SPA)的主要工具,它和 React 生态结合的非常好,最新发布的 Webpack 2 带来了不少非常有前景的改进,具体可以阅读这里

Gulp

Gulp 是一个通用的任务运行工具,可以在任何和文件系统打交道的自动化流程中使用,可以认为它并不是 WebpackBrowserify 的直接竞争者。

Grunt 类似,Gulp 的主要角色是任务管理,你可以让它压缩合并代码,但是它不会帮你处理 JS 模块化问题,而 WebpackBrowserify 是可以的。

当然了,Gulp 可以和 Webpack 结合起来使用,即使开发者倾向于使用 npm script 也是可以的,实际上很多开发者就是这么做的。

Browserify

Browserify 因为非常简单,在 Node.js 工程师群体中比较受欢迎。简单来说,它把多个 Node.js 的包作为输入,然后输出单个编译后的文件。相比而言,Webpack 在 WEB 应用打包方面考量更多,更适合现代的 WEB 开发工作流。

展望未来…

2017 年需要留意的模块打包工具是 rollup,它强调的是性能,基于 ES6 的模块规范,并且支持 Tree Shaking 这种黑科技,构建产生的结果只包含实际业务逻辑用到的代码,而不是简单的文件合并。

8. 测试框架

相比于流行了很久的测试框架 JasmineMocha,2016 年出现了 2 个更新的、并有很多人使用的测试框架:AVAJest

AVA

AVA 由非常高产的 Sindre Sorhus 开发和维护,其标榜的重点是性能和 ES6,能够并行的运行测试。AVA 的语法非常类似 TapeNode-tap

Jest

Jest,又一个 Facebook 开源项目,最近几个月引起了大量的开发者注意,在 React 社区更加流行,并且越来越多的人开始迁移到 Jest,可以阅读这个故事,2017 年 Jest 极有可能成为最受欢迎的测试框架。

Jest 内置了非常强大的 Mock 特性,而其他的测试框架通常需要依赖第三方的 Mock 包,比如 Sinon.JS

9. IDE

说到 IDE(集成开发环境,Integrated Development Environment),令人振奋的是最受欢迎的 2 款 IDE 都是用 WEB 技术开发的开源项目。

Visual Studio Code

微软的 Visual Studio Code 在 WEB 开发者群体中非常受欢迎,因为他提供了非常棒的 TypeScript 和 Node.js 集成,部分开发者甚至特别提到 Visual Studio Code 的智能感知功能极大的提高了开发效率。现在把微软和开源放在一起,终于不那么违和了

Atom

Atom 由 Github 开源,使用 Electron 构建,在受欢迎程度上并没有落后 Visual Studio Code 太多,关于 Atom 的一个有趣事实是,他所使用的主要语言是 CoffeeScript。

10. 静态网站生成器

静态网站生成器(SSG)是指能够生成一大坨 HTML、CSS、JS 文件方便你快速部署到简单的 WEB 服务器上而不用安装和配置数据库的工具。就像 Gatsby 所标榜的:

像 1995 年那样构建网站。

静态网站的特点是速度快、健壮行高、容易维护。

静态网站如此流行的重要原因是市面上有很多非常好用并且免费的静态网站托管解决方案,比如:

Hexo

2016 年最流行的静态网站生成工具是 Hexo,他有点类似于 Workdpress 这样的 CMS 系统,可以用来方便的创建博客网站,他还有很多其他的特性,比如国际化插件。

Gatsby

新玩家 Gatsby 是一个比较有趣的解决方案,相比于竞争者优秀的地方在于:它使用 React 生态系统来生成静态文件,可以组合 React Component、Markdown 和服务端渲染来完成静态网站生成让他更强大。

 

总结和展望

虽然 2016 年出现了“JS 疲劳”,也发生了戏剧性的事件(如 “leftpad 门”),但总体来讲 2016 年对 JS 社区来说是非常重要的一年,部分项目在 2016 年崛起,如 Vue.JSReact Native,还有些黑马项目 2016 年诞生,如 YarnCreate React App

我们谈论了 2016 年 Github 上最受瞩目的开源项目,但是真正重要的是开发者的满意度,如果你想就这个话题有更量化的认识,建议去看看 Sacha Greif 的调查 State of JavaScript,该调查收集了超过 9000 份问卷。

接下来该思考 2017 年了,哪些将会持续获得开发者的青睐?哪些会成为新星呢?下面是我精选的 10 个我 2016 年比较欣赏,并且 2017 年会继续保持增长的项目或创意:

  • Vue.JS:还在快速增长阶段
  • Electron
  • Create React App
  • React Native
  • Gatsby (你浏览的这个页面就是用它来构建的)
  • Yarn:快速、可靠并且安全的依赖管理工具,可以直接替代 npm,建议阅读文章 yarn vs npm
  • PWA(Progressive Web Applications)渐进式 WEB 应用
  • Node.js 微服务的一站式部署和运行解决方案,比如 Now
  • Node.js 的进化:最新版本对 ES6 语法的支持已经非常好了
  • 最后是 GraphQL:我身边不少朋友说这会是一个大的进步

感谢你花时间阅读本文,可以尽情把本文分享出去,有疑问可以到 Github 上发起 Issue 或直接联系我们。

下一页