
1.5
模块化
JavaScript
的必要性
|
15
万象的架构有可能会为我们省去很多麻烦,但是这样的设计可能要花大量
时间预先思考与准备,并且可能会让我们卡在一系列难以保持同步的抽象
中,短期内也没有可预见的收益。在没有数据表明流量即将出现爆发式增
长的情况下,专注于解决当下或即将遇到的问题,比去预估可能到来的爆
发式流量增长而为其设计对应的基础设施要好得多。
当我们不用这种长期模式做规划时,就会发生一件有趣的事情 :我们的系
统更加自然地发展,能适应近期的需求,并逐渐向支持更大的应用程序和
更多的需求发展。当这个过程渐进地进行时,我们会注意到,随着系统的
成长,各种抽象会以一种正确的方式被提取出来或被丢弃。如果过早地去
做抽象,最终会发现这些抽象都是错误的抽象,而且我们将为这些错误付
出代价。糟糕的抽象会迫使整个应用程序顺从它的意愿。当意识到这个抽
象很糟糕,应该被移除时,我们可能已经对它投入了大量的精力,以至于
从其中撤出需要很大的代价。这一点再加上“沉没成本(
sunk cost
)”谬 论( 即
因为在这个抽象上花费了大量的时间和心血,我们往往会试图保留它),的
确是很危险的。
本书的一个重要内容就是,帮助读者理解如何在正确的时间识别和利用正
确的抽象,将承担的风险降到最低。
1.5
模块化
JavaScript
的必要性
由于历史原因,
JavaScript
在模块化设计方面的做法特别有意思。在早期的
Web
开发中,很长一段时间内
JavaScript
的使用没有什么章法,很多人对
这门语言的了解仅限于显示错误的报警框