前端架构：从入门到微前端

架构做什么？很多人第一次看到这个词都会有疑问，甚至做过几年开发之后，仍然会问“需要架构师么？” 某种程度上，架构师的界限是模糊的，它需要先是开发者，然后是架构师，它必须懂，且要比普通开发者懂得更多。 架构是“粗、细”兼备的事情，粗的层面，整个团队的人员构成、技术栈分布、成员间的合作机制、开发及发布节奏等，细的层面，代码编写规范、管理规范、组件库、工具选择、文档的整理和维护、性能监测和优化等。总的来说，是需要具备丰富且完整经验的人才能够胜任。 那么“微前端”又是什么概念？简单说，技术编程从来都是在经历“分分合合”，要么分拆，要么聚合，都是为了更好地管理和维护代码，过去常说的模块化和组件化多是代码层面，而微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单体应用转变为把多个小型前端应用聚合为一的应用。各个前端应用可以独立开发、独立部署。 它可能带来三个方面的收益：应用自治、单一职责、技术栈无关。 你可能觉得这些并没有给你的项目造成困扰，那么其实采用微前端架构的另一个重要理由是“遗留系统迁移”，比如过去编写的单页面应用，已经在线上稳定运行了，也没有新的功能。对于这样的应用来说，没有理由浪费时间和精力去重写，而这些应用是使用旧的、不再使用的技术栈编写的，框架本身已经不更新，既然应用可以使用，就不用花太多的力气重写，而是直接整合到新的应用中去。 最后，回到架构这件事上，架构跟项目密切相关，而项目又跟业务密切相关，所以从来都无定论，需要开发者根据自己的情况去选择实施。

二零一九年读完的第八十二本书，断断续续读了差不多半个月，终于在从广州去深圳的高铁上完结了。这本书是从比较宏观的角度来看待前端这个东西，对于有一定前端工作经验的人比较有用，如果没有一定的工作经验去看反而会觉得虚。总得来说还是值得一看的。

在我们的职业生涯里，维护应用的时间远远长于启动一个新的应用。当我们觉得启动应用更有挑战的时候，是因为维护应用的时间太长。在经历多个项目之后，笔者才明白维护一个系统有多难，如何让一个我们觉得“烂”的系统慢慢变好？旧的系统给我们带来一系列深入的思考，我们会思考平时哪里做得不好，应该怎么做才能让系统变得更好？如果能不断地在新旧系统之间切换，那么我们就能理解好的架构的意义，好的设计的初衷。并且，只有经历过遗留系统，才能让自己真正地成长。

之前买的实体书，十一花了几天读了一下。总体来看内容还是比较散并且比较 theoretical，理论名词太多。前半部分大部分内容其实也可称为前端工程化实践，只有第九、十章的微前端实现想法还是比较有意思的。不过所有的微服务化理论，无论是前端还是后端都只有借鉴意义而已，所谓的 trade-off 衡量要小心过犹不及。BTW，“如果能不断地在新旧系统之间切换，那么我们就能理解好架构的意义”这句话十分赞同。

这本书讲了前端的整体开发流程，结合作者的开发经历，着重讲了微前端的应用，颇有启发。

花了50多币，不到3个小时开完。 我觉得这本书适合工作3-5年，经历过多个项目或前端leader看看；对于经历多项目，多框架，多语言开发的人员说，这本书会带你总结一下，跳出细节和具体技术，从宏观角度重新审视一下经历遇到的问题和解决方法。对于管理人员，书里提到的一些方法和工具可以参考，特别是经验的提炼、模式的应用。这本书到时带我回顾了一下前端的发展历史，记得最初的html、Css，js、servlet输出 以及ajax的异步通讯请求；jquery等等到如今各种组件、模块、框架；开发形式方式都在改变，同时要求也在改变，大前端、自适应；甚至是0代码。这样以来以怎样的粒度、耦合度解决相关行业的问题，就尤其重要了。

不能归为教程，也不大适合作为传授知识的书，可定性为一本关于作者经验总结与分享的书。 读完感受就是看得太细反而并未有许多获益。总的来说作者对前端的架构涉及到的总结介绍的很全面，适合作为参考，更像是把前端所有菜式都摆弄了出来，如何选择取舍则丢给了读者去思考。可以从思维上获取不少认同和指南。这点上也不得不佩服作者知识面的广泛。

看完了第二遍。并且想推荐给我的前端朋友们都看看。重塑了我架构概念的一本书。写代码的本应该就能从全局去看业务，到细节里写代码。所以还是认为解耦业务的能力最重要了。能扒开顶层业务做好基础架构后面的程序员会感激很多年。

远程办公这两周的下班时间断断续续看完的，书的后半部分还是值得一读的，最近刚好遇到了一个新的架构上的问题，目前还没有想出聪明的解决方案，能从中得到一些启发，也对自己工作这两年多以来做的很多事情有了更深刻的感悟体会和总结。

前面7章能看懂，后面几章就比较吃力了。前端小白，还还不太适合������这类架构书，以后有机会，再重新理解一遍。