开发一个产品, 从简单的雏形, 到复杂的系统. 下面从前端说:

1. 一张图;
2. 一个html, 可能里边有点css;
3. html里又加了点js;
4. html变大了, 里面东西越来越多, 于是把css和js抽出来变成单独的文件, 文件从一个变成了三个;
5. 业务逻辑越来越多, 页面元素越来越多, 样式也跟着多, 于是css和js又拆成一堆文件, html可能要include其他的html,可能也要拆.三个文件变成一堆文件;
6. 静态资源多了, 对性能产生影响. 怎么办? 资源压缩吧, 文件合并吧, 雪碧图吧, etc… 该引入自动化构建了吧;
7. js一大堆, 引入顺序一错, 整个页面就有可能挂住, 咋办? 引入模块管理吧;
8. 引入了模块管理, 又不能随便合文件了吧, 咋办? 引入模块管理专用的合并插件吧;
9. 项目大了, 来了新需求, 可能要改代码, 那么现有的功能是不是会受影响? 改完代码得测吧? 哪里会受影响? 自己想么? 万一有没想起来的咋办?得引入单元测试吧;(前端单元测试我还没怎么接触, 好捉急)

为什么要写这篇文章? 昨天用seajs, 引入jquery的时候怎么也引不进来, 不是null就是undefined. 到seajs的官网一查, 是因为seajs内部的一些机制引起的, 模块id和文件路径的问题, 这里不细说了; 有兴趣的看这个帖子

seajs的官网上是这样介绍的:

提供简单、极致的模块化开发体验

简单友好的模块定义规范

自然直观的代码组织方式

但是真的简单吗? 真的直观吗? 作为一个刚接触它的用户, 我觉得这有待商榷. 比如它的demo中, 有这样一个配置

seajs.config({
 base: "../sea-modules/",
 alias: {
   "jquery": "jquery/jquery/1.10.1/jquery.js"
 }
});

一般对前端有了解的, 都会明白, 这里的jquery文件放在了jquery/jquery/1.10.1/这个路径下,那么按照直觉, 如果我把文件移动到 lib/下, 然后将alias改为

“jquery”: “lib/jquery.js”

应该是没问题的吧? 又或者, 我不改文件路径,只改文件名,把jquery.js改成jquery.min.js, 然后修改对应的配置为

“jquery”: “jquery/jquery/1.10.1/jquery.min.js”

这个按照常人的思维, 应该没啥问题吧? 答案是,有问题!

报错!

$ is undefined!

就为了这么点玩意儿, 我研究到半夜一点多. 那么究竟是什么导致的问题呢? 如何解决? 看我上边提到的那个帖子;

所以我就想, 我们引入工具, 是为了把复杂的工作简单化; 可是工具本身又增加了额外的复杂度, 这些复杂度来自工具本身的坑和工具的学习曲线. 为了研究如何使用工具, 我们可能会花费比研发产品本身更多的精力. 那么这到底值不值得呢? 很难说.

比如,原始人打猎, 可能最开始用石头; 后来引入了枪, 为了造枪, 继而引入锻造, 冶炼, 采矿, 运输, 能源, 化工, 自动化加工等等. 驱动这些的原因, 仅仅是使用枪比使用石头简单高效; 找块石头很简单, 用石头猎杀动物不简单; 用枪打猎很简单, 造枪却不简单; 可是如果不引入这些复杂的东西, 我们现在可能还住在山洞里;

同样的道理, 在IT领域也一样, 用户使用的产品越来越简单, 开发工作却越来越复杂; 顶层开发越来越简单, 底层开发越来越复杂;

宇宙里是不是有个复杂度守恒的定律: 一边变简单, 另一边就变复杂;

说到这, 我要说什么都忘了; 话说,又是半夜一点了… …