当前位置：首页 > news >正文

做钓鱼网站盗游戏号会被判刑吗扬州北京网站建设

news 2025/11/3 20:30:12

做钓鱼网站盗游戏号会被判刑吗,扬州北京网站建设,wordpress在哪儿设置关键词和描述,建站网站怎么上传代码前端架构的前世今生#x1f6f5;前言一、#x1f6f4;前端架构的前世今生1、架构是如何产生的#xff1f;2、MVC架构3、前后端分离架构4、Nodejs5、单页面架构#xff08;1#xff09;现有单页面架构#xff08;2#xff09;单页面架构的优势#xff08;3#xff09;单… 前端架构的前世今生前言一、前端架构的前世今生1、架构是如何产生的2、MVC架构3、前后端分离架构4、Nodejs5、单页面架构1现有单页面架构2单页面架构的优势3单页面架构的劣势6、大前端时代7、微前端架构二、软件设计原则与分层1、软件设计原则1单一职责原则2开放封闭原则3里氏替换原则4最少知识原则5接口隔离原则6依赖导致原则7总结2、补充设计原则1组合/聚合复用原则2无依赖原则3共同封装原则4共同重用原则5好莱坞原则6其他设计原则3、软件设计分层1图例2系统级架构3微前端4应用级架构5模块级架构6代码级架构7注意三、如何保证架构的质量1、系统的稳定性和健壮性1稳定性2健壮性3总结2、架构质量的衡量3、日常开发过程中的架构质量四、架构尹始1、架构前期准备1架构师分类2技术前期贮备3技术优化4架构优化2、技术填补1编码方案问题2技术填补会引发的后果3技术填补解决方案3、奔溃预防4、系统重构1基础概念2早期和晚期的系统3什么时候需要重构4重构流程五、️结束语彩蛋 One More Thing参考资料番外篇前言在我们的日常开发中经常会遇到这么一些业务需求比如说在一个项目中要放入两个完全不同类型的场景。基于这样的背景下单页面应用显然已经不能在繁杂的业务中脱颖而出。因此前端的流行趋势里也就有了微前端架构。这篇文章更像是一篇笔记记录了我学习微前端的伊始。那在这里可能会谈到为什么我会从之前的应用文到突然学起了这些架构内容呢原因在于周一在入厂后接触到了一系列超级先进的技术。微前端可能是我第一天就触碰到的一个概念在 mentor 的一番讲解之后才对它有了个浅显的认识。但万事万物的深入总得从它的根源去开始学起。于是也就有了这一系列文章的撰写~ 在下面的文章中将深入浅出的谈谈前端架构的前世今生。开始进入文章的讲解~ 一、前端架构的前世今生 1、架构是如何产生的刚开始时前端是没有架构的。为什么会这么说呢因为 js 在刚开始诞生时它的目的是为了让用户在页面上的交互会更加地流畅仅仅只是作为一个工具来使用。通常情况下那个时候的前端代码会内嵌到后端的应用中来使用。随着时间的推移和前端的发展在一个网页当中js 的代码会越来越多交互也变得越来越复杂。于是有了一些后端的架构比如说后端 MVC 框架。 2、MVC架构所谓 MVC 架构即将前端的渲染体系从后端的服务体系中拆解出去。后端 MVC 架构具有以下特点将视图层、数据层、控制层做分离后端的服务主要在数据层和控制层缺点重度依赖开发环境代码混淆严重复杂度比较高 3、前后端分离架构所谓前后端分离架构即将前端代码从后端环境中提炼出来 ajax 促进了前后端分离架构的发展也就是我们所说的多页面架构。下面我们用一张图来了解前后端分离架构的特点即使出现了前后端分离架构但它还是存在一定的缺点。比如前端缺乏独立部署能力整体流程依赖后端环境。针对存在的这些问题后来也就有了 Nodejs 。 4、Nodejs Nodejs 的广泛适应促进了前端技术的飞速发展因为 Node 的出现各种打包、构建工具应运而生。同时也诞生了多元化的前端开发方式使得前端开发可以脱离整体后端环境。 Nodejs 的出现使得前端产生了新的架构体系即单页面架构。 5、单页面架构 1现有单页面架构市面上流行的单页面架构有以下几种类型打包gulp、rollup、webpack和vite……框架vue/react/angular/……ui库antd/iview/elementui/mintui…… 2单页面架构的优势切换页面无刷新浏览器用户体验号组件化开发方式极大提升了代码复用率 3单页面架构的劣势单页面架构有一定的优势但同时也存在一定的不足。具体如下单页面架构所有的内容都是由 js 来渲染的因此会不利于 SEO 也不利于跨端搜索因为它只有一个简单的 html 文件。且由于所有的渲染都是由 js 来控制的因此首次渲染会出现较长时间的白屏。但比较好的一点是这两个存在的问题都可以利用其他技术手段来解决。说到这里细心的同学可能会发现一个问题所有的前端内容都还只停留在浏览器阶段只是跟用户在做一些简单的交互。那有没有可能有一种情况我们的 js 也可以写一些服务端的逻辑呢比如说连接数据库、做一些增删改查的操作或者一些运维的工作。基于这样的背景大前端时代到来了。 6、大前端时代大前端时代的到来为开发者们带来了一些服务端的框架。比如后端框架express、koa包管理工具npm、yarnnode版本管理nvm 综上大前端时代给我们提供了一定的便利但同时也带来了一定的弊端。比如所有的代码基本都可以通过应用拆分来实现细颗粒度但是呢这样细颗粒度的拆分也会导致一些维护上的困难即过于灵活的实现也导致了前端应用拆分过多维护困难。往往一个功能或需求会跨两三个项目来进行开发这样会增加很大的开发负担。基于以上弊端的存在现如今衍生出许多新型的架构比如微前端等。 7、微前端架构微前端等新型架构有以下特点跟技术栈无关可以使用 vue 、react 、angular 、html 原生等技术栈主框架不限制所接入应用的技术栈微应用具备完全自主权可以进行独立开发和独立部署。正所谓天下大势合久必分分久必合那么微前端架构也是一样的。它具有以下优点增量升级 - 不论是上线、发布还是开发都可以使用增量的方式来升级微前端是一种非常好的实施渐进式重构的手段和策略所谓渐进式重构即不断地对既有代码进行抽象、分离和组合。有时候在我们的大型应用里我们需要把一部分页面通过重构的方式来进行重写或优化以让代码后期可复用、无副作用和逻辑更单一而这所使用的方式就是渐进式重构微应用仓库独立前后端可独立开发主框架自动完成同步更新微前端的每一个子应用都是可以独立运行的每个微应用之间的状态是隔离的运行时状态不共享。有了优点那也会有一定的缺点。微前端架构劣势如下接入难度高 - 微前端的整体理念跟我们以往的开发方式还略有不同初步理解时会稍有困难因此会有较长一段时间的接受程度。应用场景 - 在移动端较少、而在 PC 端和后台管理端应用较多。二、软件设计原则与分层上面我们讲解了前端架构的前世今生。接下来我们将来了解软件设计的原则与分层。 1、软件设计原则 1单一职责原则概念永远不应该有多于一个原因来改变某个类。理解对于一个类而言应该仅有一个引起它变化的原因。应用如果一个类拥有了两种职责那就可以将这个类分为两个类。相信看上面的概念可能很多小伙伴会觉得很枯燥接下来我们用一个例子来进行阐述。具体如下比如说我们现在在做登录页面这个页面会有两个验证功能。第一个是验证用户的用户名第二个是验证用户的密码。那假设说我们把这两个功能放在同一个方法里这不仅仅会不利于查找错误的原因而且在一个方法里面我们会写很多的逻辑判断来验证我们当前所验证的字段是用户名还是密码。这样做不仅仅会加重我们开发的负担而且在我们后期的开发过程中维护起来也是比较困难的。因此在这个时候我们就可以将验证用户名和验证密码这两个功能拆分成两个方法去进行实现。 2开放封闭原则概念软件实体扩展应该是开放的但对于修改应该是封闭的。理解在我们整体的开发过程中封装的类或者方法应该是便于扩展而不便于修改的。也就是说“可以去扩展某个类或者某个方法但是尽量不要去对它进行修改”。应用当需求有改动尽量用继承或组合的方式来扩展类的功能而不是直接修改类的代码。同样我们用一个例子来阐述开放封闭原则具体如下在上面验证用户名和验证密码功能的基础上我们继续添加一个核对图片验证码的功能。在输入了用户名和密码之后需要让用户再输入验证码只有验证码输入正确后才可以进行正常登录。那这个时候可能有的小伙伴会想去修改验证密码这个函数的功能那么我们不仅仅要付出大量的开发时间还有多出很多的测试内容要去测试。同时上线了之后我们也不能保证是否会对验证密码这个功能造成影响。所以这样做后期的维护成本是相当大的。因此我们应该先去封装一个新的函数来验证图片验证码的功能。这样处理即使是线上环境出了问题我们也可以更好的追溯到出现问题的源头。 3里氏替换原则概念父类在使用的过程中一定是能够被子类替换的。理解那么也就是说我们在使用父类方法的时候如果说将父类的引用化为子类的引用那么对于整体的程序设计来说是没有任何影响的。里氏替换可能在我们适应面向对象的时候会不断的注意到。而对于现在大部分在使用函数式编程时对里氏替换原则的关注度可能就没有那么高了。对于架构设计而言里氏替换原则是一个比较重要的原则我们需要对一些整体的程序做一些可替换的操作。 4最少知识原则概念只与你最直接的对象交流即与你直接关联的对象。理解低耦合高内聚。应用做系统设计时尽量减少依赖关系。 5接口隔离原则概念一个类与另一个类之间的依赖性应该依赖于尽可能小的接口。理解不要对外暴露没有实际意义的接口用户不应该依赖它不需要的接口。应用当需要对外暴露接口时如果是非必要对外提供尽量删除。 6依赖导致原则概念高层模块不应该依赖于低层模块他们应该依赖于抽象。抽象不应该依赖于细节而细节应该依赖于抽象。理解应该面向接口编程不应该面向实现类编程。注意点并不是说所有的类都要有一个对应的接口而是说如果有接口那就尽量使用接口来编程。 7总结将以上六大原则的英文首字母拼在一起就是 SOLID 稳定的所以也称之为 SOLID 原则。只有满足了这六大原则之后才能设计出稳定的软件架构 2、补充设计原则下面我们再来补充几个重要的设计原则具体如下。 1组合/聚合复用原则当要扩展类的功能时优先考虑使用组合而不是继承。该原则在 23 中经典设计模式中频繁使用。如代理模式、装饰模式、适配器模式等等。 2无依赖原则当 A 模块依赖于 B 模块B 模块依赖于 C 模块C 模块依赖于 A 模块此时将出现循环依赖。在设计中避免该问题可通过引入 “中介者模式” 解决。 3共同封装原则应该将易变的类放在同一个包里将变化隔离出来。该原则是“开放-封闭原则”的延伸。 4共同重用原则如果我们重用了某个包中的一个类那么这个包又还需要依赖于它的一个父类。这样就相当于重用了包中的所有类因此我们要尽可能减少包的大小。 5好莱坞原则秉承 Dont call me, I‘ll call you. 的原则控制反转或称为“依赖注入”不需要主动创建对象而是由容器帮我们来创建并管理这些对象。 6其他设计原则不要重复你自己 —— 不要让重复的代码到处都是要让它们足够的重用所以要尽可能地封装。保持它简单与傻瓜 —— 保持系统界面简洁功能实用操作方便。高内聚与低耦合 —— 模块内部需要做到内聚度高模块之间需要做到耦合度低。关注点分离 —— ①将一个复杂的问题分离为多个简单的问题然后逐个解决。②难点如何进行分离。你不需要它 —— ①不要一开始就把问题设计的非常复杂不要陷入“过渡设计”的深渊②让系统足够简单而又不失去扩展性。 3、软件设计分层 1图例软件的设计分层可以分为4个部分分别是系统级架构、应用级架构、代码级架构和模块级别架构。具体如下图所示下面我们将依据这 4 大设计分层来进行一一介绍。 2系统级架构应用在整个系统内如与后台服务如何通信与第三方系统如何集成。设计前端首要条件了解前端系统与其他系统之间的关系。其中关系包括业务关系和协同机制。设计后端首要条件只需要规定与后台数据传递的机制。包括api 设计规则访问授权的一个开放标准OAuth跳转 token 的验证数据传递 cookie 等。前端与后端的关系考虑的主要因素是前后端分离的架构设计。前后端分离架构其实是如何实施技术决策包括用户鉴权、API接口管理和设计、API文档管理、Mock的使用、BFF服务于前端的后端nodejs以及是否需要服务端渲染等。 3微前端在一个系统内微前端是应用间的架构方案。在多个应用之间微前端则是一种系统间等架构方案。微前端是将多个前端应用以某种形式结合在一起进行应用。旨在解决单体应用在一个相对长的时间跨度下由于参与的人员、团队的增多、变迁从一个普通应用演变成一个巨石应用FrontEnd Monolith后随之而来的是应用不可维护的问题。单实例即同一时刻只有一个子应用被展示子应用具备一个完整的应用生命周期。多实例通常基于 url 的变化来做子应用的切换值得注意的是同一时刻可展示多个子应用。通常使用 Web Components 方案来做子应用封装子应用更像是一个业务组件而不是应用。 4应用级架构应用级架构可以看做是系统级别架构的细化。单个应用与其他外部应用的关系微服务架构下多个应用的协作、数据交换等。应用级架构举例脚手架、模式库和设计系统 5模块级架构这部分内容是我们开始业务编码之前进行设计我们称之为迭代。 6代码级架构主要谈论规范与原则。 7注意上面我们谈到软件的 4 种设计分层同时对于这 4 种设计分层来说它的难度是逐级递减的。在开发中要注意可维护性和可扩展性。简单的代码可维护性高越是写的抽象的代码越难维护。三、如何保证架构的质量 1、系统的稳定性和健壮性 1稳定性定义当一个实际的系统处于一个平衡的状态时如果受到外来作用的影响时系统经过一个过渡过程仍然能够回到原来的平衡状态我们称这个系统就是稳定的否则称系统不稳定。特点架构设计的基石可以更好的实现自我修复 2健壮性定义计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下能否不死机、不崩溃就是该软件健壮性的具体表现。解释一个系统容错能力强运行不易被干扰安全性好。度量标准一个软件可以从错误的输入中推断出正确合理的输入一个软件可以正确的运行在不同环境下一个软件能够检测到自己的内部设计或者编码错误并得到正确的结果。 3总结健壮性和稳定性是特定软件自身的要求健壮性和稳定性是软件处理的一部分软件架构的健壮性和稳定性是该软件规划时所确定的目标若软件的实现未能达到原定的目标则该软件的健壮性和稳定性不够或不好。 2、架构质量的衡量想要衡量一个软件架构的好坏程度需要注意以下几点衡量标准拓展性维护性可管理性高可用性故障修复、容灾、降级和熔断 3、日常开发过程中的架构质量对于日常开发过程中的软件架构来说总会有好的架构和不好的架构设计。那对于架构质量来说有以下几点衡量指标理解难度崩溃率和错误率的指标接入依赖的成本开发效率错误上报和信息收集等功能四、架构尹始 1、架构前期准备都说正确的选择是良好架构的开端也就是说如果前期我们把所有需要准备的内容准备好那么在做架构设计时也将会让架构设计更加的得心应手。下面我们就来谈论几点架构前期需要准备的内容。 1架构师分类系统架构师从系统的维度出发负责整体系统的架构设计主要是基础服务和各系统间协调着眼全局比如关注负载、可靠性、伸缩、扩展、整体项目切分、缓存应用等方面的基础架构设计。应用架构师从应用程序的维度出发负责某个应用的技术架构主要偏业务系统。关注和理解业务梳理模型、设计模式、接口和数据交互等方面。业务架构师从业务流程的维度出发对某一个行业、业务的领域做相应的分析获取领域模型最终获得系统的模型。也可以称为是领域专家、行业专家、产品咨询师和资深顾问。 2技术前期贮备技术选型社区氛围、发展规模、未来发展趋势、与当前团队的契合度、执行成本、维护和迁移成本、执行效率等内容的调研和报告。想充分调研每一项技术可能带来的利与弊。最大程度上预测架构设计中的缺陷以防重大问题的发生。 3技术优化在架构发展过程中可能会存在一些有悖于当前架构设计的实现造成了架构发展阻塞所以需要进行架构优化使得架构设计的适应性更高。 4架构优化架构不是一蹴而就的即不是一成不变的。在业务发展的过程中架构也在不断地演进。因此要对架构设计进行实时调优使架构优化为常态化。通过不断的调整架构实现改进初始架构中设计的不足来补足短板。 2、技术填补 1编码方案问题在开发中有时候会因为开发时间紧急的原因让我们写的代码有些粗糙。如果每次都不让自己去追求完美而是一味的妥协现有不好用的编码方案。久而久之很容易使得整个软件架构零散成一地像是东拼西凑的没有任何支撑点可言。常见问题的存在形式有以下几大方面开发过程中因为时间紧迫导致的实现不合理 —— 比如查找10000以内的质数利用循环或筛选法等方式来进行实现。暂时没有想到更好的实现方式而妥协的版本 —— 刚开始使用 if……else 实现慢慢地演变成责任链的模式。架构设计前期没有考虑到的细节 —— ①交互细节→ props 传递参数交互冗余流程较长②使用全局状态管理实现参数传递。不合理的交互设计导致技术实现复杂。旧功能文档缺失无正确拓展、修改和兼容旧功能导致上线后问题剧增。 2技术填补会引发的后果在上面中我们举例了各种软件编码过程中修修补补的方案那这样不断的技术填补后会导致什么样的后果么具体表现有修复变重构 —— 小的技术债务不做偿还最后会演变成一场大规模的重构工作导致产出不高影响开发速度 —— 技术债务的存在导致整体开发需要减容的点过多影响开发效率。极大影响上线速度导致整体项目迭代缓慢失去核心竞争力开发死循环 —— 容易陷入维护旧功能→开发新功能→兼容旧功能→维护旧功能→开发新功能……这样的恶性循环。 3技术填补解决方案上面说到了技术填补会引发的后果那后果产生了自然也就需要有对应的解决方案来弥补。具体解决方案有以下几种优秀的架构设计是基础 —— ①必须能够有效处理当前需求中可预见的情况而对于未知的、可能出现的特殊情况一般很小的改动就能解决问题②根据当前的业务进行合理的项目拆分尽量的代码解耦减少高耦合度的情况发生③必须有日志模块操作日志错误日志业务日志等等。良好的技术培训和传帮带能力 —— ①让每一位开发者可以从更深一层次理解自己所需要实现的功能②从最开始的代码规范、到熟悉业务、最后再到编写文档。传帮带充分的技术方案可避免一部分技术债务的产生 —— 技术方案是充分理解需求之后所能产出的对需求理想的实现方式必要性不言而喻。不同工程师之间可以相互review —— CodeReview 是非常重要的同时也是对自身的一个提高。提升对修复技术债务重要性的认知 —— 工程师如果能预见一个债务可能导致的问题自然愿意花时间去处理。善于发现和定期处理一些技术债务 —— 勇于发现系统中的技术债务让自己为系统负责。总结来说就是等产品上线后开发就没有那么紧张了这个时候就可以找个时间来处理下遗留下来的技术债务在解决技术债务中不断去突破自己的上限更好的提高自己的技术能力和软件架构设计的能力。 3、奔溃预防架构奔溃是严重的架构设计事故也是我们需要预防的关键所在。在软件奔溃的时候首先要分析原因①系统奔溃的产生②日志记录如操作日志错误日志业务日志等。分析完成原因之后接下来要讲的是如何预防架构奔溃。主要有以下几点用户行为抓取→争取在最新时间获取到用户操作链条解决存量问题→技术债务遏制新增→减少新增问题的概率对脏数据进行兜底和校验单元测试奔溃预警自动化测试更广的灰度触达性能优化体系…… 4、系统重构架构并不是永恒不变的架构也是具有生命周期的也会经历初生、发展、巅峰、衰弱、消亡的过程。那下面就来了了解软件重构的相关内容。 1基础概念什么是重构对软件内部结构的一种调整。目的是在不改变可观察行为的前提下提高其可理解性降低其修改成本。实现方式使用一系列重构手法在不改变软件可观察行为的前提下调整其结构。重构理念运用大量微小且保持软件行为的步骤一步步达成大规模的修改。 2早期和晚期的系统早期系统特点开发速度快代码复杂度低代码规范都保持完好严格注重开发规范不会允许危及架构设计的代码产生以上因素导致添加功能难度低成本低晚期系统特点具备所有早期系统的劣势代码复杂度高代码规范不完善很多需求或功能会出现为了愉悦架构设计的情况添加新功能兼顾较多涉及较多模块牵一发而动全身 3什么时候需要重构当发现现有系统体系已经不能满足当前迭代速度的时候就需要进行重构工作。对有「坏味道」的代码通过一些重构手段进行微重构。 4重构流程重构一般具有以下流程确定问题点确定重构功能和范围根据旧架构中已有的设计梳理重构后软件应有的逻辑走向确保重构后的软件具有一定的稳定性和性能上的优化解决此前在需求过程中存在的冲突问题。五、️结束语在上面的文章中我们学习了前端架构的前世今生以及软件设计的原则与分层。除此之外也阐述了在实际开发中如何去保证架构的质量以及在做架构时需要有的一些前期准备。文章仅根据周一的浅薄理解做了一些输出难免很多观点有不当之处。欢迎交流~ 到此关于前端架构的前世今生就讲解结束啦希望对大家有帮助~ 彩蛋 One More Thing 参考资料从零打造微前端框架番外篇关注公众号星期一研究室第一时间关注学习干货更多有趣的专栏待你解锁~如果这篇文章对你有用记得留个jio 再走哦我们下期见

查看全文

http://www.huolong8.cn/news/201978/