王辉的博客

是什么让我对未知世界始终充满热情?

0%

前一段时间,人告诉我说,我在沟通方面的能力还可以进步。刚听说的时候,还伤感了一下,后来,明白了,就开始找一些可以提升这方面能力的书,
不知道是怎样顺水摸得鱼,糊里糊涂找到了一本很大气的书, How to Win Friends & Influence People, 只看了一下书评,就看到了其中的一条铁律,就是不要和人争吵。

仔细琢摸了一下,发现有的时候我还真是一个不错的辩手。有一次,一个做产品的哥们,问我能不能在某个模块里加一行日志,具体是什么给忘记了,我依然绝然的回绝了。当时的理由是,那条日志是一个底层模块应该写的日志,不能写在高层模块里。
我们争得脸红脖子粗,他说,就一行日志,你加了得了,我怀着对软件设计的崇高敬仰,和对其他程序员高度负责的态度,据理力争,不依不饶。

上面只是一个例子,很多时候,只要是我认定的是对的事情,我很难被人说服,达不成一致的时候,结局往往是争吵。

后来,我开始慢慢体会到不要和人争吵的真正意思所在。那就是聆听,敞开胸怀聆听。有自己的信仰是无可厚非的事情。但因为有信仰就没耐心听完别人的话,就只能说明,嫩,太嫩。首先,我信的东西未必是完完全全对的,争吵我就错过了一个纠正自己看法的机会。
其次,别人的想法也未必就一定和我有冲突,毕竟我听到的可能只是一部分。最后,即便是我真的是对了,人错了,听完想明白后给他发个邮件拯救一下也为时未晚。

不信?试一试,世界仿佛更美了。

今天谈年终总结,说到我在哪些方面还可以再进步的时候,被告知,我要学会控制我的激情。后来我一直在思考这个问题,难道有激情不是一件好事吗?

我当时就有些困惑,不明白我们所谈的激情是什么。详细的问过之后,才发现,原来是有人认为我对技术的热情极高,高到有很多新鲜的事物,看了就想尝试。

我当时的第一反应,是极为委屈的。我纳闷,我什么时候,愣头愣脑的不假思索,不问一二的就埋头做产品了。我的经验中,一向我都是多方面考量之后,才选择一个解决方案,并且明确它局限的地方。
被解释道,说你这个缺点指的是你在实验性的项目中,出手太快,太靠激情引导。我没有完全被这个理由给说服,因为我觉得,既然是实验性的项目,就应该勇于尝试,敢于失败。

可除此之外,确实有的时候,做的不够成熟,出口太快,以致所说的话,条理不清,不能完全让人明白。这一点,即便他们不说,我还是有体会的。记得有一次,我看到了一个关于如何测延迟的文章,为之叫好。结果没有
把概念完全吃透,就给别人说,说这个有多好多好,导致被问到深层次问题的时候,不知如何作答,给人一种只求一知半解的印象。

从上面两方面的角度考虑,我认为,激情是必须得有的,有激情才能有效率,才能更快乐,才能发现新想法。但如果激情过于热烈,而导致身边的同事不舒服的时候,就应该有所节制。毕竟工作生活中,接触的是人,服务的也是人,
人与人之间的交流和关系要处理好。其次,很重要的就是,不要被新鲜的事物,迷惑了双眼,但凡新鲜的想法,都要在脑子里多过几遍,以一种批判的眼光去看待。话不能说太多,一旦开说的时候,一定要有深度,有信服力。

这个节制激情的建议,看似有些令人匪夷所思,但抱着一种一日三省吾身的态度,去看,确实能够找到,自己能进步的地方。

只要功夫深,铁杵磨成针。在钻了好几个晚上和周末后,我没曾放弃过的布朗运动终于动起来了。怀着喜悦的心情,
给大家伙讲讲我看到的,学到的关于优先队列这个数据结构,ES6编程,和Canvas动画的事。

演示

原理

这个系统模拟的是小球在一个有限的空间里完全弹性碰撞的情况。上面的演示中大小不一的小球一共500个。实现这个系统有三个核心模块:

  • 基础模块:两个小球之间的碰撞预测和碰撞后的响应解析
  • 统筹模块:管理所有小球之间的碰撞顺序,以及任意两个小球碰撞后对系统的更新
  • 动画模块:动态的描绘系统的状态

