Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

不要把复杂的东西变得看起来很简单

  明媚的午后,听到后面一排的小伙子与同伴撕逼的过程中突然冒出一句「不要把复杂的东西变得看起来很简单」,于是我连忙起身跑过去点了个赞。这句话说得太对了!人们总是想把东西变简单,越简单越好,然而变简单之后得到的却是一坨奇怪的东西。
  我觉得,原本复杂的东西就应该是复杂的,「看起来简单」只会造成更大的麻烦。
  有人喜欢使用 getter 和 setter 属性,并且在里面放入很复杂的逻辑。我觉得这就是个坑!给对象的属性赋值是一件看起来简单的事情,如果这件事背后还有很复杂的逻辑存在,那么在使用者不知情的情况下就容易出问题。比如在我看来,属性访问应该是一件时间复杂度 O(1) 的事情,结果却有人把某个属性的访问做成了 O(n) 甚至更高的复杂度,结果使用者在不知情的情况下就很容易出现性能问题。比如一个链表的封装,除非直接储存了长度信息,否则都不应该使用 length 属性来遍历获取长度,应该将这个 API 设计为 getLength 之类的方法才对。
  像 Angular 那么恶心的 digest 机制,实际上就是在把一坨很复杂很恶心的东西变成了一坨看似简单的东西,然后不知情的使用者就很容易掉进坑里。我刚接触 Angular 的时候就很好奇为什么修改 $scope 里面的东西可以自动更新到 UI 上?结果答案是大多数操作都会导致全局比对的触发,整个 Angular 是基于一套这么蠢的机制运行的,虽然看上去很简单。
  以前写 jQuery 的时候也经常踩坑,因为 jQuey 中的所有操作都是方法形式调用的,没看源码或做性能测试的话根本不知道这些方法的时间复杂度。比如 index 方法取元素位置就需要遍历,然而却有很多人会认为这是一个 O(1) 复杂度的方法。其实 jQuery 也只是躺着中枪,原生 JavaScript 的实现中 indexOf 也是 O(n) 的东西,当然这个方法只要学过算法的应该都知道它大概是 O(n) 的,所以它算是坑比较小的。而 shift/unshift 这一对方法就经常会被人们误认为是 O(1) 的,因为链表实现它是 O(1) 的。可实际上在目前的主流浏览器中,这一对方法的复杂度是 O(n)。(虽然 Chrome 里有个 Smart Move 优化,但依然有一些局限性)
  当然也并不是要做到所有方法的实现都把时间复杂度从命名上标出来的程度。如果那样做就变成科学研究了。就像先前的文章中说的 ,工程上确实会放弃一些科学上的逻辑完备性从而提高工作效率。但这也是尺度问题,把握好简单与严谨之间的度才能做出更适合人类使用的东西。
网名:
3.80.32.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^