用来蛮长一段时间的umi，最近也看了一些umi的源码，对于umi模式的好处有以下几点理解：
- 确定的技术选型
- 项目模板定制化
- 切入全开发周期的代码生成
1、对于团队开发来说，确定的技术选型在一定程度上是能够减少同队成员的维护的成本。在react早期，光是状态库就有很多种方案，redux、mobx和其他flux方案层出不穷；路由库选用react router v3或者v4版本？类似的技术选型争论喋喋不休。要是开发人员需要在多个不同选型的项目中切换，光是切换的开销就足够头发。
2、umi-create的模板功能比较强大，能够根据选择生成不同的模板。实际阅读完代码，依赖于 yeoman-generator、inquirer、yargs-parser这三个库就能比较快速的做出一个模板生成器，并且能够快速的增加其他模板的支持。不管是相对通用的模板还是偏向业务的模板，都能够节省不少时间在重复工作上。
3、umi介入到了整个开发流程中，比如mock、测试、开发体验、修改配置自动重新加载、热更新、dll。一些需要新增的通用功能可以做到配置开启，比如多语言、hd、auto-externals，究其原因在于可以做到代码生成。umi和vue-cli其实在功能上有不少相似的地方，但由于代码生成技术，所以相比于vue-cli能够做的事情更多。譬如基于约定去做一些路由的生成，甚至可以直接对接后端的swagger api，自动生成对应的请求函数。
login:
method: POST
url: /login
getUser:
url: /login/{userId}/{info}
import { login, getUser } from "umi-service";
login({ data });
getUser({ userId: "", info: "" });
以上只是举例说明，比较完善的想法是直接配置该项目的后端提供的swagger json api地址，每次启动前检查swagger api是否有更新，有更新则自动生成新的请求函数，并且能够加入ts支持，给出返回格式的类型信息。或者加入运行时类型检查，如果后端返回类型检查失败，直接throw Error，能够从根本上根绝客户端常见的返回值类型不一致的问题。
而umi提供的插件机制和代码生成能够非常便利的实现上述功能，并且能够很好的切入到整个开发流程。
对于前端框架的工程化，基本也是从最开始的（react、vue、angular）框架开始，解决了前端领域的视图、状态管理、路由问题。随之而来vue-cli、create-react-app、angular-cli开始解放生产力，不用重复的创建项目，配置复杂的webpack，通常默认集成了webpack的最优配置。umi在前面两者的基础上更进了一步，代码生成在某种意义上等价于其他语言中的元编程，能够更大的解放生产力。
后续会写一些关于umi源码分析的文章，待续。。。