其中基础模块用到的是物理力学和矢量的知识,统筹模块靠的是优先级队列的数据结构,HTML Canvas帮助做动画。

动机

做这个程序,主要有两个企图。

  1. 想切身感受一下优先队列这个数据结构的美妙。这个想法是在看完了Coursera上的算法课之后有的,毕竟一下高效的模拟这么多小球的相互碰撞不是一件容易的事。
  2. 学习一下ES6这个编程语言。之前一直抗拒尝试ES6,是担心用到写不出优美的代码。后来看到最新的ES6,支持了模块,类,箭头函数等让大家期待已久的特性,手有点痒痒,决定试一下。

做完之后,别的先不提,单是把它真真切切,活生生的跑起来,就让我高兴了好几天,这便是程序员的最大的好处,创造东西有成就感。除此之外,收获还是蛮多的,下面稍微详细的侃侃从不同角度对ES6,和它周遭的生态系统的粗浅看法。

好的

到处都是Javascript

Javascript吸引我的最大的一个原因,就是我可以把它给部署到任何一台有浏览器的电脑,分享给成千上万的人。这就是Web的魅力。这个程序完全可以用Java,Scala或者其他语言写,
但想分享给其他人,其他人必须得先安装JDK,然后再下载我这个程序,再运行,才能看见点什么。
Web的话,点一个网址即可。并且我软件的升级对网友来说是完全透明的,他看到的永远是最新的版本。

模块化

在我看来,模块化的支持将把Javascript的有效打击范围再推向一个更广阔的阶段。因为模块化是构建复杂系统最重要的工具。从我这四五年做软件开发的经验来看,模块化有很重要的意义。

大事化小,小事化了

大事化小,是毫无疑问的,小事化了,就是在谈理想了。模块化的这个好处,是从我们人类认识世界的角度来出发的。一个人在认识复杂事物的时候,不可能一下就抓住它的全部,而是先从一些容易理解的比较基础的地方开始,然后一点一点积累出来,最后看到全貌。
举个简单地例子,让你算个
12*5+(24/6 + 16)/2.5 - 2
等于多少,你不可能一下就知道结果,而是先把这个复杂的算式,分解分解,弄成最基本的加减乘除,然后一步一步得到最后的结果。

做软件是同样地道理。把复杂的系统,分割成稍微简单地子模块,依次往下走,子模块做好了,大的系统才可能见得天日。这一点和任何开发语言都没有关系。甚至和编程本身都没有关系,因为它是我们认识,发现世界的基本方法。

你变你的,别影响到我就行

这是模块化带来的第二个非常关键的好处,隔离变化所造成的影响。在软件这个领域里,我们最喜欢的是变化,最害怕的也是变化。为什么爱得也是它,恨的也是它?

爱它使因为它带来的是效益,有变化说明客户有新的需求,需求越多,变化越多。恨它,是因为变化不好控制,一不小心,就造出了Bug,并且有时候都不知道,为什么改了东墙,却倒了西墙。

模块化所扮演的角色,就是隔离,一个模块内部的变化,一定要内部消化,不管你怎么消化,别影响到别的模块就好。就像我上面分的模块,动画模块和基础模块是隔离的,小球怎么撞那是基础模块的事,不管怎么撞,动画模块画球的方式都不会受到影响。

拿来用用

吃别人嚼过的馍馍没味,但用别人已经做好的模块就很爽,因为这能给你节省时间和精力,让你专注于别人没有而你独有的东西。这是我认识到的模块化,激活的第三个非常关键的特点。
我的这个模块里,直接用到的别人做好的模块是优先级队列这个数据结构,在es-collesions里。我用得没有预期中的那么顺利,因为它由Bug,就像所有的拿来主义一样,要持有敢怀疑的态度。我是最后才怀疑的它,最后证明Bug就在他那里,我给他修了

生态系统

这里我所谓的生态系统,是指的在Javascript这个语言周围的一些辅助开发的工具。

Atom

