Teobler

在开始聊之前，我想定义一下架构的概念。大部分小伙伴都会问一个问题： “ 前端能有啥架构，不就是文件放

在很长一段时间我并不知道怎么去平衡速率和质量之间的关系，我虽然看过不少书和文章告诉我只有保证质量才能保证速率，但我还没有见过反例，我没办法很好地说服别人，直到我经历和见证了不同项目、不同情况之后...

这篇文章非常长，写这篇文章的初衷是为了沉淀这几年在项目上的一些代码实践，同时也希望能够听听外界的声音，毕竟闭门造车不可取。

前端没法 TDD / 前端不容易做 TDD / 前端 TDD 收益不大。 这是进公司后无数人给我判的“死刑”。 事实上好像的确如此？

不久前一个呆了2年多的项目成功结束，接下来要去一个新项目，新项目要用 Angular，于是我开始告别从毕业就开始用的 React，开始学习这个大家少有提及的框架。

我们的项目整体来看算得上一个比较大型的项目，整个项目规划完成后有 17 条业务线。但是在刚起项目的时候由于种种原因并没有考虑周全，将项目当成一个普通的前端项目来解决，在第一期项目结束，第一条业务上线后

React17那篇没有任何新特性的博客还历历在目，半年多后，终于等来了17铺路许久的18发布计划，本来想赶紧看看都有些啥，无奈事情略多，一直拖到现在，最近有点点时间，看看18给我们带来了什么。

我们需要认识到每一个系统的架构都不应该是一成不变的，为了应对业务的变化，我们不应该只有重写一个选项。 但往往架构的迁移业务方不会给开发者预留充足的时间，短时间内对架构进行平滑迁移就成了需要解决的问题。

从敏捷宣言发布，敏捷如同在雪山顶滚下的一个小雪球，迅速发展并很快席卷了整个软件业。但是如同传话游戏那样，最初的敏捷思想被扭曲和简化，最终到管理者耳朵里变成了是承诺可以更快交付软件的一个流程。 于是浩浩荡荡的敏捷转型开始了，但是一种文化并不容易转型到另一种文化，于是一个岗位出现了…