关于程序员:前端真的不需要架构能力吗看完这篇文章你就懂了

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

接盘了一大坨演示类我的项目，域名 20+ 个，每个我的项目的自身复杂度不高，然而我的项目数量惊人，我的项目之间充斥了重复性逻辑代码 …

忽然有一天产品说在某个我的项目改下款式，并且相干的都要进行同步 … 想必作为前端人都想口吐芳香了

为了不便了解，上面以图代文，正如所看到的那样，各种各样的域名对应大同小异的 repo, 保护起来几乎要命, 作为一位强迫症开发者，对于这种景象是相对是无奈容忍的。因而把每个我的项目的 repo 都过了一遍, 发现之间有很多类似的逻辑，包含前端页面的布局、我的项目的展现形式。最初进行了进一步的剖析，本着 ’ 求同存异 ’ 的思维，进行了汇总。

大略分为两大类我的项目：

1-1. 纯展现类 1-2. 纯展现类附带简略 UI 页 2. 定制化类

针对下面分好的两类我的项目，对我的项目的代码进行了合并并且引入了配置核心，去依据 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 引擎的抉择等，依据配置信息，进行具体管制（为了不便了解 也能够了解为权限控制系统）。复制代码

降级之后的状态，如下图所示。

进行了整合之后，本人在我的项目开发过程中仿佛加重了很大的心智累赘，然而大量域名的保护，仍旧须要走不同的公布程序，运维同学的心智累赘仍旧很大，因而想着能不能沟通一下，让域名共用一个，共用一个 jks 我的项目，这样的话开发运维都很谐和。

因而呈现了上面的这种图。

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

然而到此为止，尽管看似曾经解决了某些问题，然而感觉并没有做到最优。当前随着我的项目的复杂度愈高，简单的我的项目数量愈多，我想新的问题会随之而来..

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

其实，在工作中，发现不少的开发者都赖得动脑子去系统化的思考问题，忙于重复性的搬砖而忙的不可开交，缓缓丢失了主动性思考能力。这种放弃被动思考的行为如果长期上来真的很可怕。为了能一直的取得成长和晋升，心愿大家要保持继续学习，锤炼系统性思考问题的能力。

关于程序员:前端真的不需要架构能力吗看完这篇文章你就懂了

前言

注释

V1.0

V2.0

V3.0

结语