为啥不用 node

@Oceanhime 不加是全局变量，加了是作用域变量。你说的成员变量 js 并没有，要实现也是用 this 实现的。

无意识加工

@whoisghost @impl
前东家，目前在广州待过最爽的公司。每天 8 小时。氛围不错。

@geelaw 浏览器自己可以完成虚拟化是什么意思？这个不是长列表常见的优化吗？

跟它一样好又比它更便宜就已经够秒杀它了

# 怎么对经理说
“该怎么跟经理说重构的事？”这是我最常被问到的一个问题。毋庸讳言，我见过一些场合，“重构”被视为一个脏词——经理（和客户）认为重构要么是在弥补过去犯下的错误，要么是不增加价值的无用功。如果团队又计划了几周时间专门做重构，情况就更糟糕了。如果他们做的其实还不是重构，而是不加小心的结构调整，然后又对代码库造成了破坏，那可就真是糟透了。
如果这位经理懂技术，能理解“设计耐久性假说”，那么向他说明重构的意义应该不会很困难。这样的经理应该会鼓励日常的重构，并主动寻找团队日常重构做得不够的征兆。虽然“团队做了太多重构”的情况确实也发生过，但比起做得不够要罕见得多了。
当然，很多经理和客户不具备这样的技术意识，他们不理解代码库的健康对生产率的影响。这样的情况下我会给团队一个较有争议的建议：不要告诉经理！
这是在搞破坏吗？我不这样想。软件开发者都是专业人士。我们的工作就是尽可能快速创造出高效软件。而我的经验告诉我，对于快速创造软件，重构可带来巨大帮助。如果需要添加新功能，而原本设计又使我无法方便的修改，我发现先重构再添加新功能会更快些。如果要修补错误，就得先理解软件的工作方式，而我发现重构是理解软件的最快方式。受进度驱动的经理要我尽可能快速完成任务，至于怎么完成，那就是我的事了。我领这份工资，是因为我擅长快速实现新功能。我认为最快的方式就是重构，所以我就重构。

—— 摘录自《重构-第 2 版》第 2 章 ”重构的原则“

真的很用心 : )

支持一下。出书不容易啊。