精华内容
下载资源
问答
  • 寻求工程化
    千次阅读
    2021-12-29 22:00:46

    一:软件工程

    (1)软件工程的定义

    软件工程:采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,经济的开发出高质量的软件并维护它

    (2)软件工程的本质特征

    ① 关注大型程序的构造

    • 把一个人在较短时间内写出的程序称为小型程序,而把多人合作用时半年以上才写出的程序称为大型程序。传统的程序设计技术和工具是支持小型程序设计的,不能简单地把这些技术和工具用于开发大型程序。

    ② 中心课题是控制复杂性

    • 软件所解决的问题通常十分复杂,不得不把问题分解,使得分解出的每个部分是可理解的,而且各部分之间保持简单的通信关系。用这种方法并不能降低问题的整体复杂性,但是却可使它变成可以管理的。

    ③软件经常变化

    • 绝大多数软件都模拟了现实世界的某一部分。 现实世界在不断变化,软件为了不被很快淘汰,必须随着所模拟的现实世界一起变化。因此,在软件系统交付使用后仍然需要耗费成本,而且在开发过程中必须考虑软件将来可能发生的变化

    ④开发效率非常重要

    • 社会对新应用系统的需求超过了人力资源所能提供的限度,软件供不应求的现象日益严重。软件工程的一个重要课题就是,寻求开发与维护软件的更好更有效的方法和工具

    ⑤开发人员和谐合作是关键

    • 软件处理的问题十分庞大,必须多人协同工作才能解决这类问题。为了有效地合作,必须明确地规定每个人的责任和相互通信的方法,每个人还必须严格地按规定行事,纪律是成功地完成软件开发项目的一个关键

    ⑥软件需要有效支持用户

    • 开发软件的目的是支持用户的工作。软件提供的功能应该能有效地协助用户完成他们的工作。有效地支持用户意味着必须仔细地研究用户,以确定适当的功能需求、可用性要求及其他质量要求。还意味着软件开发不仅应该提交软件产品,而且应该写出用户手册和培训材料

    ⑦软件开发者替代其他领域人员创造产品

    • 软件工程师是软件设计、软件体系结构、测试或统一建 模语言等方面的专家,但他们不仅缺乏应用领域和文化领域的实际知识,还缺乏该领域的文化知识,这是软件开发项目出现问题的常见原因

    (3)软件工程基本原理

    ①按软件生存期分阶段制定计划并认真实施

    • 在软件开发与维护的漫长的生命周期中,需要完成许多性质各异的工作。应该把软件生命周期划分成若干个阶段,并相应地制定出切实可行的计划,然后严格按照计划对软件的开发与维护工作进行管理。不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作,绝不能受客户或上级人员的影响而擅自背离预定计划

    ②坚持进行阶段评审

    • 由于大部分错误都是在编码之前造成的,并且错误发现与改正的越晚,所需付出的代价也越高,所以软件的质量保证工作不能等到编码阶段结束之后再进行。因此,在每个阶段都进行严格的评审,以便尽早发现在软件开发过程中所犯的错误,是一条必须遵循的重要原则

    ③坚持严格的产品控制

    • 当改变需求时,为了保持软件各个配置成分的一致性, 必须实行严格的产品控制,其中主要是实行基准配置管理。所谓基准配置又称为基线配置,它们是经过阶段评审后的软件配置成分

    ④使用现代程序设计技术

    • 采用先进的技术不仅可以提高软件开发和维护的效率,而且可以提高软件产品的质量

    ⑤结果能够得到清楚的审查

    • 软件产品不同于一般的物理产品,它是看不见摸不着的逻辑产品。软件开发人员的工作进展情况可见性差,难以准确度量。为了提高软件开发过程的可见性,更好地进行管理,应该根据软件开发项目的总目标及完成期限,规定开发组织的责任和产品标准,从而使得所得到的结果能够清楚地审查

    ⑥用人少儿精

    • 软件开发小组的组成人员的素质应该好,而人数则不宜过多。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍,而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误

    ⑦承认不断改进软件工程实践的必要性

    • 为了保证软件开发与维护的过程能赶上时代前进的步伐,能跟上技术的不断进步,不仅要积极主动地采纳新的软件技术,而且要注意不断总结经验。例如,收集进度和资源耗费数据,收集出错类型和问题报告数据等

    二:软件工程方法学

    (1)概念

    软件工程方法学:把在软件生命周期全过程中使用的一整套技术方法的集合称之为方法学,也称为泛型。软件工程方法学包含三个要素:方法、工具、过程

    • 方法:完成软件开发各项任务的技术方法,回答“怎么做”的问题
    • 工具:为运用方法提供的自动或半自动软件工程支撑环境
    • 过程:是为了获得高质量软件所需要完成的一系列任务框架,回答“何时做”的问题

    (2)分类

    传统方法学(生命周期方法学)

    • 采用结构化技术完成软件开发各项任务
    • 把软件生命周期的全过程依次划分为若干阶段
    • 每个阶段开始和结束都有严格标准
    • 每个阶段结束后要有严格审查

    面向对象方法学

    • 把对象作为融合了数据及在数据上的操作行为的统一的软件构件
    • 把所有对象划分为
    • 按照父类与子类的关系,把若干类组成层次结构的系统
    • 对象彼此间仅能通过发送消息互相联系
    更多相关内容
  • 前端的小伙伴应该能够很明显地感觉到,在面试过程中,各大公司面试官已经非常注重前端工程化能力的考察了。 前端工程化的演进可以极大地提升开发效率。前端发展到现在,社区涌现出大量的优秀框架和工具,得以将...

    前端的小伙伴应该能够很明显地感觉到,在面试过程中,各大公司面试官已经非常注重前端工程化能力的考察了。

    前端工程化的演进可以极大地提升开发效率。前端发展到现在,社区涌现出大量的优秀框架和工具,得以将前端工程师从繁重的工作中解脱出来。比如,同样地给一个 dom 元素绑定一个 click 事件,使用 Vue 就会比 JS 更简单清晰。

    我相信每个踏入前端这个行业的同学都是有着一颗热爱学习的心。因为前端这个行业不如后端那么成熟稳定,所以一直是在高速地推陈出新,每年都会有新的框架出来。但每个人的精力又是有限的,每个人都希望投入有限的精力的情况下,能学到最有价值的东西。所以我一直在想能否将这些年前端在工程化方面的优秀成果浓缩到一个课程中。感兴趣的同学可以了解下 ?《透视前端工程化》

    结合自己的经历总结了一些在前端学习上的方法,希望对大家有所帮助:

    1. 夯实自己的基础能力。HTML、CSS、JS这三个前端必备的技术是必须要精通的,不能做了几年前端了连CSS布局、异步编程这些基本的东西还模糊不清。
    2. 抓主要矛盾,打造核心竞争力。每个人的精力有限,我们应该挑选一个感兴趣的方向往深里去钻研。而不是企图将所有的方向都做到最好。
    3. 工作中多思考总结。很多人吐槽自己一直疲于做做业务需求,没有机会做技术项目,得不到提高。其实在业务中也能做到能力的提升。在做业务的时候,完全可以将自己平时的新想法,接触到的新技术付诸实践。另外,做完项目后做一个复盘,总结自己遇到的问题和解决方案。久而久之,你会发现自己在业务中也能很好地得到成长。
    4. 多与别人交流。现在互联网技术讲究开源,我们的心态更要open,应该互相学习对方的优点,内化为自己的东西,让自己得到快速提升。
    5. 时刻关注社区技术动态。前端的新东西层出不穷,不一定什么东西都去学,但要掌握行业动态,知道大家都在玩什么技术,跟上行业的脚步。

    我是谁?

    我是王超,现任快狗打车(原58速运)前端负责人,从 0 到 1 组建了快狗前端团队,负责团队技术体系的搭建,形成了以 Webpack 和 Vue 为基础、 Node.js 中间层为补充的,自动化、工程化、组件化的快狗前端技术体系。

    曾任职于人人网、奇虎360、58,有 8 年知名互联网工作经验。

    这次主要是想和大家聊聊从切图仔到前端 Leader,究竟是如何实现的个人成长?

    联合推荐:沈剑 快狗打车CTO王海旭 58大前端团队创始人冯阳 58到家平台前端负责人


    我的工作经历

    时间如白驹过隙,转眼已经在前端这个行业已经七八年的光景了。非计算机专业出身的我从事前端这个行业,确实经历了很多的挫折,走了很多弯路。

    但现在回首自己的职业经历,每一份经历都有不一样的收获。

    毕业生,第一份工作千万不能选错

    我毕业后第一份工作是在一家广告联盟公司做 flash 广告设计和平面设计。当初选择这份工作自己根本就没经过仔细的考虑。

    由于公司很小,在 flash 开发设计这个岗位上就我一个人,身边没有有经验的人可以学习。随着 Web2.0 时代的到来,Flash 技术也在走下坡路了,我的 flash 之路是条死路。

    后来公司来了一个做前端的同事,工作中与之不断交流中渐渐了解了前端开发,flash 技术未来一定会被前端的技术所取代。这才将自己的精力投入到了前端的学习上,慢慢也能做一些简单的前端工作了。

    现在来看,虽然自己最终找到了一个正确的航道。但如果在选择工作的时候就经过仔细调研,能让自己少走很多弯路。

    平台对新人很重要,好的平台会让新人有很好的成长起点,具备良好的视野。而且在平台众多有经验的老人的提携下,新人成长的会很快,能为以后的职业发展奠定一个良好的基础。

    「人人网」时期,见证 PC Web 到 移动 Web 的跨越

    当时的前端处于从 PC Web 开发向移动 Web 开发过渡的时期。在这里的两年多,无论是 PC 上的开发还是移动上的开发都做了很多,比如 PC 各种浏览器厂商的兼容问题,移动端上各种机型的适配问题,使用 CSS3 实现各种新特性。

    此时前端领域正在发生快速的变化,像 Angular、React 等现代前端框架已经开始出现。而这边依旧是使用传统的原生 JS、jQuery 重复性地完成项目,自己的技术也进入了一个瓶颈期。

    面对自己的技术瓶颈,我想到的是换个环境来逼迫自己跳出舒适区,突破技术瓶颈。
    但是,这里我想多说一句,一定不要为了跳槽而跳槽。

    跳槽之前要问自己一句,我在这里是不是已经该学的都学会了?如果答案是肯定的,那就早点行动,否则就踏踏实实地继续沉淀提高。

    「360」时期,越痛苦提升越快

    360 这边的技术体系很完善,前后端分离开发、前端部署平台化、上线前代码自动 diff,新技术的应用、定期的技术交流。

    入职之初我做项目很吃力,因为从开发框架 Backbone、React 到构建工具 Webpack,再到开发方式使用 Linux 开发机,所有的东西都是新的,感觉哪哪都不会。

    我足足用了半年的时间,直到和同事一起使用 React 重构 360 地图,才完全熟悉和适应。但让我无比痛苦的半年恰恰是自己提升最快的时候。

    谈到这里我想说一下是如何一步步提升自己的。

    第一是独立思考解决方案。遇到了问题我通常是自己去网上去找解决方案,实在解决不了了,再去找自己的同事和 leader 寻求帮助。

    第二看比自己能力强的同事的代码。从他们的代码中,可以借鉴到很多好的设计方式和编程习惯,日积月累变成自己的东西。

    第三多与同事进行技术交流。通过与他们的交流,可以很好地开阔自己的视野,弥补自己不知道的知识。这里特别感谢一下我的老朋友司望利,从他的身上学到了很多。

    「快狗」的挑战,建设前端工程体系

    快狗这边的早期的前端开发方式比较原始。担任快狗前端负责人后,我开始着手推进前端工程化。首先就是升级技术栈,并进行前后端分离。陆续建设了前端部署平台、组件库、脚手架、以及性能监控平台逐渐形成了完善的前端技术体系。

    做为团队负责人如何从无到有搭建技术体系,这里分享一下我的经验。

    新晋技术负责人从技术思维向管理思维转变。很多技术人在成为团队管理者后,还是习惯什么事情都自己搞,一方面担心别人做不好,另一方面担心自己的技术优势会慢慢丧失。别人不会做,你可以进行指导,但不能千万自己替他做,因为你的精力是有限的。另一个担心更不可取了,你虽然不再深入技术细节,但在知识的技术广度、技术视野上会有更大的提高。

    技术体系建设要以解决业务痛点为目的。任何的技术工具和平台建设都不能脱离这个目的,不能仅仅为了试用一下某项技术或者好玩就去搞。否则很可能是白白浪费了研发成本,缺很难在团队中推广使用,无法产生价值。

    技术体系建设要充分讨论后再实施。方案的设计讨论清楚了,才能避免将来各种问题的出现。我们在建设前端部署平台的时候就有过深刻的教训。

    由于前期方案考虑不周,后期平台经历一次大的调整,使用老平台部署的项目用了半年的时间才完成迁移,成本很高。

    建议将 70% 的时间用在方案设计和讨论上,30% 时间用在工具和平台的研发上。

    为什么大公司现在这么重视前端工程化?

    从事前端开发这个职业有七八年的时间了,既经历过工程化程度极低的开发方式,也见证了这几年前端领域工程化水平的大幅提升。导致前端工程化水平大幅提升的原因,大致有二:

    一方面是由于大公司本身业务复杂,相应的前端工程化程度高,配套的基础设施很成熟,对人员的要求自然很高。

    另一方面,现在的前端开发都是在一些先进的工程化工具基础之上,比如 React、Vue、Sass、Webpack 等。只有具备良好的工程化能力,才能更好地应对日益复杂的开发任务,才能更容易进入大公司。

    试读 ?《透视前端工程化》

    课程设计

    前端工程化是个比较大的话题,涵盖的知识很多。大篇幅的讲述理论知识又是很枯燥的,而且效果不好。

    所以在课程设计上,我是以动手实现一个前端脚手架工具为主线,过程中引出实现某个功能的思路和用到的工具,并一一讲解。

    例如,为了把规范开发者的代码,我们在脚手架中需要引入代码检查工具eslint和stylelint,并对两者的使用进行了讲解。

    又比如,在搭建本地开发环境可能有多种实现方式,比如自己单独写一个静态服务器来实现或者使用 webpack-dev-server 和 webpack-dev-middleware 进行来实现,我们着重对后者进行了详细介绍。

    读者在课程结束后,不但可以系统学习了前端工程化的工具和知识,还可以完成一个实用的脚手架工具。

    课程特色

    实操驱动,沟通前端知识

    实际操作脚手架搭建,沟通起流程规范、开发、联调、测试、构建、部署各个环节知识

    实用性强,直接落地业务

    课程内容基于团队的实际工程化经验,可以把课程所学直接应用到业务开发中

    你能学到什么

    1. 对前端工程化有一个系统认知;
    2. 能独立设计一套前端工程化解决方案;
    3. 知识广度上有大幅提升;
    4. 进入更好的平台,获得更好的薪酬。

    最后,希望每一个前端人都能通过努力来完成自己的人生进阶道路,加油!

    试读 ?《透视前端工程化》

    目录

    开篇词:到底什么是前端工程化

    第一部分:模板设计

    第01课:模板功能设计
    第02课:Webpack 基本介绍
    第03课:搭建项目模板框架
    第04课:前端模块化解决方案
    第05课:搭建本地开发环境
    第06课:搭建本地 Mock 服务
    第07课:引入代码检查工具
    第08课:自动生成雪碧图
    第09课:根据浏览器构建
    第10课:根据环境构建
    第11课:集成移动端调试工具
    第12课:引入单元测试
    第13课:引入 e2e 测试
    第14课:Webpack 构建性能优化
    第15课:添加部署功能
    第16课:聚合项目配置并模板化

    第二部分:命令行设计

    第17课:cli 功能设计(上)
    第18课:cli 功能设计(下)

    结语:开放的心态才是更高阶的工程化

    展开全文
  • 什么是前端工程化

    千次阅读 2018-06-26 16:25:17
    目前来说,Web业务日益复杂化和多元化,前端开发已经由以WebPage模式为主转变为以WebApp模式为主了。...前端工程化是前端架构中重要的一环,主要就是为了解决上述大部分问题的。而前端工程本质上是软件工程...

    目前来说,Web业务日益复杂化和多元化,前端开发已经由以WebPage模式为主转变为以WebApp模式为主了。现在随便找个前端项目,都已经不是过去的拼个页面+搞几个jQuery插件就能完成的了。工程复杂了就会产生许多问题,比如:如何进行高效的多人协作?如何保证项目的可维护性?如何提高项目的开发质量?...


    前端工程化是前端架构中重要的一环,主要就是为了解决上述大部分问题的。而前端工程本质上是软件工程的一种,因此我们应该从软件工程的角度来研究前端工程。


    那么前端工程化需要考虑哪些因素?

    本人总结经验,认为前端工程化主要应该从模块化、组件化、规范化、自动化四个方面来思考,下面一一展开。


    ## 模块化


    简单来说,模块化就是将一个大文件拆分成相互依赖的小文件,再进行统一的拼装和加载。只有这样,才有多人协作的可能。


    ### JS的模块化


    在ES6之前,JavaScript一直没有模块系统,这对开发大型复杂的前端工程造成了巨大的障碍。对此社区制定了一些模块加载方案,如CommonJS、AMD和CMD等,某些框架也会有自己模块系统,比如Angular1.x。


    现在ES6已经在语言层面上规定了模块系统,完全可以取代现有的CommonJS和AMD规范,而且使用起来相当简洁,并且有静态加载的特性。


    规范确定了,然后就是模块的打包和加载问题:

    1. 用Webpack+Babel将所有模块打包成一个文件同步加载,也可以打成多个chunk异步加载;

    2. 用SystemJS+Babel主要是分模块异步加载;

    3. 用浏览器的<script type="module">加载

    目前Webpack远比SystemJS流行。Safari已经支持用type="module"加载了。


    ### CSS的模块化


    虽然SASS、LESS、Stylus等预处理器实现了CSS的文件拆分,但没有解决CSS模块化的一个重要问题:选择器的全局污染问题。


    按道理,一个模块化的文件应该要隐藏内部作用域,只暴露少量接口给使用者。而按照目前预处理器的方式,导入一个CSS模块后,已存在的样式有被覆盖的风险。虽然重写样式是CSS的一个优势,但这并不利于多人协作。


    为了避免全局选择器的冲突,各厂都制定了自己的CSS命名风格:


    但这毕竟是弱约束。选择器随着项目的增长变得越多越复杂,然后项目组里再来个新人带入自己的风格,就更加混乱了。


    所以我很赞同这句话:

    与其费尽心思地告诉别人要遵守某种规则,以规避某种痛苦,倒不如从工具层面就消灭这种痛苦。

    从工具层面,社区又创造出Shadow DOM、CSS in JS和CSS Modules三种解决方案。

    • Shadow DOM是WebComponents的标准。它能解决全局污染问题,但目前很多浏览器不兼容,对我们来说还很久远;
    • CSS in JS是彻底抛弃CSS,使用JS或JSON来写样式。这种方法很激进,不能利用现有的CSS技术,而且处理伪类等问题比较困难;
    • CSS Modules仍然使用CSS,只是让JS来管理依赖。它能够最大化地结合CSS生态和JS模块化能力,目前来看是最好的解决方案。Vue的scoped style也算是一种。

    ### 资源的模块化


    Webpack的强大之处不仅仅在于它统一了JS的各种模块系统,取代了Browserify、RequireJS、SeaJS的工作。更重要的是它的万能模块加载理念,即所有的资源都可以且也应该模块化。


    资源模块化后,有三个好处:

    1. 依赖关系单一化。所有CSS和图片等资源的依赖关系统一走JS路线,无需额外处理CSS预处理器的依赖关系,也不需处理代码迁移时的图片合并、字体图片等路径问题;
    2. 资源处理集成化。现在可以用loader对各种资源做各种事情,比如复杂的vue-loader等等。
    3. 项目结构清晰化。使用Webpack后,你的项目结构总可以表示成这样的函数:dest = webpack(src, config)


    ## 组件化


    首先,组件化≠模块化。好多人对这两个概念有些混淆。


    模块化只是在文件层面上,对代码或资源的拆分;而组件化是在设计层面上,对UI(用户界面)的拆分。


    从UI拆分下来的每个包含模板(HTML)+样式(CSS)+逻辑(JS)功能完备的结构单元,我们称之为组件。


    其实,组件化更重要的是一种分治思想

    Keep Simple. Everything can be a component.

    这句话就是说页面上所有的东西都是组件。页面是个大型组件,可以拆成若干个中型组件,然后中型组件还可以再拆,拆成若干个小型组件,小型组件也可以再拆,直到拆成DOM元素为止。DOM元素可以看成是浏览器自身的组件,作为组件的基本单元。

    传统前端框架/类库的思想是先组织DOM,然后把某些可复用的逻辑封装成组件来操作DOM,是DOM优先;而组件化框架/类库的思想是先来构思组件,然后用DOM这种基本单元结合相应逻辑来实现组件,是组件优先。这是两者本质的区别。


    其次,组件化实际上是一种按照模板(HTML)+样式(CSS)+逻辑(JS)三位一体的形式对面向对象的进一步抽象


    所以我们除了封装组件本身,还要合理处理组件之间的关系,比如(逻辑)继承(样式)扩展(模板)嵌套包含等,这些关系都可以归为依赖


    其实组件化不是什么新鲜的东西,以前的客户端框架,像WinForm、WPF、Android等,它们从诞生的那天起就是组件化的。而前端领域发展曲折,是从展示页面为主的WebPage模式走过来的,近两年才从客户端框架经验中引入了组件化思想。其实我们很多前端工程化的问题都可以从客户端那里寻求解决方案。


    目前市面上的组件化框架很多,主要的有VueReactAngular 2、我们公司

    RegularAvalon等。你感兴趣可以都研究一下,选择一套中意的。其实Vue文档中的 对比其他框架一文已经讲得很详细了。


    ## 规范化


    模块化和组件化确定了开发模型,而这些东西的实现就需要规范去落实。

    规范化其实是工程化中很重要的一个部分,项目初期规范制定的好坏会直接影响到后期的开发质量。


    我能想到的有以下一些内容:

    • 目录结构的制定
    • 编码规范
    • 前后端接口规范
    • 文档规范
    • 组件管理
    • Git分支管理
    • Commit描述规范
    • 定期CodeReview
    • 视觉图标规范
    • ...

    其中编码规范最好采取ESLint和StyleLint等强制措施,配置git hooks可以实现Lint不过不能提交代码等机制,因为人是靠不住的。

    前后端接口管理可以了解一下我们公司出的NEI - 接口管理平台


    ## 自动化


    作了这么多年程序猿的我,一直秉持的一个理念是:

    任何简单机械的重复劳动都应该让机器去完成。

    所以我也认为,前端工程化的很多脏活累活都应该交给自动化工具来完成。


    ### 图标合并


    • 不要再用PS拼雪碧图了,统一走Webpack吧;
    • 不要再用Icomoon了,统一走Webpack吧。

    ### 持续集成

    ### 自动化构建

    ### 自动化部署

    ### 自动化测试


    前端自动化测试能够提高代码质量、减少人肉测试等,这些优点是不言而喻的。

    市面上前端测试框架有很多,选择哪个都不会有太大问题,我们用的是:

    Karma + Mocha + Chai

    395 ​29 条评论
    ​分享
    ​收藏 ​感谢
    收起
    10 人赞同了该回答

    什么是"前端工程化"?

    先说概念:前端工程化是使用软件工程的技术和方法来进行前端项目的开发、维护和管理(曾经的前端开发可不是这样的,不然为什么要说工程"化"呢?)。

    "前端工程化"里面的工程软件工程,和我们一般说的工程是两个完全不同的概念。

    • 工程是个很泛泛的概念,你甚至可以认为建了个 Git 仓库就相当于新建了一个工程;
    • 软件工程的定义是"应用计算机科学理论和技术以及工程管理原则和方法,按预算和进度,实现满足用户要求的软件产品的定义、开发、和维护的工程或进行研究的学科"(GB/T11457-2006《信息技术 软件工程术语》)。

    很多时候,我们的前端确实是个工程,但并不是在以软件工程的方式方法去对待它。

    为什么会出现"前端工程化"这个概念?

    • "这个活动页面,给张图切一下就行了嘛";
    • "这个管理后台已经通过 XXX 脚手架生成了,页面稍微改改就行";
    • ...

    前端的开发工作在一些场景下被认为只是日常的一项简单工作,或只是某个项目的"附属品",并没有被当做一个"软件"而认真对待(无论是产品负责人还是开发者)。

    然而无论你如何对待它,也无法否定前端是一种 GUI 软件的事实,因此其也就必然遵循时间、质量、成本相互制约的特性。对于时间和成本的控制必然将导致最终产出倾向于出现"质量低"、"可维护性差"、"可用性差"等问题。

    过去我们以牺牲质量的方式换取时间和成本,现在趟了前辈们早已趟过的坑,然后发现还是要重新审视"前端"这一软件开发活动,并且使用软件工程这套早已存在的体系去对前端项目进行管理。

    如何做“前端工程化”?

    软件工程化关注的是性能、稳定性、可用性、可维护性等方面,一切以这些为目标的工作都是"前端工程化"。

    至于模块化、组件化、XX 打包方案、制定自动化流程、制定开发规范,这些都是"术"。可能现在是这样,过两年又变了。并且每个项目自身特点不同,所有这些"术"都不应该成为衡量一个项目是否做了"前端工程化"的标准。

    至于性能、稳定性、可用性、可维护性这些才是开发者需要持续关注的问题。

    作者:赵雨森
    链接:https://www.zhihu.com/question/24558375/answer/139920107
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    展开全文
  • 现实中的软件工程

    2021-02-04 10:51:43
     对于Borland来说,对软件开发语言(C、Java、Delphi)把握是其自身优势,所以Borland一直保持在语言上的中立,以寻求一种在不同平台上的开发者社群的支持最大。Borland积极的推动UML的标准,一方面可以使得...
  • 前端架构,前端工程化

    万次阅读 多人点赞 2018-01-31 10:49:28
    1.前端工程化 web应用复杂度的增加,特别是单页面应用的风靡。组件化,工程化,自动化成了前端发展的趋势。或者说一线的互联网公司就是这么做的。 每个前端团队都在打造自己的前端开发体系,这通常是一个东拼西凑,...

    前端架构:

    1.前端工程化

    web应用复杂度的增加,特别是单页面应用的风靡。组件化,工程化,自动化成了前端发展的趋势。或者说一线的互联网公司就是这么做的。
    每个前端团队都在打造自己的前端开发体系,这通常是一个东拼西凑,逐渐磨合的过程,在技术发展日新月异的今天,这样的过程真的是不可抽象和复制的么?本文希望能够通过系统的拆解前端开发体系为大家提供体系设计思路参考。

    前端工程的3个阶段


    第一阶段: 库/框架选型


    Animate.css 
    jQuery 
    vue.js 
    underscore.js 
    React.js 
    Backbone.js 
    Bootstarp 
    zepto.js 
    jade 
    normalize.css 
    compass 
    Angular.js 
    解决开发效率


    第二阶段: 简单构建优化


    选择构建工具,对代码进行压缩,校验,之后再以页面为单位进行简单的资源合并。


    第三阶段: JS/CSS模块化开发


    解决维护效率 
    js的模块化方案 
    ADM/CDM/UMD/ES6 Module


    css的模块化:less,sass。


    第四阶段: 前端是一个技术问题较少,工程问题较多的开发领域


    当我们要开发一款完整的Web应用时,前端将面临更多的工程问题,比如: 
    - 大体量:多功能、多页面、多状态、多系统; 
    - 大规模:多人甚至多团队合作开发; 
    - 高性能:CDN部署、缓存控制、文件指纹、缓存复用、请求合并、按需加载、同步/异步加载、移动端首屏CSS内嵌、HTTP 2.0服务端资源推送。


    组件化开发和资源管理


    组件化开发: 
    光有JS/CSS的模块化还不够,对于UI组件的分治也有着同样迫切的需求
    资源管理: 
    根据“增量”的原则,我们应该精心规划每个页面的资源加载策略,使得用户无论访问哪个页面都能按需加载页面所需资源,没访问过的无需加载,访问过的可以缓存复用,最终带来流畅的应用体验。
    由增量原则引申的前端优化技巧成为了性能优化的核心: 
    按需加载 
    延迟加载 
    预加载 
    请求合并


    浏览器的缓存


    静态资源管理系统 = 资源表 + 资源加载框架


    前端模块化框架肩负着模块管理和资源加载2个重要的功能


    webpack已经成为了前端打包构建的主流。


    开发框架则是形成了三国时代: 
    React , Vue, Ng


    移动端也以混合开发为主的方式,Native嵌入了Webview页面。


    SPA依靠首次加载的Loading动画,来掩盖一些页面加载性能的问题。


    用户验证问题,怎么来确认Native的用户身份,是用原来Web网站常用的session还是使用Native比较常用的token,但是不管用哪种,都需要Native帮忙来注入标识。


    前端业务重量化,场景多样化。 
    未来的趋势: 组件化。


    美团的工程化


    关于前端工程化,我看了美团团队的分享: 
    他们分享的前端化的实践总结: 
    1. 前端开发要自成体系,包括构建、部署及运维,不再和后端项目耦合,后端通过RESTful接口提供服务。 
    2. 避免重量级的框架,没有一个框架可以满足所有的业务场景。 
    3. 设计要分层,来应对需求和技术的变化。


    前端工程化项目分为3大模块: 
    1. Node服务,提供数据代理,路由,和服务器渲染,通过restful api和后端通信。 
    2. web应用开发,专注于web交互体验。 
    3. 前端运维:包含构建,测试,部署及监控等。


    Node服务:用于实现前后端分离,核心功能是实现数据代理中转,附带url路由分发和服务端渲染功能。
    Web应用开发:纯粹的前端模块,给予前端工程师极大的自由度进行技术选型,专注于Web交互体验的开发。
    前端运维:主要指前端项目构建和部署、工程质量(源码质量检查和测试等)及监控服务(日志、性能等)等工作。
    前后端分离: 
    - 为了前后端彻底的分离,引入Node服务层。 
    - 即在Node端通过HTTP请求得到数据后,Web端再通过Ajax的方式从Node端间接获取后端数据,Node服务起到“桥梁”的作用。 
    - 路由分发 
    - 服务器端渲染:Node服务端最后一个核心功能是渲染:输出 HTML Shell和 JSON。输出JSON字符串的用途是为了浏览器端能以Ajax形式动态获取数据,而输出的HTML内容则是我们Web应用的所需的HTML“壳子”。


    这主要是SPA的快速发展,前端的用户体验大幅提升。


    静态资源与Node端衔接: 
    - 前端静态资源构建工作与Node服务相互分离,Node服务在开启的过程中会读取前端构建生成的静态资源映射表。 
    - 静态资源映射表的生成: 
    - 预编译:ES6语法转义,css预编译器处理,源码质量审查,测试 
    - 模块依赖解析 
    - 压缩,静态资源版本号


    前端构建工具基本都提供静态资源映射表生成插件,比如构建工具Webpack就存在插件assets-webpack-plugin来实现该功能。


    鼓励遵循下面几条“约定”: 
    - Ajax请求从Node端代理,而非具体后端服务。 
    - 鼓励将JavaScript、CSS、HTML视为前端领域的“汇编”。 
    - 重视前端页面状态管理,推荐的方案有Redux、vuex及MobX等。 
    - 强调组件化,面向组件集开发。
    项目的脚手架,来搭建项目的开发环境。


    工程质量保证,在每次的commit,同个项目要求遵循同一套编码规范,并采用ESLint等工具进行约束,对于一些复用性高的核心组件也强制要求写测试。 
    甚至是接入单独的系统测试。


    总结


    前端工程化体系的引入,让前端开发能和原生App应用项目开发一样“自成体系”,脱离了对后端项目的依赖。基于“约定优于配置”、“按照约定写代码”的原则对Node层功能的设定能够降低沟通协调成本,构建、部署等工作的规范化,使前端技术人员的开发重点回归到Web应用的交互体验本身,回归到“纯粹”的前端研发。

    或许现在很多企业和团队尚未重视前端工程,或许前端工程在很多人眼里还只是“构建工具”的代名词,又或许未来前端领域的变革使得一切工程问题从根本上得到解决。不管怎样,我只是希望当下能认真的记录自己在前端工程领域的所见所想,与正在经历前端工程化改进,并被此过程困扰的同学交流心得。

    先说概念:前端工程化是使用软件工程的技术和方法来进行前端项目的开发、维护和管理(曾经的前端开发可不是这样的,不然为什么要说工程"化"呢?)。

    "前端工程化"里面的工程指软件工程,和我们一般说的工程是两个完全不同的概念。

    • 工程是个很泛泛的概念,你甚至可以认为建了个 Git 仓库就相当于新建了一个工程;
    • 软件工程的定义是:"应用计算机科学理论和技术以及工程管理原则和方法,按预算和进度,实现满足用户要求的软件产品的定义、开发、和维护的工程或进行研究的学科"(GB/T11457-2006《信息技术 软件工程术语》)。

    很多时候,我们的前端确实是个工程,但并不是在以软件工程的方式方法去对待它。

    为什么会出现"前端工程化"这个概念?

    • "这个活动页面,给张图切一下就行了嘛";
    • "这个管理后台已经通过 XXX 脚手架生成了,页面稍微改改就行";
    • ...

    前端的开发工作在一些场景下被认为只是日常的一项简单工作,或只是某个项目的"附属品",并没有被当做一个"软件"而认真对待(无论是产品负责人还是开发者)。

    然而无论你如何对待它,也无法否定前端是一种 GUI 软件的事实,因此其也就必然遵循时间、质量、成本相互制约的特性。对于时间和成本的控制必然将导致最终产出倾向于出现"质量低"、"可维护性差"、"可用性差"等问题。

    过去我们以牺牲质量的方式换取时间和成本,现在趟了前辈们早已趟过的坑,然后发现还是要重新审视"前端"这一软件开发活动,并且使用软件工程这套早已存在的体系去对前端项目进行管理。


    目前来说,Web业务日益复杂化和多元化,前端开发已经由以WebPage模式为主转变为以WebApp(eg:https://app.ft.com/)(httpshttps其实就是建构在SSL/TLS之上的 http协议,所以要比较https比http多用多少服务器资源,主要看SSL/TLS本身消耗多少服务器资源。)模式为主了。现在随便找个前端项目,都已经不是过去的拼个页面+搞几个jQuery插件就能完成的了。工程复杂了就会产生许多问题,比如:如何进行高效的多人协作?如何保证项目的可维护性?如何提高项目的开发质量?
    前端工程化是前端架构中重要的一环,主要就是为了解决上述大部分问题的。而前端工程本质上是软件工程的一种,因此我们应该从软件工程的角度来研究前端工程。那么前端工程化需要考虑哪些因素?本人总结经验,认为前端工程化主要应该从模块化、组件化、规范化、自动化四个方面来思考,下面一一展开。## 模块化简单来说,模块化就是将一个大文件拆分成相互依赖的小文件,再进行统一的拼装和加载。只有这样,才有多人协作的可能。### JS的模块化在ES6之前,JavaScript一直没有模块系统,这对开发大型复杂的前端工程造成了巨大的障碍。对此社区制定了一些模块加载方案,如CommonJS、AMD和CMD等,某些框架也会有自己模块系统,比如Angular1.x。现在ES6已经在语言层面上规定了模块系统,完全可以取代现有的CommonJS和AMD规范,而且使用起来相当简洁,并且有静态加载的特性。规范确定了,然后就是模块的打包和加载问题:1. 用Webpack+Babel将所有模块打包成一个文件同步加载,也可以打成多个chunk异步加载;2. 用SystemJS+Babel主要是分模块异步加载;3. 用浏览器的<script type="module">加载目前Webpack远比SystemJS流行。Safari已经支持用type="module"加载了。### CSS的模块化虽然SASS、LESS、Stylus等预处理器实现了CSS的文件拆分,但没有解决CSS模块化的一个重要问题:选择器的全局污染问题。按道理,一个模块化的文件应该要隐藏内部作用域,只暴露少量接口给使用者。而按照目前预处理器的方式,导入一个CSS模块后,已存在的样式有被覆盖的风险。虽然重写样式是CSS的一个优势,但这并不利于多人协作。为了避免全局选择器的冲突,各厂都制定了自己的CSS命名风格:BEM风格;

    Bootstrap风格;Semantic UI风格;我们公司的NEC风格;...但这毕竟是弱约束。选择器随着项目的增长变得越多越复杂,然后项目组里再来个新人带入自己的风格,就更加混乱了。所以我很赞同这句话:与其费尽心思地告诉别人要遵守某种规则,以规避某种痛苦,倒不如从工具层面就消灭这种痛苦。从工具层面,社区又创造出Shadow DOM、CSS in JS和CSS Modules三种解决方案。Shadow DOM是WebComponents的标准。它能解决全局污染问题,但目前很多浏览器不兼容,对我们来说还很久远;CSS in JS是彻底抛弃CSS,使用JS或JSON来写样式。这种方法很激进,不能利用现有的CSS技术,而且处理伪类等问题比较困难;CSS Modules仍然使用CSS,只是让JS来管理依赖。它能够最大化地结合CSS生态和JS模块化能力,目前来看是最好的解决方案。Vue的scoped style也算是一种。
    ### 资源的模块化Webpack的强大之处不仅仅在于它统一了JS的各种模块系统,取代了Browserify、RequireJS、SeaJS的工作。更重要的是它的万能模块加载理念,即所有的资源都可以且也应该模块化。资源模块化后,有三个好处:依赖关系单一化。所有CSS和图片等资源的依赖关系统一走JS路线,无需额外处理CSS预处理器的依赖关系,也不需处理代码迁移时的图片合并、字体图片等路径问题;资源处理集成化。现在可以用loader对各种资源做各种事情,比如复杂的vue-loader等等。项目结构清晰化。使用Webpack后,你的项目结构总可以表示成这样的函数:
    dest = webpack(src, config)## 组件化首先,组件化≠模块化。好多人对这两个概念有些混淆。模块化只是在文件层面上,对代码或资源的拆分;而组件化是在设计层面上,对UI(用户界面)的拆分。从UI拆分下来的每个包含模板(HTML)+样式(CSS)+逻辑(JS)功能完备的结构单元,我们称之为组件。其实,组件化更重要的是一种分治思想。Keep Simple. Everything can be a component.
    这句话就是说页面上所有的东西都是组件。页面是个大型组件,可以拆成若干个中型组件,然后中型组件还可以再拆,拆成若干个小型组件,小型组件也可以再拆,直到拆成DOM元素为止。DOM元素可以看成是浏览器自身的组件,作为组件的基本单元。传统前端框架/类库的思想是先组织DOM,然后把某些可复用的逻辑封装成组件来操作DOM,是DOM优先;而组件化框架/类库的思想是先来构思组件,然后用DOM这种基本单元结合相应逻辑来实现组件,是组件优先。这是两者本质的区别。其次,组件化实际上是一种按照模板(HTML)+样式(CSS)+逻辑(JS)三位一体的形式对面向对象的进一步抽象。所以我们除了封装组件本身,还要合理处理组件之间的关系,比如(逻辑)继承、(样式)扩展、(模板)嵌套和包含等,这些关系都可以归为依赖。其实组件化不是什么新鲜的东西,以前的客户端框架,像WinForm、WPF、Android等,它们从诞生的那天起就是组件化的。而前端领域发展曲折,是从展示页面为主的WebPage模式走过来的,近两年才从客户端框架经验中引入了组件化思想。其实我们很多前端工程化的问题都可以从客户端那里寻求解决方案。目前市面上的组件化框架很多,主要的有Vue、React、Angular 2、我们公司 @郑海波 的Regular、Avalon等。你感兴趣可以都研究一下,选择一套中意的。其实Vue文档中的对比其他框架一文已经讲得很详细了。## 规范化模块化和组件化确定了开发模型,而这些东西的实现就需要规范去落实。规范化其实是工程化中很重要的一个部分,项目初期规范制定的好坏会直接影响到后期的开发质量。我能想到的有以下一些内容:目录结构的制定编码规范前后端接口规范文档规范组件管理Git分支管理Commit描述规范定期CodeReview视觉图标规范...其中编码规范最好采取ESLint和StyleLint等强制措施,配置git hooks可以实现Lint不过不能提交代码等机制,因为人是靠不住的。前后端接口管理可以了解一下我们公司出的NEI - 接口管理平台。## 自动化作了这么多年程序猿的我,一直秉持的一个理念是:任何简单机械的重复劳动都应该让机器去完成。
    所以我也认为,前端工程化的很多脏活累活都应该交给自动化工具来完成。### 图标合并不要再用PS拼雪碧图了,统一走Webpack吧;
    不要再用Icomoon了,统一走Webpack吧。### 持续集成### 自动化构建### 自动化部署### 自动化测试前端自动化测试能够提高代码质量、减少人肉测试等,这些优点是不言而喻的。市面上前端测试框架有很多,选择哪个都不会有太大问题,我们用的是:Karma + Mocha + Chai

    非要介绍的话,那前端工程化就是这些:
    1. 高性能
    2. 稳定性(reliability)
    3. 可用性(usability)
    4. 可维护性(maintainability)
    5. 可访问性(accesibility)

    每个前端团队都在打造自己的前端开发体系,这通常是一个东拼西凑,逐渐磨合的过程,在技术发展日新月异的今天,这样的过程真的是不可抽象和复制的么?本文希望能够通过系统的拆解前端开发体系为大家提供体系设计思路参考。什么是前端集成解决方案


    前端集成解决方案,英文翻译为 Front-end Integrated Solution,缩写fis,发音[fɪs]
    前端集成解决方案并不是一个新词汇,将这个词拆开来看,我们能得到:


    前端:指前端领域,即web研发中常用的浏览器客户端相关技术,比如html、js、css等
    集成:将一些孤立的事物或元素通过某种方式改变原有的分散状态集中在一起,产生联系,从而构成一个有机整体的过程。[1]
    解决方案:针对某些已经体现出的,或者可以预期的问题,不足,缺陷,需求等等,所提出的一个解决问题的方案,同时能够确保加以有效的执行。[2]
    总结来说,前端集成解决方案就是:


    将前端研发领域中各种分散的技术元素集中在一起,并对常见的前端开发问题、不足、缺陷和需求,所提出的一种解决问题的方案。
    前端领域有哪些技术元素


    前端行业经历了这么长时间的发展,技术元素非常丰富,这里列举出一般web团队需要用到的技术元素:

    开发规范:包括开发、部署的目录规范,编码规范等。不要小瞧规范的威力,可以极大的提升开发效率,真正优秀的规范不会让使用者感到约束,而是能帮助他们快速定位问题,提升效率。
    模块化开发:针对js、css,以功能或业务为单元组织代码。js方面解决独立作用域、依赖管理、api暴露、按需加载与执行、安全合并等问题,css方面解决依赖管理、组件内部样式管理等问题。是提升前端开发效率的重要基础。现在流行的模块化框架有requirejs、seajs等。
    组件化开发:在模块化基础上,以页面小部件(component)为单位将页面小部件的js、css、html代码片段放在一起进行开发、维护,组件单元是资源独立的,组件在系统内可复用。比如头部(header)、尾部(footer)、搜索框(searchbar)、导航(menu)、对话框(dialog)等,甚至一些复杂的组件比如编辑器(editor)等。通常业务会针对组件化的js部分进行必要的封装,解决一些常见的组件渲染、交互问题。
    组件仓库:有了组件化,我们希望将一些非常通用的组件放到一个公共的地方供团队共享,方便新项目复用,这个时候我们就需要引入一个组件仓库的东西,现在流行的组件库有bower、component等。团队发展到一定规模后,组件库的需求会变得非常强烈。
    性能优化:这里的性能优化是指能够通过工程手段保证的性能优化点。由于其内容比较丰富,就不在这里展开了,感兴趣的同学可以阅读我的这两篇文章 [1] [2]。性能优化是前端项目发展到一定阶段必须经历的过程。这部分我想强调的一点是 性能优化一定是一个工程问题和统计问题,不能用工程手段保证的性能优化是不靠谱的,优化时只考虑一个页面的首次加载,不考虑全局在宏观统计上的优化提升也是片面的。
    项目部署:部署按照现行业界的分工标准,虽然不是前端的工作范畴,但它对性能优化有直接的影响,包括静态资源缓存、cdn、非覆盖式发布等问题。合理的静态资源资源部署可以为前端性能带来较大的优化空间。
    开发流程:完整的开发流程包括本地开发调试、视觉效果走查确认、前后端联调、提测、上线等环节。对开发流程的改善可以大幅降低开发的时间成本,工作这些年见过很多独立的系统(cms系统、静态资源推送系统)将开发流程割裂开,对前端开发的效率有严重的阻碍。
    开发工具:这里说的工具不是指IDE,而是工程工具,包括构建与优化工具、开发-调试-部署等流程工具,以及组件库获取、提交等相关工具,甚至运营、文档、配置发布等平台工具。前端开发需要工具支持,这个问题的根本原因来自前端领域语言特性(未来我会单独写一篇文章介绍前端领域语言缺陷问题)。前端开发所使用的语言(js、css、html)以及前端工程资源的加载与定位策略决定了前端工程必须要工具支持。由于这些工具通常都是独立的系统,要想把它们串联起来,才有了yeoman这样的封装。前面提到的7项技术元素都直接或间接的对前端开发工具设计产生一定的影响,因此能否串联其他技术要素,使得前端开发形成一个连贯可持续优化的开发体系,工具的设计至关重要。
    以上8项,1-3是技术和业务相关的开发需求,4是技术沉淀与共享需求,5-8是工程优化需求。


    经过这些年的工程领域实践,个人觉得以上8项技术元素应该成为绝大多数具有一定规模的前端开发团队的标配。各位读者可以对照自己团队现状来思考一下团队开发体系还有哪些环节需要完善。


    攒一套前端集成解决方案


    不难发现,其实其他领域工程也基本需要解决上述这些问题。前端由于其领域语言的独特性,使得前端工程在解决这些问题上跟其他工程有很大区别,因此至今也没有形成一套比较好的理论体系指导团队实践前端工程。
    仔细观察过一些团队的技术体系形成过程,大家都在努力拼凑上述8项技术元素的具体解决方案。单独观察每一项技术点,你或许会觉得都能各自找到已有的实现,但我要说,把所有8项技术点无缝的串联起来,是一项非常有挑战的工作,你信么?相信真正经历过这样事情的同学能明白我说的串联成本问题。


    假设我们希望实践一套完整的前端集成解决方案,好了,如果我们单独去看每一项技术点,都可能会找来一两个现成的东西,假设我们东拼西凑的找全了所有8项技术要素对应的具体实现。接下来要用了,它们能很完整流程的跑起来么?


    正如前面的贴图展示的那样,所有的技术点都有一定的内在联系:


    模块化开发涉及到性能优化、对构建工具又有一定的配套实现要求,也会影响开发规范的定制
    组件化开发应该基于模块化框架来加载其他依赖的组件,如果组件化框架自带模块管理功能,那么就可能导致工程性的性能优化实现困难
    组件库应该与组件化开发配套,组件仓库中的组件都应该按照相同的标准来实现,否则下载的组件不具有可复用性、可移植性,就是去了仓库的意义
    我们设计的开发规范工具是否能很容易的实现,如果部署上有特殊要求,工具是否能很容易的做出调整,而不是修改规范。
    工具是否能提供接入公司已有流程中的接口,比如命令调用,如果工具需要一些系统环境支持,公司的ci流程中是否能支持等问题。
    前端领域语言的特点决定了攒一套集成解决方案有很高的实现成本。因为前端语言缺少包、导入、模块等开发概念,这使得各个技术点的解决方案在设计的时候都是考虑被独立使用的情况下如何工作,因此或多或少的会延伸自己的职责。比如模块化框架要附属构建工具,甚至要求后端服务(比如combo),组件化框架自带模块化框架,构建工具自带部署规范等,这就大大提高了将各个技术要素融合起来的成本。


    总之,前述的8项技术要素之间有许多联系,这就为打造一套完整连贯的前端集成解决方案带来了较大的挑战。如何兼顾规范、性能、框架、流程、部署等问题,就不是东拼西凑那么简单的事了。后面我会单独撰文介绍如何实现一套集成解决方案。

    1、关于组件化和模块化,这个粒度实在是不好拿捏,模块可以很大,也可以很小,小到一个函数成一个模块,所以我觉得模块应该主要是通用工具、api、类的封装,而组件更多的是业务功能、UI块的封装


    2、关于组件仓库,其实bower、component之类的并不够,还有文档的生成与管理,使用别人写的代码,最快入手的就是看文档,其次才是看代码


    3、还有,测试。纯工具和api之类的模块,很容易自动化测试,蛋是到了组件层面,设计业务逻辑、UI什么的,自动化太难了,还得靠人肉

    fis-conf.js所在目录即整个工程目录,所以如果整个目录下有很多文件,fis在构建的时候是会全部文件收集起来再作处理的,所以文件查找会成为时间大头。但一般情况下前端工程也不会出现个别多的文件,如果你的工程里混有一些非前端代码,比如nodejs的node_modules等,建议用 fis.config.set('project.exclude', /正则/); 来排除掉。


    当然,有些前端工程确实特别大,我们在百度的时候采用的做法是把一个网站的代码拆成多个子系统,每个子系统一个fis-conf.js,每个子系统一个svn仓库,子系统可以独立编译、独立上线发布。这样系统的并行开发程度就提高了很多。子系统中有一个特殊的子系统,叫公共资源子系统(common),其他子系统不允许有相互的资源依赖,只允许它们唯一依赖公共资源子系统。而依赖的功能是通过模块化框架实现的。


    全部放在一起也没有什么问题,就是构建速度差一些,代码合并会多一些,规模上会有一定的瓶颈。分开来也会有一些小问题,而且框架设计成本略高,有时候甚至要在后端模板层实现一套后端的模块化框架,略麻烦。


    你用的spmx是我之前一个下午随便搞的,不是很严谨,也没有充分考虑到seajs的设计理念,所以可能用起来效果稍差一些,如果有需要可以在spmx的issues里提,我尽量满足,或者给你们开权限,以及npm上的发布权限,如果可以将它发展成一个强大的解决方案,那真是一件非常不多的事情。

    关于前端工程的核心问题


    说的有点大,其实呢,前端工程只有两个核心问题:


    一个是 资源定位,另一个是 模块化开发。
    fis从你的描述中我已经感觉你们用的比较好了,这里我可以做一个总结和补充:

    前端工程的所有工作都是围绕着这两个核心问题展开的。资源定位的主要思想就是将 工程路径 转换为 部署路径,也就是把相对路径变成绝对路径并且加上md5戳和域名。这样做的目的是解决静态资源缓存更新的问题,同时为模块化开发这个问题做准备。因为只有将所有相对路径转换成绝对路径才能实现模块的独立性,模块才能被任何地方使用都不用担心里面资源加载的问题。你所喜欢的内嵌功能,也是要建立在路径转换的基础上,因为内嵌会改变路径关系,绝对化处理可以让任意文件间的内嵌成为可能。


    模块化开发呢,在解决了资源定位的前提下,核心问题就是依赖管理和加载了。fis最推崇的做法就是:


    尽量依靠框架实现,最少依赖构建工具处理。
    就是说,尽量不要让构建工具做太多事情,因为那很黑盒,fis的设计是,构建工具只负责生成依赖关系表,这就足够了,然后框架自己决定什么时候该加载哪些资源,表的关系可以让框架加载时完成按需、请求合并等需求。


    基于上述设计理念,能发挥fis最大价值的地方就在于如何利用静态资源依赖表来实现一个合理的模块化框架。
    spmx是我根据seajs的模块化设计而做的适配,其实可以更精简一些的。我到UC之后根据他们的业务特点与小伙伴 @hinc 又设计开发了一个模块化框架,并以此衍生出了一套解决方案,可以作为你们的参考。今年还做了一个分享,可以看看:

    前端工程可以在 前端开发,性能优化,持续集成,自动部署、模块生态、甚至 CMS运营系统 中都能发挥功效,其中CMS运营系统的前端工程化实践我们还在探索中,你可以看一下自己团队还有哪些需要补充。


    模块化框架和工具做好了之后,就在模块化框架里做性能优化,比如请求合并、按需加载、localstorage缓存(移动端)等,然后就是开发过程和持续集成与部署结合,内网搭建jenkins,提交即构建,构建结果存放到代码仓库 ,然后实现部署推送。接下来将历往项目中的通用模块抽取出来,放到生态里,比如GitHub上,然后在开发工具中集成一个install的小工具,用于项目初期获取这些模块,可以进一步提高效率。最常见的例子就是处理css合并了,css中经常会有图片资源的路径引用,如果保留相对路径,会对css文件合并带来很多负担。有这么几种情况:


    代码中使用相对路径,合并后不做任何路径处理。这种情况下,有两种开发模式:
    所有css在同级维护,构建中合并css,并且合并后的css也是同级目录。优点是不依赖工具,简单直观。缺点是不能把css和对应的html、js维护在一起,而且项目变大之后一个目录下都是css文件,又不能分二级,很恶心。
    所有css中写图片路径的时候,都是写那个合并后文件的相对路径。优点是css可以分级,但是写资源地址要时刻想着是在另外一个文件中使用的,这和写绝对路径有什么分别?而且IDE不友好,很多IDE会报错,别小看这个,很多程序员都是神经质,烦。
    代码中使用相对路径,合并后根据合并后生成的文件的位置做相对路径计算。解决了1.2中的问题,通过工具重新计算相对路径。缺点是同一个文件只能被合并,不能被其他方式复用,否则会带来相对路径不一致问题。而且这都用上工具了,为啥不直接转成绝对路径。
    代码中使用相对路径,合并后替换成绝对路径。先说缺点,依赖工具,没了。然后说说优点:
    开发中使用相对路径,各种直观与友好
    没有规范,组件任意移植,部署路径都能正确
    目录任意分级,可以实现完全的组件化/模块化开发
    有些时候,我们可能需要把css的文件嵌入到js中,通过js动态插入到页面上,或者嵌入到html的style标签中使用,转换成绝对路径永远不用担心资源找不到的情况
    combo随便,还是因为资源定位都是绝对路径。
    js也有相同问题,当你在js中想要通过逻辑加载一个图片、加载一个css文件,加载其他js文件的时候,使用绝对路径可以让这个js无论在哪个页面,无论在哪一级路径下都能正确运行,有百利而无一害。(其实路径会很长,算是一害)。


    有了绝对路径,资源的合并、复用、移动才能不被运行时的文档路径限制。我觉得,绝对路径才叫资源定位,才是真实的完整的定位信息,相对路径更像是一种“变量”,它使得同一段代码在不同的路径下执行会有可能发生定位错误。


    其实前端页面也是一种GUI软件,传统的桌面软件,所有程序资源都部署(安装)在客户端,所以从来没有在资源上遇到过想前端的这种的定位概念。前端程序资源是部署在其他设备上的,通过运行时加载到客户端来执行,这种程序资源部署上的差异我觉得正是前端工程与GUI软件工程的最大区别,几乎所有前端开发、维护、模块化、性能优化等特殊的工程问题都是围绕着这个差异点产生的。

    展开全文
  • 本文探讨了为什么工科学生成为并继续致力于适得其反的实践。 我们的发现表明,线人在工科学校任职期间所进行的工作实践与“好工程师”所做的刻板印象相... 我们利用这些发现提出对职业社会理论和工程工作管理的启示。
  • 对于海量的散点数据,尤其是石油地震数据,一般的DeIaunay三角网格生成算法不再适用,必须寻求一种快速的Delaunay三角网格生成算法,以满足海量数据的三维建模需求。笔者在传统的分割一合并算法基础上。对已经块分割...
  • 针对红外图像对比度低、细节较差,且一般是黑白图像,不适宜于人眼观察,提出一种利用局部线性映射方法(LLE)的红外成像彩色方法。该方法寻求灰度空间到色彩空间的映射,实现红外图像到彩色红外图像的转变,先将目标红外...
  • 从分析过去存储过程的测试方法中存在的问题入手,逐步阐述我们分析问题,寻找问题根源和寻求解决办法的过程,介绍我们开发这个基于JUnit的存储过程自动测试的Eclipse插件的过程和存储过程单元测试的解决方案。...
  • 寻求简单有效的更改管理方法,对提高信息实施过程的效率和成功率具有重要意义。在设计结构矩阵(DSM)的基础上,通过引入外部影响因素,建立了扩展DSM.在分析扩展DSM中各元素之间关系的基础上,提出了信息实施过程更改...
  • 要摒弃传统加工技术,寻求新技术、新思维及一体包装解决方案;降低整个产品包装作业、物流、仓储系统的运作成本,使产业链上的各个节点均能受益。这种包装理念和实施,是市场经济全球竞争的必然。
  • 层次方法以逐层精特征的方式寻求特征冗余和信息漏选之间的平衡。实际数据集上的实验结果表明所提方法的迷惑恶意代码检测率较高,与传统特征选择方法相比,具有所需训练样本集小、泛化能力强的优点。
  • 长期以来,我国传媒存在同质现象,要想造就一个有竞争力的传媒,必须不断寻求自身的独特个性,凭借差异的理念和操作思路在市场竞争中获取独特的优势,做到人无我有,人有我新。
  • 目的在于寻求判断这种转变的方法。在将分数布朗运动(fBM)作为压力波动信号数学模型的基础上,采用 R/S分析法从信号的时间序列中提取出Hurst指数,并观察它在不同表观气速下的变化。实验结果表明,信号的Hurst指数在...
  • 一部当代中国工程师群体形成与发展的历史,不仅是工程技术历史的投射,也是中国在新时期寻求现代之路的缩影。中国工程师在培养科技人才、扩展技术知识以及加速我国工业进程方面,都取得了非常大的成就。共和国成立...
  • 针对该问题,采用博弈论理论,构建一种网络制造环境下任务调度的非合作博弈模型,将对任务调度的优化求解转化为对寻求非合作博弈模型的Nash均衡解。同时,采用遗传算法实现了对非合作博弈模型模型的具体解算,系统...
  • 针对计算机网络规模滞后、服务类型单一和服务质量...仿真结果表明:算法实现最小新增链路,使改进后拓扑仅略大于理想拓扑(Harary拓扑),88%的流量通过少跳数传输,且各链路带宽分配均匀(均方差σ=1.1)。从而使算
  • 随着房地产暴利时代的结束,房地产行业开始逐步进入利润常态的后房地产时代,为寻求新的利润增长点,地产公司开始将注意力转向物业管理,尝试通过建设移动信息的智慧型社区,来改造传统的物业管理模式,并借助...
  • ERP人才培养工程项目背景 在全球经济快速发展与信息高度普及的环境下高素质信息应用型人才成为企业寻求发展的关键性人才队伍其中具备企业资源规划以下简称ERP设计咨询实施服务及运行管理能力的专业人才更受到...
  • 酒店管理系统阿尔巴尼亚的旅游业经历了快速的增长,这是由于越来越多的外国游客寻求探索文化和考古遗产以及沉迷于众多令人叹为观止的风景。 从北部山区到西南部异国情调的海滩,由于住宿需求的不同,多样的景观给...
  • 住宅建筑在施工阶段因使用机电设备耗用大量的能源,会产生大量碳排放,阻碍了建筑行业的低碳发展.住宅建筑施工阶段的碳排放量化是寻求建筑低碳发展路径的基础,通过确定电力和化石能源的碳排放因子,推导碳排放...
  • 熟练掌握二叉树线索过程和在中序线索树上找给定结点前驱和后继方法 教学关键 掌握二叉树遍历包含中根遍历前根遍历和后根遍历方法 教学难点 了解什么是线索中序线索二叉树结构特征及寻求某结点前驱和后继方法 ...
  • 软件工程期末复习二

    千次阅读 2020-02-10 15:48:12
    以下是我的一位同学整理的,标注是我做的,希望好好学习,顺利通过考试,软件工程最重要的是画图题。 1.什么是软件危机,它有哪些典型表现? 答: 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重...
  • 软件工程知识点总结

    千次阅读 多人点赞 2022-04-11 13:24:09
    文章目录一、软件工程概述1. 定义2. 软硬件失效3. 软件危机4. 软件工程三要素5. 软件工程目标6. 软件工程研究内容7. 软件工程知识体系二、软件生命周期模型2.1 软件工程过程:PDCA循环2.2 软件生命周期 software ...
  • 2016年,SDCC(中国软件开发者大会)相继走进了上海、深圳、成都、杭州各地。11月18日-20日将在北京完美...周俊鹏目前主要负责前端工程、前后端分离解决方案的研究探索与开发工作,是58到家前端工程解决方案boi开发者。
  • 工程思维的培养

    千次阅读 2019-11-09 10:29:44
    我们应当注重对工程思维的培养,在很多方面需要对工程思维的投入。...通常就工程思维与创造性活动相联系,工程思维涉及寻求多约束问题的合理解决方案。尽管人类没有完全理解创造性思维和过程,但还是可以对创...
  • 目前,我国服装企业正在寻求品牌经营,ZARA为我们提供了知识密集型、信息密集型、(通讯)技术密集型为特征的新兴大众品牌生存和发展的独特榜样。我国服装企业可以从ZARA经营模式的选择、供应链的整合等方面学习到新的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 33,852
精华内容 13,540
热门标签
关键字:

寻求工程化