前端真的不需要架构能力吗？看完这篇文章你就懂了

前言

不知道各位前端开发者是否面临过这样的苦恼 ：

接盘了一大坨演示类项目，域名20+ 个，每个项目的本身复杂度不高，但是项目数量惊人，项目之间充满了重复性逻辑代码...

突然有一天产品说 在某个项目改下样式，并且相关的都要进行同步... 想必作为前端人都想口吐芬芳了

正文

为了方便理解，下面以图代文，正如所看到的那样，各种各样的域名对应大同小异的 repo, 维护起来简直要命, 作为一位强迫症开发者，对于这种现象是绝对是无法容忍的。 因此把每个项目的 repo 都过了一遍, 发现之间有很多相似的逻辑，包括前端页面的布局、项目的展示方式。最后进行了进一步的分析，本着'求同存异'的思想，进行了汇总。

大概分为两大类项目：

1-1. 纯展示类 1-2. 纯展示类附带简单UI页 2. 定制化类

V1.0

针对上面分好的两类项目，对项目的代码进行了合并并且引入了配置中心，去根据 host 进行相应的配置。 这样说可能不太明白，下面举个例子说明：

const config =  [{
  host: 'host1',
  title: 'xxxx',
  loadingPage: true,
  loadingBgImg: 'xxx',
  loaidngText: '',
  menu: true,
  engine3DType: '',
  menuList: [{
      icon: 'xx',
      title: 'xx',
      data3D： [],
      templateUrl: '',
      modelJson: '',
   }, {
      icon: 'xx',
      title: 'xx',
      data3DUrl: '',
      templateUrl: '',
      modelJson: '',
   }, 
   ...],
  navigator: ture,
  ...
  }, 
...];

const item = checkDev() ? getItem(debugHost) : getItem(window.location.host);

// 页面的相关数据展示/UI展示/3D引擎的选择等，根据配置信息，进行具体控制（为了方便理解 也可以理解为权限控制系统）。

复制代码 

升级之后的形态，如下图所示。

V2.0

进行了整合之后，自己在项目开发过程中 似乎减轻了很大的心智负担，但是大量域名的维护，依旧需要走不同的发布程序，运维同学的心智负担依旧很大， 因此想着能不能沟通一下，让域名共用一个，共用一个jks项目，这样的话开发运维都很和谐。

因此出现了下面的这种图。

摒弃了之前根据host读取配置的形式，改成了根据 pathname 去进行配置的读取，纯前端路由的手法进行实现。（哇，前端工程师真nb.. 笑哭😂）

V3.0

但是到此为止，虽然看似已经解决了某些问题，但是感觉并没有做到最优。以后随着项目的复杂度愈高，复杂的项目数量愈多，我想新的问题会随之而来..

但是作为攻城狮，不就是为了能 “快准狠 ”的 “攻城” 而存在的吗？

结语

其实，在工作中，发现不少的开发者都赖得动脑子去系统化的思考问题，忙于重复性的搬砖而忙的不亦乐乎，慢慢丧失了主动性思考能力。这种放弃主动思考的行为如果长期下去真的很可怕。 为了能不断的获得成长和提升，希望大家要坚持持续学习，锻炼系统性思考问题的能力。