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

38次阅读

共计 1285 个字符,预计需要花费 4 分钟才能阅读完成。

前言

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

接盘了一大坨演示类我的项目,域名 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


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

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

结语

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

正文完
 0