Atom是Github的一款文档编辑器,用Javascript/Coffeescript写的,但它早已超越了文档编辑器的范畴。琳琅满目的插件,多种多样的功能
完全可以使它成为一个开发的整合环境,你所需要的代码补齐,代码高亮,搜索替换,git,vim等等很多工具都可以在里边找到相应地插件。唯一不足的是,
缺少调试功能。

Webpack

我查得第一个工具就是构建工具,稍微一查,真是有点被吓到。构建工具太多了,虽说百家齐鸣是好事,但多了也麻烦,这就牵扯到标准方面的事情。大概看了一下,最老牌的是Grunt,相当于Java里地Maven,推崇的是Convention over Configuration,我很喜欢这种方式
,大家都用同样地东西,学了一样工具,就到处都可以用。比较新的有Gulp,我说它比较像Java里的Gradle和SBT,Code as Configuration,配置文件本身也是代码,它省了不少配置的复杂度,也很有吸引力。

可最终我选择了,配置最简单,支持ES6最快捷,注重模块化的Webpack。几行配置文件就搞定了ES6的支持,并且自动生成一个Bundle整合文件,HTML只需要导入这个文件即可。很快就可以上手。它最有吸引力的是它关于Code Splitting的关注,可我后来意识到这里所说的
Code Splitting更像是Java 9里谈到的自动加载独立模块的概念,在我的项目里没用到。稍微细说一点,就是你有很多模块,当一个用户用你的应用的时候,未必一下子需要把这些模块都加载进去,提取给他有用的那些部分模块就好,简单地说是为了减少代码的下载量。

测试驱动

测试驱动,在使用像Javascript这样的松类型的开发语言的时候,所扮演的角色就更重要了。松类型的一个弱点就是不能在编译阶段找错,所以我们犯错误的概率就更大一点,所以早测试就尤为的重要了。
Webpack里有测试的Plugin,但是都是基于浏览器的。由于我的基础模块,和统筹模块都不操作DOM,完全可以脱离浏览器独立的测,所以我就选用了Mocha的单元测试,和Babel编译器相结合,单元测试非常快。试了一下Karma,是和浏览器结合的,太慢了。

Animation with Canvas

最后,说一说动画模块,一个简单地函数window.requestAnimationFrame,就天衣无缝的把网友计算机的屏幕刷新机制和代码联系了起来,
这真的让人叹服。我觉得这是Web的另一大魅力,几乎所有我们能想象到的应用都可以用Web的技术来实现,WebSQL, WebSocket, WebComponent…

可改进的

松类型(loose typing)

松类型是有好处,因为它给了你更多地灵活性。我在基础模块了就用到了这一点。可以和小球碰撞的物体有两种,一个是小球和小球撞,另外一个就是墙和小球撞。我在球和墙的代码里,都写了一个撞小球的方法,它们不用继承同一个父类,我可以直接把他们放到同一个集合里,
然后调用它们共同的方法和小球撞。这在Java,Scala或者Haskell这些强类型的语言里是不可能实现的。

但它也有它的缺点,首当其冲的是,松类型不利于在编译阶段发现错误,这个弱点可以用单元测试来弥补。但最让我头疼的是,一个函数所传达的信息是不完整地,它只告诉了你它接受什么参数,而不告诉你要返回什么。这对代码的可读性是一个非常大得影响。我想一个可能的
改善的方法,是把函数的名字,起的更详细完整一些,在函数的名字里,告诉别人它要返回的是什么。

下一步

Webstorm IDE

Intellij在Java中的体现是有目共睹的,相信WebStorm也可以做的很好。Webstorm相对于Atom,对我的吸引力体现在它对调试的支持上,
也许我应该写更多的单元测试,彻底地省去调试的需求。

JSHint

我看了两个Douglas Crockford的演讲,一个是比较老一点的JavaScript: The Good Parts,
另一个是新一点的The Better Parts,他都提到了如何用JSHint帮助我
们避免Javascript里地一些陷阱,只用它好的部分。

尾部递归

另外一个我没有提到的ES6的新功能便是对尾部递归的优化,这么一来,我就完完全全没有必要在代码里使用循环了。