鲁达 构建现代软件系统的五要素开发方法论
照片由Safar Safarov在Unsplash上拍摄，用 Canva 编辑
程序员通常使用各种开发工具和依赖项来处理桌面、移动、Web 和嵌入式应用程序。同时，一些程序员开发框架、软件库、操作系统和开发工具来支持开发应用程序的程序员。每个程序员都努力提高他们的软件系统的质量，以在他们的项目中取得成功。如果一个软件产品具有高质量和稳定的特性，用户就会向其他用户推荐特定的产品——否则，他们可能会找到替代品。
软件开发团队遵循各种流程和实践来构建高质量的软件系统。我们都知道十二要素应用程序方法，它提供了一个结构良好的概念来构建高质量的软件即服务 (SAAS) 类型的产品。
在这个故事中，我将解释一种用于提高任何软件系统质量的五因素开发方法。您可以将此方法应用于构建桌面应用程序、移动应用程序、Web 应用程序、框架、库或任何其他软件项目。我也使用相同的方法来开发我的软件项目。
1. 稳定优化的项目架构
一个软件项目通常包含多个子模块或组件，这些模块可以是内部组件或第三方依赖项。软件架构是指这些子模块的排列和连接。例如，在分层架构模式中，我们通常将子组件排列在洋葱中的每个相似层的顶部，以构建整个系统。看看 Flutter 引擎层如何使用Skia渲染层来处理原生小部件的绘制：
Flutter引擎使用Skia canvas API，作者截图
软件架构最初为软件项目奠定了基础，并让程序员在特定项目上工作多年。整个软件系统的生命周期、可维护性和市场成功取决于此基础。对于任何软件开发团队来说，后期的架构更改通常都是耗时且昂贵的。换句话说，一旦在它上面建了房子，就不可能改变地基。因此，我们总是需要努力在第一次实现尝试时选择最优的架构模式。
将更多时间花在早期的架构决策上，而不是花时间修复即时非最佳架构决策的副作用确实更好。
首先，在软件系统的核心功能上工作并稳定下来——在这个阶段，架构的改变并不耗费太多时间。接下来，使用软件核心的功能处理功能。即使您使用单体模式，您也可以将核心逻辑与源代码级别的功能分离，而不是从架构级别分离。几年前，我们在搭建一个Serverless平台，把核心逻辑分离到core目录中，如下图：
Jerverless平台中的隔离核心逻辑，作者截图
此外，诸如选择编程语言和依赖项之类的技术决策无疑很重要——通过仔细考虑你的需求来选择它们——不仅仅是因为现代炒作。
2. 干净、简单、可维护的代码库
一旦我们对软件架构设计有了清晰的认识，我们就可以开始开发代码库了，但还有另一种方法。我们可以首先构建一个工作软件项目（又名 POC），然后考虑改进架构方面。许多流行的开源项目都是从这种基于 POC 的方法开始的，后来根据生产需求对架构进行了微调。然而，我们需要开发干净、简单和可维护的代码库，从而获得高质量的软件。
通常不止一名开发人员从事软件项目，他们经常需要使用功能、错误修复和性能改进来更新项目代码库。拥有可维护的代码库可以提高每个人的工作效率，并激励每个人再次为项目做出贡献。YAGNI、KISS 和 DRY 编程原则教我们创建一个好的代码库。下面的故事进一步解释了这些编程概念：
在开发代码库之前，从一开始就计划好。首先，考虑一个首选的编程范式——流行的OOP 并不是唯一适合现代软件开发的范式。接下来，我们可以使用正确的数据结构、首选的语言特性、合适的软件库、良好的代码风格和设计模式来编写干净的、不言自明的代码。仅使用所需的设计模式和语言功能使代码库保持简单可消除过度工程效应并激励每个人为项目做出贡献。
3. 面向开发人员和 CI/CD 服务器的 DevOps 工作流程
早些时候，程序员使用手动流程来处理云部署、生成发布包并了解用户期望的功能。后来，DevOps 运动引入了自动化软件发布、自动化测试策略和应用程序监控概念，以更快、更优质地交付软件功能。以下故事解释了 DevOps 的优势：
DevOps 概念确实通过自动化使整个软件开发过程富有成效。例如，开发人员必须编译我们的一个开源框架来试验最新的未发布功能。但现在，我们的自动化 DevOps 工作流程在每个午夜生成具有实验性功能的夜间构建，如下所示：
关于 nightly 框架预发布的 GitHub 通知，作者截图
DevOps 不仅用于改进发布周期——它还激励我们将整个软件开发生命周期 ( SDLC )中的每一项耗时的手动任务自动化。例如，我们可以使用 DevOps 原则，通过基于应用程序监控事件自动生成 sprint backlog 任务来提高客户满意度。
在某些场景下，我们可以在本地开发环境中重用专注于 CI/CD 的 DevOps 脚本，也可以提高开发人员的工作效率。DevOps 工作流程中经常会发生过度工程，因此我们需要在需要自动化时实施自动化，而不仅仅是因为现代 DevOps 趋势。
4. 面向开发人员和 CI 服务器的测试套件
软件测试策略帮助我们在最终用户之前识别软件系统中的缺陷。程序员经常修改源文件以添加新功能、修复错误和重构。即使我们有手动代码审查，即使是单个字符更改也可能在软件系统中悄悄引入一个严重错误。代码审查通常对特定代码快照执行静态分析。我们无疑需要通过在真实计算环境中执行代码来执行动态分析，以识别可能的运行时和编译时问题。
测试套件通常会引入一组单元测试、集成测试或其他测试，以动态验证特定代码快照的正确性。由 DevOps 提供支持的自动化测试套件通过在源代码修改后立即识别缺陷来提高产品质量。例如，查看 Node.js 代码库的 DevOps工作流如何验证每个贡献者拉取请求：
Node.js 源代码库的 GitHub Actions for pull requests，作者截图
测试套件不仅适用于 CI 服务器，而且开发人员还需要在开发活动期间在本地运行它，然后再将代码提交到远程存储库。因此，大多数软件项目通常会为开发人员提供一种在本地运行完整测试套件或其中一部分的方法。
与软件错误一样，测试套件也可能包含错误，并且可能会隐藏算法模块中的边缘情况问题——所以相信你所写的东西，而不是测试套件的通过/失败状态。
5. 易于理解的文档和手册
有几种文档类型——让我们首先讨论代码文档。一个简单的无注释源代码确实是铁杆程序员的文档源。但是，每个程序员都在努力节省时间，并且不想检查每一行代码来提交一个简单的补丁。例如，如果您构建一个 SAAS 产品，新聘用的开发人员在他们第一次贡献代码之前不需要阅读每个现有的代码行。
代码文档提供了源代码的概述并解释了每个源代码模块的职责。与包含许多段落的文档相比，代码注释可能是更有价值的文档。例如，查看 Linux 内核源代码中的以下注释：
Linux内核源码中的代码注释，作者截图
同时，一些开发人员会根据代码注释生成单独的基于 Web 的文档页面。但是，他们在处理源文件时可能会遇到一些问题，因为这些文件看起来有点过度设计嵌入式文档。根据您的方便选择代码文档策略。
另一种文档类型是最终用户阅读的项目手册。如果您为开发人员解决问题，本文档也可以是技术文档。一些项目可以包含其他类型的文档，例如架构说明和应用程序安全相关说明。让每个文档都易于遵循和更新，让每个人都感到快乐和富有成效。
谢谢阅读。