Web前端最新DevOps进阶(二):DevOps 发展史_第二代devops系统,2024年最新前端开发面试题

总结

我在成长过程中也是一路摸爬滚打,没有任何人的指点,所以走的很艰难。例如在大三的时候,如果有个学长可以阶段性的指点一二,如果有已经工作的师兄可以告诉我工作上需要什么,我应该前面的三年可以缩短一半;后来去面试bat,失败了有5、6次,每次也不知道具体是什么原因,都是靠面试回忆去猜测可能是哪方面的问题,回来学习和完善,当你真正去招人的时候,你就会知道面试记录是多么重要,面试官可以从面试记录里看到你的成长,总是去面试,总是没有成长,就会被定义为缺乏潜力。

开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

image
image

  • 我们的首要任务是通过尽早地、持续地交付可评价的软件来使客户满意。
  • 乐于接受需求变更,即使是在开发后期也应如此。敏捷过程能够驾驭变化,从而为客户赢得竞争优势。
  • 频繁交付可使用的软件,交付间隔越短越好,可以从几个星期到几个月。
  • 在整个项目开发期间,业务人员和开发人员必须朝夕工作在一起。
  • 围绕那些有推动力的人们来构建项目。给予他们所需的环境和支持,并且信任他们能够把工作完成好。
  • 与开发团队以及在开发团队内部最快速、有效的传递信息的方法就是,面对面的交谈。
  • 可使用的软件是进度的主要衡量指标。
  • 敏捷过程提倡可持续发展。出资人、开发人员以及使用者应该总是共同维持稳定的开发速度。
  • 为了增强敏捷能力,应持续关注技术上的杰出成果和良好的设计。
  • 简洁——最大化不必要工作量的艺术——是至关重要的。
  • 最好的架构、需求和设计都源自自我组织的团队。
  • 团队应该定期反思如何能变得更有战斗力,然后相应地转变并调整其行为。

敏捷宣言是为银河系带来和平以及维护各自的平衡所迈出的很重要一步。在很长的时间里,相比此前基于流程和机械化的方式,这是第一次基于文化和“人性”来将不同的关键项目干系人连接在一起的方式。人们开始互相交流,进行基本的碰头会议,并开始不断的交流意见和看法。他们开始意识到他们是有着很多比想象中还多的共同点,客户也开始成为他们之中的一员,而不再是像以往一样只是往项目砸钱然后开始求神拜佛祈求一切顺利如愿。
在这里插入图片描述

尽管前面还是有不少的障碍需要克服,但是未来已经光明了许多。敏捷意味着开放和拥抱(需求)改变。但是,如果改变过多的话,人们就很难专注到最终的目标和交付上来。此时精益软件开发就开始破土而出了。

三、精益软件开发

因为对精益软件开发的着迷以及为了达成放逐和驱赶风险的目的,一些程序员的子孙们就开始探首窗外,开始向软件之外的行业进行取经。他们从一家主要的汽车生产商身上找到了救赎,丰田生产系统在精益上面的成就是不可思议的,同时它们精益生产的经验也是很容易应用到软件开发上来的。

精益有以下7个原则:

  • 杜绝浪费
  • 内建质量
  • 创建知识(放大学习)
  • 延迟决策(尽量延迟决定)
  • 快速交付
  • 尊重人员(团队授权)
  • 全局优化

将这些放到敏捷上去,精益原则就能让人们在从精神上关注做正确的事情,同时还能够让整个开发流程拥有足够的弹性。一旦敏捷精益软件开发被软件开发团队采纳,那么下一步就是把这一套原则应用到IT团队上来。把IT也纳入到整体战略上,然后我们就来到了DevOps跟前了!

四、进入DevOps :高速公路的三条车道

老一派的软件开发团队成员会包含业务分析员、系统架构师、前端开发者、后端开发者、测试员等等。优化如敏捷和精益原则等的软件开发流程的关注点就在这些地方。比如,软件一旦达到”可以生产“的程度,就会发到系统工程师、发布工程师、DBA、网络工程师,安全专家这些“运维人员”的手上。这里该如何将横在Dev(开发)和Ops(运维)之间的鸿沟给填平,这就是DevOps的主要关注点了。

DevOps是在整个IT价值流中实施精益原则的结果。IT价值流将开发延伸至生产,将由程序员这个遥远的祖宗所繁衍的所有子孙给联合在一起。

这是来自Gene KimDevOps的最好解析,如果你还没有看过他的《凤凰项目》这本书的话,我建议你真的该好好花时间看看。

你不应该重新招聘DevOps工程师,且DevOps也不应该是一个IT的新部门。DevOps是一种文化,一种理念,且是和IT糅合成一体的。世间没有任何工具可以把你的IT变成一个DevOps组织,也没有任何自动化方式可以指引你该如何为你的客户提供最大化的效益。

DevOps通常作为下面这三个方式而为人所熟知,而在我眼里我是把它们看成是一条高速公路上的三条车道。你从第一条车道开始,然后加速进入到第二条车道,最终在第三车道上高速行驶。

车道1 - 系统级别的整体效率考量是最主要的关注点,这超过对系统中任何一个单独个体元素的考虑;

车道2 - 确保能提供持续不断的反馈循环,且这些反馈不被忽视。

车道3 - 持续的学习和吸取经验,不停的进步,快速的失败。

