企业官方网站开发外包,app运营,wordpress邀请码生成,潍坊做网站教程案例解析篇 一、大型开源项目对软件工程的应用1、开发迭代过程 二、大厂是怎样应用软件工程的1、软件项目开发团队组成#xff08;1#xff09;软件开发团队规模小#xff08;2#xff09;没有专职测试#xff08;3#xff09;DevOps 文化 2、开发工具的使用3、项目开发流… 案例解析篇 一、大型开源项目对软件工程的应用1、开发迭代过程 二、大厂是怎样应用软件工程的1、软件项目开发团队组成1软件开发团队规模小2没有专职测试3DevOps 文化 2、开发工具的使用3、项目开发流程 三、微服务、云计算、人工智能1、软件工程中技术架构和组织架构的关系2、新技术改变了软件工程中的分工协作3、在软件工程中技术是工具 一、大型开源项目对软件工程的应用
以VS Code为例看大型开源项目是如何应用软件工程的。 软件工程的核心就是围绕软件项目开发对开发过程的组织对方法的运用对工具的使用。
所以当我们去观察一个软件项目我们就可以去看它的开发过程是怎么被组织的运用了哪些软件工程的方法使用了哪些工具
所以接下来就从以下几个方面分析 VS Code 对软件工程的应用
VS Code 的开发过程团队的分工角色各个阶段如何进行使用了哪些工具。
1、开发迭代过程
从开发模式来说VS Code 采用的是快速迭代的开发模式每四周一个迭代。那么这四周的迭代的工作都是如何进行的呢
第一周 每个版本的第一周通常是起着承上启下的作用一方面要准备新版本一方面还要对上一个版本的工作进行收尾。
另一个主要工作就是一起讨论下一个迭代要做的功能。其实这有点类似于敏捷开发中每个 Sprint 开始之前的项目计划会议。
如果上一个版本开发完成的功能发现了严重 Bug第一周还要去修复这些紧急 Bug。
第二周和第三周 第二周和第三周主要工作就是按照计划去开发一部分是开发新功能一部分是修复 Bug
第四周 VS Code 团队把最后一周叫 End game你可以理解为测试周因为这一周只做测试和修复 Bug。
这一周要测试所有新的 Feature 和验证已经修复的 Bug确保被修复。同时还要更新文档和写 Release Notes。
测试完成后就发布预发布版本这个预发布版本会先邀请一部分人使用比如说微软内部员工、热心网友。
下一个迭代第一周 每个迭代开发测试完成的版本会放在下一个迭代的第一周发布。如果在预发布版本中发现严重 Bug需要在第一周中修复。
如果没有发现影响发布的 Bug那么第一周的周三左右就会正式发布上一个迭代完成的版本。
在团队分工上VS Code 的团队很扁平没有专职测试通过轮值的 Inbox Tracker 和 Endgame Master 来帮助团队处理日常 Issue 和推动测试和发布工作的进行。
在工具的使用方面VS Code 使用的是 GitHub 托管代码基于 GitHub Flow 的开发流程使用的。还有使用 Azure DevOps 作为它的持续集成系统。
二、大厂是怎样应用软件工程的
微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的 从大厂应用软件工程的实践中你能学习什么又该如何学习借鉴。
每个公司都有自己的历史和文化他们的文化又影响了各自的软件开发模式。所以要多去关注大厂们对软件工程实践共通的地方可以应用在你自己项目的地方另外还要去看大厂对软件工程实践的变化趋势在朝什么方向发展。
通常这些大厂的很多实践都是业界的风向标一旦一些实践大厂都在应用那么很多中小厂就会跟风最终变成行业标准。
下面将从大厂的开发团队组成、开发工具的使用、项目开发流程这几个方面来分析一下大厂对软件工程的应用中有哪些共同点有哪些变化趋势有什么地方可以借鉴
1、软件项目开发团队组成
1软件开发团队规模小
网上曾有一张流传甚广的关于各大公司的组织结构图。 这张图形象生动的描述了各大公司的组织结构各具特色。然而这些大厂的组织结构具体细分到软件项目开发团队的时候却惊人的相似那就是一个软件项目开发团队都不会太大一般不会超过 10 个人如果超过就会被分拆。
团队规模越大交流就越复杂成本也越高要想沟通更高效那么就要求团队的规模必须足够小。
2没有专职测试
像微软、谷歌、Facebook、阿里巴巴这些大厂都没有专职的测试人员大厂替代专职测试的这些手段对于普通公司来说可能现阶段去实施是有难度的但是随着这些发布、监控工具的不断普及自动化测试的普及开发团队不设置专职测试会逐步变成一种趋势现在的手工测试将来也许会被逐步淘汰。
3DevOps 文化
将运维团队合并到了工程师团队运维人员和开发人员协作更加紧密了有效提高了编码效率质量和产量。
2、开发工具的使用
大厂都爱自己造轮子对开发工具也是如此都有一个专门的部门去做内部工具的开发和维护。
大厂用的这些主要工具你在网上几乎都能找到开源的或商业的替代品。只是没有那么好用罢了。
建议可以学习下大厂把这些工具用起来帮助你更好地完成项目。
3、项目开发流程
有的团队是敏捷开发有的团队是快速迭代甚至有的团队还用的是瀑布模型。但他们在项目开发中有很多共通之处。
迭代周期短
即使是像微软这样以前要几年才发布一个版本软件的公司现在也加快了迭代。
如果你的项目需要半年以上的开发周期也要考虑一下是否可以缩短开发周期快速迭代起来。
严格的开发流程
已经提到过很多开发的流程比如说基于分支开发、代码审查、自动化测试、持续集成等等希望大家能在实践中去应用这些好的实践。
然而在大厂这些开发流程基本上都是硬性要求
要基于分支进行开发新功能或者修复 Bug要遵守公司或者团队的代码规范合并之前要有至少一个人 Review 通过要写自动化测试代码并且保证所有测试用例通过。
严谨的测试流程
虽然很多大厂都没有专职测试但是测试可不含糊都有一套严谨的并且行之有效的测试流程。除了自动化测试以外每个版本发布之前都要经历以下几个版本下图window 10的发布流程也是这样一个一个的测试版本的测试流程
完善的发布和监控流程
很多大厂们还会配合一套完善的发布和监控流程。
发布前先评估风险增加相应的监控数据和设置报警的阈值。制定出现问题的应对方案。
上线后先推送一小部分用户并同时进行线上数据的监控如果没有发现异常自动加大比例直到完整覆盖如果发现异常自动报警通知相关负责人上线处理并直接关闭新功能。
事后总结不断改进 复盘也是整个项目开发过程中很重要的一部分正是因为有这样一次次的“事后诸葛亮”会议才让团队成员能从中总结成功经验吸取失败教训。
从大厂对软件工程实践中你可以学习到一个优秀的公司是如何来应用软件工程打造出高质量产品的也可以借鉴其中好的实践到你自己的项目中。
最后要清楚即便是大厂对软件工程的应用也不是一成不变的会随着技术的发展、软件工程的发展不断改进。
三、微服务、云计算、人工智能
这些年来新技术新概念层出不穷比如说微服务、云计算、人工智能等。你有没有去学习和了解这些新技术呢又是怎么去理解这些新技术的呢
如果只是从技术角度思考这些问题难免会陷入技术之中反而不容易看清楚这些问题。不妨从项目的整体从软件工程的角度来理解这些技术这能给你带来不同的视角。
1、软件工程中技术架构和组织架构的关系
从技术角度来看微服务就是一种架构技术。通常系统架构和组织架构是相似的。
比如说前后端分离的架构那么在组织上一般也会分前端组和后端组而微服务架构则分组是和服务相关的可能一个组就是负责一个微服务。
这个现象背后有个定律叫康威定律那些大型复杂的单体软件系统背后也对应着一个庞大的开发团队那些应用微服务的项目背后都是一个个的小组。 微服务架构的设计不仅仅是一个对服务拆分的架构设计同时也是对组织架构拆分的设计。
对于微服务的组织结构需要按服务划分团队团队成员有开发、测试和运维一起组成一个小团队围绕着服务不断迭代这样效率是最高的。
如果以后又出来什么新的概念和技术你不妨从软件工程的角度去看看它和组织结构的关系。
2、新技术改变了软件工程中的分工协作
云计算通过标准化的服务简化了开发的难度人工智能和自动化在逐步替代项目中的一些手工操作。
早些年的开发团队服务端比前端人数要多因为那时候界面简单而后端需要实现很多数据库增删改查的逻辑。现在的趋势是界面越来越复杂而后端服务越来越强大借助一些云服务甚至不需要去写程序就能实现服务端 API 供前端调用。
如果你从软件工程的角度去看云计算它本质上是在将那些与业务无关的而又很重要的基础设施、技术作为一种标准服务提供让你在软件开发时只需要专注于业务所独有的部分从而可以极大地减少开发工作提升开发效率。
3、在软件工程中技术是工具
对于像微服务、云计算、人工智能这些新技术如果站在技术角度看技术人员永远有两种态度拥抱新技术和抵触新技术。
但如果你站在软件工程的角度去看技术技术服务于架构设计架构设计服务于业务业务服务于商业。也就是本质上来说技术是为项目服务的工具。
从软件工程的角度就会把技术当做工具去学习了解这些新技术然后进一步思考这个技术能解决什么问题应用在项目中有什么样的优缺点
让技术去为架构服务让架构去为业务服务从而帮助业务产生好商业价值。
