源码使人进步

runtime-only & runtime-with-compiler在用vue-cli构建应用时，一般会让我们做如下选择： Runtime + Compiler：recommended for most usersRuntime-only: about 6KB lighter min+gzip, but templates...其原因是$mount的实现方式在不同平台构建时具有差异性。 compiler的版本和runtime-only版本的差异就在于： runtime-only版本是只包含Vue.js运行时的代码，体积更轻量，通常需要借助vue-loader将.vue文件编译为.js，而compiler版本会在执行的过程中直接预编译。$mountVue.prototype.$mount = function ( el?: string | Element, hydrating?: boolean): Component { el = el && inBrowser ? query(el) : undefined return mountComponent(this, el, hydrating)}$mount方法接收两个参数，一是挂载对象，第二个跟服务器渲染相关，浏览器环境不需要传。其内部实际调用了/src/core/instance/lifecycle里的mountComponent方法: export function mountComponent ( vm: Component, el: ?Element, hydrating?: boolean): Component { vm.$el = el // ... callHook(vm, 'beforeMount') let updateComponent /* istanbul ignore if */ if (process.env.NODE_ENV !== 'production' && config.performance && mark) { // ... } else { updateComponent = () => { vm._update(vm._render(), hydrating) } } new Watcher(vm, updateComponent, noop, { before () { if (vm._isMounted && !vm._isDestroyed) { callHook(vm, 'beforeUpdate') } } }, true /* isRenderWatcher */) hydrating = false if (vm.$vnode == null) { vm._isMounted = true callHook(vm, 'mounted') } return vm}为了看着简洁，此处的源码删除了一些判断逻辑。 ...

作者：谢伟授权 LeanCloud 转载 我叫谢伟，是一名侧重在后端的程序员，进一步定位现阶段是 Web 后台开发。 由于自身智力一般，技术迭代又非常快，为不至于总处于入门水平，经常会尝鲜新技术。 为保持好奇心，日常除技术以外，还会涉猎摄影、演示设计、拍视频、自媒体写作等。 如果此刻我是一个成功人士，看到上面的领域，有人会羡慕说：「斜杠」，遗憾的是，在下没有成功，所以，上面的领域都一定程度上会被人认为：「不务正业」，不过不重要，我本职还是一名后端程序员。 记忆记忆有遗忘曲线，这是大家都懂的道理，所以为了防止忘记，最重要的方法是经常使用、反复使用。这也是为什么，有些人说：在工作中学最容易进步。因为工作的流程、项目不会频繁变动，你会经常性的关注一个或者多个项目进行开发，假以时日，你会越来越熟悉，理所当然，你会越做越快。这个时候，就达到了所谓的：舒适圈。要再想进步，你得跳到「学习区」。再反复这个动作。 问题是，除了工作之外，你很少有其他机会再进行技能锻炼了。 创造机会主动承接更为复杂的任务这个比较容易理解，因为更为复杂的任务，你才可能尝试使用新的技术栈，有机会进行其他技能的锻炼，这样就能进入「学习区」。 如果公司项目就这么点，没有太复杂的，或者说新项目和你接触的相差不多，只不过应用场景不同而已。这个时候，任务如果一定需要你的参与，你最好尝试新的架构，尝试新的技术点，尽管大体相同，可以将你认为原系统不合理的地方改进，这样也能创造机会进入「学习区」。 但就我认为，一般项目开发时间都非常紧，开发人员有可能没有充足的时间进行考虑，会依然使用原有技术点，这样进入学习区的机会就被浪费了，你只是使用一份经验，做了两个类型的项目而已。 旧知识补全刚进入职场，核心位置就那么几个人占着，论经验、论资历，你都不如别人，你接触到的资源有限，没有新项目让你独立开发，只有旧项目的 Bug 让你修复，那该怎么办？ 换坑吗？怕不怕另外一个也是坑？ 补知识体系即使是你能完成的任务，你有没有尝试过自己独立写一个，你有没有尝试过自己弥补下不懂的知识点，你有没有尝试过总结下自己的开发流程是否是最优的，你有没有尝试过总结下项目的技术要点，你有没有尝试过提炼可以复用的技术点... 如果你都没有，恭喜你，你又找到了一个进入「学习区」的点，即：补充原有技术栈。 也许你工作中已经有一门常用编程语言，但都是靠 Google、StackOverFlow，你是不是要尝试梳理下整个编程语言的知识体系，当然梳理的切入点依然是和工作相关为先，因为这最迫切，最能反复，使用频率最高。 也许你对数据库相关知识略懂，对优化数据知识点却不是很懂，你是不是要尝试下找相关资料弥补下。 也许... 也许你还可以翻阅源码，比如内置库的实现，之前我还不太会关注这些，写起代码来不是很有底气，后来经常性的查看源码，借助 IDE 的跳转功能实现对源码的阅读，再结合 IDE 的 structure ，可以对文件的函数、结构体、方法等进行组织。这样从整体观看一目了然，看得多了，你甚至可以总结出一些共性： 比如包的错误处理一般定义在包的顶部几行，而且格式都统一比如 Interface 是方法的集合，内置的常用的 Interface 其实不多，很多内置包都相互实现比如包的结构体，可以实例化一个默认的，这样可以直接调用函数，比如 http.DefaultClient...阅读库的源码，我一般是怎么做的呢？（不要太关注具体的实现，除非你完全能看懂） 官方文档：了解常用使用方法思维导图：输出可导出的结构体、函数、方法等，依然选择最为常用的IDE 的 structure 功能，查看文件的具体组织形式，看可导出的结构体、函数、方法等持续总结举个例子net/http 包几乎奠定了 Go 领域所有 Web 框架、网络请求库的基础。由此来看下我是如何梳理的。 了解 HTTP 相关知识随意找本相关的书，发现是个大块知识啊。结合一般的历史经验，你可能作出这么张思维导图。 整个过程像是：你从一本书总摘出的目录，前提是看过书的内容而得出来的。 net/http 客户端网络请求分为两个层面： 客户端发起网络请求服务端提供网络请求访问资源func getHandle(rawString string) { response, err := http.Get(rawString) if err != nil { return } defer response.Body.Close() content, _ := ioutil.ReadAll(response.Body) fmt.Println(string(content))}看上去发起网络请求很简单，只需要使用 http.Get 即可。 ...