先说一下我自己的观点，架构其实并没有那么的高大上，前端初学者都可以尝试去理解这个概念，并不是只有架构师才需要涉及。从代码设计，到应用设计再到系统设计，其实处处都是架构。从代码实现和具体业务中抽象出一幅有着各种各样关联性的架构图。

架构思维

架构思维的建立

实际开发经验到一两年之后，应对大部分的业务开发应该问题不大了，这个时候可能就会自然而然的思考，各种组件封装，函数封装等，让自己的代码尽量不那么的’shit’，这个时候其实就开始建立起了代码设计层级的思考了

代码级设计

从各种各样的名词：高内聚、低耦合、健壮性、可读性、复用性、松散性、可维护、可扩展等

从各种各样的设计模式：单例、策略、中介、工厂、发布订阅、观察者等

从各种各样的设计原则：单一原则、最小知识原则、开放封闭原则等

代码层面上的设计除了一系列技术上的各式各样的原则之外，还应包括各种各样的规范，比如变量命名、目录结构、代码提交等。

在cv久了之后，也会思考模块化设计和组件化开发，结合业务去思考模块化开发的临界条件，即什么场景下需要做封装，什么场景下需要解耦，哪些代码可以做封装，这里到底是全局统一封装还是组件内封装。会去考虑代码的各种设计，降低代码的耦合度，提高可复用性。

在进行模块化设计时，按功能拆分成独立的模块，每个模块负责一个特定的功能或者一组相关的功能。

在进行组件化开发时，将UI和业务逻辑划分为独立的组件。需要保证这些组件可以被复用，同时也是仅承担一个特定的功能

同时会生成自己的一套代码规范、目录规范、命名规范、代码提交规范等。

应用级设计

应用级设计涉及整个系统的组织、结构和交互，各个应用是系统架构的进一步功能级的细化，具体的实施细则都是放在各个应用之间实现的，随着系统规模增大，代码复杂度上升。难以扩展和维护，于是便抽离出各种各样的应用设计，如状态管理、路由管理、请求处理、ui组件库等。

需要结合实际开发场景做不同的应用技术选型，就好比我现在开发的后台管理系统一样，它是在vben的基础上进行开发的，选择它的原因有如下几点

  • 功能强大，封装的组件和功能足以满足日常业务开发
  • vben2.10，采用monorepo架构，对于目前规划的项目后续的版本迭代会有所帮助
  • 采用的技术栈最起码两年内不会过时
  • 有着强大的社区生态
  • 当然最重要的一点是，上家公司就是用vben开发的，对它稍微熟悉一点

系统级设计

我理解的系统级设计可能不仅是技术上的一些设计，它可能还囊括团队技术规范、新人培养、 团队成长、前后端联调、git工作流等各种操作。

从业务需求出发，确定系统的整体架构，考虑系统的规模和复杂性。选择合适的前端框架或库。

在项目开发前期，最好是输出各式文档，如代码规范、git规范、项目文档等，这有助于团队成员更容易理解和维护代码。 最好是能Code Review,在大家开发思维和开发经验不一致的情况下，这也许能统一大家的代码风格，同时也能避免程序员们闭门造车。文档的规范力度不一定足够，最好是能加上eslint

在业务开发进入正轨的时候，就可以去对项目的技术和业务进行优化，偿还之前所欠下的技术债了，同时还可以对团队或一些技术方案的设计做一些调整。

日常重复性的业务开发占用了大量时间，导致团队成员没有时间提升自己了。这个时候也可以考虑提升一下团队能力了，技术分享和Code Review都是非常好的方式，