软件工程学习笔记14——案例解析篇

一、大型开源项目对软件工程的应用

以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、阿里巴巴这些大厂，都没有专职的测试人员，大厂替代专职测试的这些手段，对于普通公司来说，可能现阶段去实施是有难度的，但是随着这些发布、监控工具的不断普及，自动化测试的普及，开发团队不设置专职测试会逐步变成一种趋势，现在的手工测试将来也许会被逐步淘汰。

（3）DevOps 文化

将运维团队合并到了工程师团队，运维人员和开发人员协作更加紧密了，有效提高了编码效率，质量和产量。

2、开发工具的使用

大厂都爱自己造轮子，对开发工具也是如此，都有一个专门的部门去做内部工具的开发和维护。

大厂用的这些主要工具，你在网上几乎都能找到开源的或商业的替代品。只是没有那么好用罢了。

建议可以学习下大厂，把这些工具用起来，帮助你更好地完成项目。

3、项目开发流程

有的团队是敏捷开发，有的团队是快速迭代，甚至有的团队还用的是瀑布模型。但他们在项目开发中有很多共通之处。

迭代周期短

即使是像微软这样，以前要几年才发布一个版本软件的公司，现在也加快了迭代。

如果你的项目需要半年以上的开发周期，也要考虑一下，是否可以缩短开发周期，快速迭代起来。

严格的开发流程

已经提到过很多开发的流程，比如说基于分支开发、代码审查、自动化测试、持续集成等等，希望大家能在实践中去应用这些好的实践。

然而在大厂，这些开发流程基本上都是硬性要求：

• 要基于分支进行开发新功能或者修复 Bug；
• 要遵守公司或者团队的代码规范；
• 合并之前要有至少一个人 Review 通过；
• 要写自动化测试代码，并且保证所有测试用例通过。

严谨的测试流程

虽然很多大厂都没有专职测试，但是测试可不含糊，都有一套严谨的，并且行之有效的测试流程。除了自动化测试以外，每个版本发布之前，都要经历以下几个版本，下图window 10的发布流程，也是这样一个一个的测试版本的测试流程：

完善的发布和监控流程

很多大厂们还会配合一套完善的发布和监控流程。

发布前，先评估风险，增加相应的监控数据和设置报警的阈值。制定出现问题的应对方案。

上线后，先推送一小部分用户，并同时进行线上数据的监控，如果没有发现异常，自动加大比例，直到完整覆盖；如果发现异常，自动报警通知相关负责人，上线处理，并直接关闭新功能。

事后总结，不断改进
复盘也是整个项目开发过程中很重要的一部分，正是因为有这样一次次的“事后诸葛亮”会议，才让团队成员能从中总结成功经验，吸取失败教训。

从大厂对软件工程实践中，你可以学习到一个优秀的公司是如何来应用软件工程，打造出高质量产品的，也可以借鉴其中好的实践到你自己的项目中。

最后要清楚，即便是大厂，对软件工程的应用也不是一成不变的，会随着技术的发展、软件工程的发展不断改进。

三、微服务、云计算、人工智能

这些年来，新技术新概念层出不穷，比如说微服务、云计算、人工智能等。你有没有去学习和了解这些新技术呢？又是怎么去理解这些新技术的呢？

如果只是从技术角度思考这些问题，难免会陷入技术之中，反而不容易看清楚这些问题。不妨从项目的整体，从软件工程的角度来理解这些技术，这能给你带来不同的视角。

1、软件工程中技术架构和组织架构的关系

从技术角度来看，微服务就是一种架构技术。通常系统架构和组织架构是相似的。

比如说前后端分离的架构，那么在组织上一般也会分前端组和后端组；而微服务架构，则分组是和服务相关的，可能一个组就是负责一个微服务。

这个现象背后有个定律叫康威定律，那些大型复杂的单体软件系统，背后也对应着一个庞大的开发团队，那些应用微服务的项目，背后都是一个个的小组。

微服务架构的设计，不仅仅是一个对服务拆分的架构设计，同时也是对组织架构拆分的设计。

对于微服务的组织结构，需要按服务划分团队，团队成员有开发、测试和运维，一起组成一个小团队，围绕着服务不断迭代，这样效率是最高的。

如果以后又出来什么新的概念和技术，你不妨从软件工程的角度，去看看它和组织结构的关系。

2、新技术改变了软件工程中的分工协作

云计算通过标准化的服务简化了开发的难度，人工智能和自动化在逐步替代项目中的一些手工操作。

早些年的开发团队，服务端比前端人数要多，因为那时候界面简单，而后端需要实现很多数据库增删改查的逻辑。现在的趋势是，界面越来越复杂，而后端服务越来越强大，借助一些云服务甚至不需要去写程序，就能实现服务端 API 供前端调用。

如果你从软件工程的角度去看云计算，它本质上是在将那些与业务无关的，而又很重要的基础设施、技术，作为一种标准服务提供，让你在软件开发时，只需要专注于业务所独有的部分，从而可以极大地减少开发工作，提升开发效率。

3、在软件工程中，技术是工具

对于像微服务、云计算、人工智能这些新技术，如果站在技术角度看，技术人员永远有两种态度：拥抱新技术和抵触新技术。

但如果你站在软件工程的角度去看技术：技术服务于架构设计，架构设计服务于业务，业务服务于商业。也就是本质上来说，技术是为项目服务的工具。

从软件工程的角度，就会把技术当做工具，去学习了解这些新技术，然后进一步思考：这个技术能解决什么问题？应用在项目中有什么样的优缺点？

让技术去为架构服务，让架构去为业务服务，从而帮助业务产生好商业价值。