4.1 车道1:获取速度

要采纳DevOps的原则,理解整个运作系统的重要性并对工作事项进行合适的优先级排序是组织首先要学的事情。在整个价值流中不能允许任何人产生瓶颈并降低整个工作流程。
车道1.jpg
确保工作流程的不可中断是身处流程中的所有成员的终极目标。无论一个成员或者团队的角色是什么,他们都必须力图对整个系统进行深入的理解。这种思维方式对质量会有直接影响,因为缺陷永远不会被下放到“下游“中,这样做的话将会导致瓶颈的产生。

确保整个工作流程不会被瓶颈堵塞住还不够。一个高产的组织应该时常考虑该如何提升整个工作流程。有很多方法论可以做到这一点,你不妨去看下“约束理论”、“六西格玛”、精益或者丰田生产系统

DevOps原则并不关心你身处哪个团队,你是否是系统架构师、DBA、QA或者是网络管理员。相同的规则覆盖所有的成员,每个成员都应该遵循两个简单的原则:

  • 保持系统运作流程不可中断;
  • 随时提升和优化工作流程;
4.2 车道2:换挡加速

不可中断的系统流程是定向的,且预期是从开发流向运维。在一个理想的世界中,这就意味着快速的开发出高质量的软件,部署,并为客户提供价值。

但是,DevOps并非乌托邦式的理想国。如果单向的交付方式是可行的话,我们的瀑布模式早就能胜任了。评估可交付产品和整个流程中的交流对确保质量是至关重要的。这里首个必须实现的"面向上游"的交流通道是从OpsDev
在这里插入图片描述
我们独自意淫是件非常容易的事情,但是获取别人的反馈和提供反馈给别人才是探究事实真相的正确方法。下游的每一步(反馈)都必须紧跟着有一个上游的确定。

你如何建立反馈循环机制并不重要。你可以邀请开发人员加入技术支持团队的会议,或者将网络管理员放到Sprint计划会议中去。一旦你的反馈机制就绪,反馈能够被接收并被处理,你就已经可以说是走到了DevOps高速车道上来了。

4.3 车道3:飞速前进

DevOps这条快速车道并不适合意志脆弱的人。为了进入这条车道,你的组织必须要足够的成熟。这里充满了冒险和对失败教训的学习,不断的尝试,并认同屡败屡战和不断的实践是走向成功这条康庄大道的前提条件。在这里你应该会经常听到”套路“这个词,这是有原因的,不断的训练和重复所以能培养出大师,是因为其让复杂的动作常规化。

但是在你要将这些复杂的动作连接起来之前,你很有必要先去掌握好每一个单独步骤。

“适合大师的动作并不适合新手,脱胎换骨之前你必须先要明白道的真谛。“
在这里插入图片描述

DevOps的第三个方式/快速车道包括每天分配时间来持续的进行试验,时常的奖励敢于冒险的团队,并将缺陷特意引入到运作系统上来以增加系统的抗击打能力。

为了确保你的组织能够消化好这些方法,你必须在每个团队之间建立好频繁的反馈循环,同时需要确保所有的瓶颈都能够及时的被清理掉,并确保整个系统的运作流程是不可中断的。

实施好这些措施可以让你的组织时刻保持警惕,并能够快速且高效的应对挑战。

五、概要:DevOps清单

下面是一张你可以用来检验你的组织对DevOps应用情况的清单,当然你也可以在文章评论后面给出你的观点。

  • 开发团队和运维团队之间没有障碍,两者皆是DevOps统一流程的一部分。
  • 从一个团队流到另一个团队的工作都能够得到高质量的验证。
  • 工作没有堆积,所有的瓶颈都已经被处理好。
  • 开发团队没有占用运维团队的时间,因为部署和维护都是处于同一个时间盒里面的。
  • 开发团队不会在周五下午5点后把代码交付进行部署,剩下运维团队周末加班加点来给他们擦屁股。
  • 开发环境标准化,运维人员可以很容易將之扩展并进行部署。
  • 开发团队可以找到合适的方式交付新版本,且运维团队可以轻易的进行部署。
  • 每个团队之间的通信线路都很明确。
  • 所有的团队成员都有时间去为改善系统进行试验和实践。
框架相关

原生JS虽能实现绝大部分功能,但要么就是过于繁琐,要么就是存在缺陷,故绝大多数开发者都会首选框架开发方案。现阶段较热门是React、Vue两大框架,两者工作原理上存在共通点,也存在一些不同点,对于校招来说,不需要两个框架都学得特别熟,一般面试官会针对你简历中写的框架进行提问。

在框架方面,生命周期、钩子函数、虚拟DOM这些基本知识是必须要掌握的,在学习的过程可以结合框架的官方文档

开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

Vue框架

知识要点:
1. vue-cli工程
2. vue核心知识点
3. vue-router
4. vuex
5. http请求
6. UI样式
7. 常用功能
8. MVVM设计模式

React框架

知识要点:
1. 基本知识
2. React 组件
3. React Redux
4. React 路由

8. MVVM设计模式

[外链图片转存中…(img-OY3vjbSZ-1715902506551)]

React框架

知识要点:
1. 基本知识
2. React 组件
3. React Redux
4. React 路由

[外链图片转存中…(img-IlfRgZxw-1715902506552)]

  • 12
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值