往蹇来誉 田获三狐
学习历程
2022-4-30
4月30日前主要是找视频和资源。之前算刚开始一天。
先找视频，
主要目的是熟悉umi，尤其是umi的用法
这次的策略是，
先了解umi，了解如何使用 umi，
然后再看源码；
具体实施是
先看视频，但不留恋太多时间在视频上，
然后快速切入 umi官网；
然后看源码；
行动方针：
抓住重点，放下细节，列举备忘。
umi 学的是架构，不要学细节；
就算想学细节，
也可以将最想学，以及最需要学的架构学完;
再来 完善细节，
可以将细节列举出来回头看：
thunk 与saga 的区别；
generator yield ；
saga 不要细学，它只是一个工具，知道用就行
刷了一个用法视频，大概一个小时；
马上进入 手写 umi 源码 视频；
然后网络搜索 相关 umi 源码 解析的系列教程；
准备看后，去看官网；
要学的是umi的主体框架
而不是很多系列的 业务实现， 比如动态路由等等，这些不是关注的重点，
但可以列举出来 感觉公司会用得到的点，以后可以学习下；
这次主要学习的是umi的一整套
umi工程的架包管理思想；
脚手架开发思路；
插件化思路；
微内核的实现；
包括也不需要太苛求完美知道umi的各种用法？
这几天做一些比较难点攻坚的问题；
因为这样的时光太难得了；
一位辕友的话：
知识才是一个程序员最虔诚的信仰。
策略：
先打快，然后以观后效，决定快慢；
umi 看完后，
就 做一些 ui的二次业务封装框架npm包；
以及脚手架的npm包；
以及平常简单的工具包；
以及 类似 umi 的很多个包的管理；
重要插件：
access
antd
dva
initail-state
layout
locale
model
qiankun
request
2022-5-3
对之前umi学习过程的一个小结：
- 之前 刷了 一个umi的用法视频，dva的视频也了解了下， 主要给自己留了一点umi的使用印象，
感觉收获不是很大，但可能也是必须要经历的吧，
从找以上视频资料到看完，
大概花了 6个小时左右； - 接着看了 云谦 的 umi 2019介绍的视频 2022年umi 4 的介绍视频，这过程大概花了3个小时， 感觉收获还不错，对umi有了更直观认识；
umi 与 webpack babel 其框架思路都是一致的 都是微内核方式， 如果之前看过 webpack 或babel源码，
看umi 就会感觉似曾相识 或相互借鉴， - 接着刷了 umi 官网 ，按照文档 配置 api 指南 插件 顺序 ，全部刷了一遍 大概花了 6个小时；
这个过程还是加深对umi框架的更多认识，或者有一个系统性的全貌认识，以便更好的看源码；
其实很多时候，官网是针对源码进行更详细的一层解释说明。
等待阅读完源码后，还会再回头看umi官网；
下一步 准备 找源码解读的教程看，然后直接拷贝源码进行阅读。
这一次不是针对umi源码的阅读，其实是一次 基建系统地理论学习 以及实战运用。
可能耗时需要三个月，因为 umi是核心，其他的有 father build， learn 等等；
一些包开发的习惯 等等；
就算是这三个月，估计也是要有的放矢，抓住重点，放弃一切不必要的深究，才能有一个好的收获
不要太抠细节，
要吸收作者的模式、架构思路、方案思路；
2022-5-4
这次阅读不要太纠缠细节，一定要快。
快速读完后，有疑问或有兴趣 再快速读一次。
而不是 抠细节 慢慢读，这样有好处，但是不适合目前实际的情况：
- 目前的心态是想早点知道全貌
- 读源码慢慢读，显得枯燥，激励性不够，很容易放弃，如果不扣细节快速读，读自己非常感兴趣的，就激起兴趣和好奇心，（兴趣是最大老师）就容易坚持
- 读源码是庞杂而枯燥 或易忘的，只有快而多次的循环车轮战的方式 去咬合比较好。
- 另外一个多遍快速的方式，每次在阅读时会有新的思考，也会产生新的兴趣，然后再去读，激励性更好，也会最终读很多细节（读细节不是目的）
关注以下几点： - 阅读源码方法
- 调试源码方法与demo
- 微内核原理
- 框架的包管理方式（如发包管理，版本号管理）
- 框架项目的脚手架具体细节实现方式(如webpack babel编译方式)
- 框架项目的脚手架具体细节实现方式(其他细节 如 ts、eslint 等等)
- 框架项目的 ci\cd 实现
- 框架的文档建设
- 框架核心业务能力的实现原理
- 框架主要或感兴趣插件的实现原理
2022-5-5
昨天花了 4个小时 看了 源码解读系列文档；
今天正式进入 umi使用 以及源码调试；
然后看umi 4 如何使用，创建项目；
然后才是 调试源码；
当前遇到一个瓶颈，不知道如何高效 阅读umi源码：
第一对使用umi不熟悉；
第二对启动umi源码或调试也不熟悉；
不知如何下手才最合理或高效，
不管怎样，下一步，
先学会如何使用umi吧。
这应该是必经的一个阶段。
学会使用了，知道umi的魅力，
可能更加有触动去学习umi源码。
了解umi的魅力后，
就调试源码，
接着就是umi源码一整套开发的知识体系学习，如昨天总结的。
【关于如何使用 umi，
就对着官网的demo示例来吧，
或者对着 umi源码的 example 里面的示例来？
拿起 umi官网，对着 使用来】
实际的操作是： 对着官网 把demo跑起来，
然后跟着源码解读，umi | 1. umi 命令
然后 跑起来的 demo上进行断点，
在运行的过程中，会熟悉整个 umi 源码的情况，也知道了 之前意想不到的 一些源码情况，
这种操作还是挺好的，后期就按这个方式 debug，
遇到问题，就查， 断点调试到一定程度 再考虑下一步。
还是要之前的策略，一定要快，一定不要纠缠，一定不要纠缠不必要了解的细节，抓住自己这次为什么学习 umi源码 最想了解的事情。
2022-5-6
感觉debug umi源码 要了解的太多，或者不知道要了解什么，找不到目标：
可以这样突破：
- 比如 如何配置umi webpack5 ，然后看umi 内部如何实现；
- 比如 看umi的路由如何实现；
- umi 的插件如何实现；
- umi 的npm包管理 的完整系列体系是如何设计的；
- umi 的脚手架（含基建） 如何设置的
通过上述一个个问题，来更多了解umi，
以及通过解决上述问题的时候，产生更多有意义 有兴趣的问题，然后再去解决这些问题；
因此 等umi熟悉个差不多的时候，就立马动手 解决以上我的疑惑或感兴趣的问题或我学umi之前原先要了解的问题。
2022-5-9
umi 的阅读 效率差；
不知道学啥，感觉没什么可学，感觉啥都要学；
只能打乱仗了；
缺点是 相关的介绍文章太少了，
因为是v4 版本的，与v3版本差异性比较多；
而且umi的这种设计 确实感觉是一味地快，而丢失了可读性 和 可维护性；
有点画蛇添足了
真得 这个快影响大吗，
我觉得 快到一定程度，再快对你的开发提升效率不大；
就好像 从0提高到80 是性价比最高的
从 80-到90 很多人不需要；
2022-5-10
在解决需求难点中，认识umi 认识umi插件，比一直坚持阅读 umi插件 文档 的方式更加有效率：
当前 连插件 如何使用 比如 如何注册 如何使用插件的api 注册命令 等等 都不是很清楚；
但是跟着 一个个上面列出的需求，一个个去了解，
逐渐知道了插件的使用方法；
还是这种方法好，了解需求本身就是 查看插件的实现，也附带着了解了 插件的使用方法；
这种效率比直接 去阅读插件的官网文档要好点，
2022-5-15
感想
时至今日，还未有一个非常有效率的方法，如何吃下umi，
umi太大了，要了解的东西很多，不知道从哪里入手，
感觉不能有捷径或偷懒的想法，
还得一步一个脚印的来，
但一步一个脚印来，又显得枯燥，
没有了兴趣，何谈持续性，
因此就找自己最感兴趣的，一步步来,
目前就是最刚兴趣，整个umi 脚手架，
比如 包管理、脚手架配置 等等。
那就先从这个入手吧。
2022-5-18
umi 太庞大了；
要想全学，耗时太长，
又因为没有实际项目做支持，恐怕很难坚持；
umi其实最重要的是 那一套思想 原理 以及umi项目的脚手架工具；
所以先从外围打起，
先学所有的 umi 外围的 脚手架 npm script 工具是对的；
后期主要学习umi，能看懂其源码，灵活使用umi，或者拿其源码修改；
至于 ant-design-pro 那些，没必要学习， 什么tab 什么面包屑，
这些都是业务逻辑实现，不会很难；
到最后，有空 可以学学
现在感觉 学习 umi 貌似 也没什么用，
也感觉 前端也没什么，再学是不是也无意义？？
学深了，感觉学多了，没有意义？？
有点想放弃umi的学习；
感觉东西 太多，太难，今天调试一个 mfsh ，太难了。
2022-5-20
感觉学习 大框架，本来是效率低，但收益高，的一件事情，
不能求快，
可能要大量使用车轮战，
笨办法
2022-5-24
阅读一个大型框架，
做笔记的时候，应该应该有一个文档 专门列举 配置 对应的源码位置；
而且要专门一个文档，这样 方便后期查询，而且可以提效阅读；
2022-5-25
.umi 下 每个目录是如何生成的；如core ，对应的是 umi 的哪些插件生成的，要做一个记录；
plugin-terminal 是如何生成的；
md 文档的 loader 是依靠什么插件生成的；
下一步具体到 文档的各个文件是怎么生成的；
然后总结做个笔记
有其他扩展的 再研究
反正以文档这个项目作为 umi的切入口，学习umi相关的知识；
2022-5-26
关于文档博客的选用：
api文档与博客的区别是
前者针对 目录进行搜索即可；
后者最好要针对内容进行搜索；
二者的核心需求 决定了使用何种模式的文档框架比较合适；
其实一个文档，除了直观展示内容外，
另外最大的功能就是 如何让你的内容更容易被你搜索到，
因为只有能被搜索到的东西，才会是有用的
除此之外，ui框架博客，还要兼顾，在线查看code，看效果，以及 浏览器 code 文件 等功能，
因此最好选用 dumi。
2022-6-7 重读umi
感觉 umi 的学习瓶颈，一是核心知识比如 mfsu 也没有了解透；
另外一个对 umi 貌似也没了解太透；
索性 重读一遍 umi；
从 umi 的文档 开始，再次重读；
要记住当前的目标或学习umi的目标：
通过umi系统学习前端脚手架能力；
自己创建一套 库，一遍锻炼 npm 发布 library库和 ui组件库的经验；
以及 ts 的编译原理；
重新捋一遍 学习umi的重点：
还是要回到正题来：
不要去学什么 mfsu；
要学习 umi 的微内核；
要学习 umi 插件原理；
以及umi 项目的 脚手架：编译、npm包管理、npm包版本管理发布 等等；
mfsu、esbuild 其实都属于拓展学习，将来不一定会用得上；
而上述说的东西，却是实实在在用得上的，而且要马上用到的；
以及ts的编译原理；
其他值得一学的东西一览：
umi的max 是一套蚂蚁集团内的项目脚手架最佳实践
包含了 状态管理dva、 国际化、多语言 等等方案；
重写umi
这是第一步：
- 如果能直接将umi改成任意其他名字，也是非常棒的第一步；
- 用删除法来复制粘贴umi项目，重写项目最稳妥；
- 去掉不必要的一些编译，做一个精简版本的umi;
- 能精简umi，其实也是对umi了解非常深厚了
2022-6-8 今天开始重写copy umi
- 直接 copy 然后换名字，发布的原因在于：
- 过程中读 umi 认识一步加深；
- 熟悉了 它整个 脚手架 发包、包管理、lint 功能
这也是下一阶段的目标。
2022-6-9
没有对umi深入的了解，直接copy 替换名字 发布版本是很难的，
必须要对umi有深入的了解后，才可以做这件事情。
所以这个顺序要注意，也可以指导以后阅读其他大型组件库。
2022-6-12
到今天，umi的源码阅读、umi重写改造成 magicbird 完成，从4月30 到今天 6月12，中间有半个月间断，差不多一个月。
此过程几次到达要过早结束或放弃的关头，
好在每到关键时候，都能调整策略，保持了兴趣，
此过程中 大框架阅读不要急，敢于不怕效率低 以及中间的各种策略选择，
包括后期的 重写umi的决定，以及如何重写的策略选择 这些点非常好。