如何将 12 Factor App 应用于 Linux 驱动程序开发？
How to apply 12 Factor App to Linux driver developing?
我是一名工程师，目前正在开发 Linux 内核模式驱动程序和用户模式驱动程序。当我接触到 12 Factor App 的理论时，强烈 的声音在我的脑海中回荡：“这就是发展的未来！”。
我一直想知道如何将此方法应用于 Linux KMD 和 UMD 设计和开发，因为该理论太基于网络应用程序（我是兼职开源网络开发人员） .
当前开发语言：C
当前测试自动化：自定义实施 Python 测试框架（基于进度，无单元测试）
请给我一些建议。提前感谢和感谢。
与大多数开发指南一样，指南与执行之间存在差距。
例如，在您的“12 因素应用程序”方法中，因素之一是：
- 代码库 - 在修订控制中跟踪一个代码库，许多部署
这听起来很棒，而且确实可以简化事情。直到你到达实用程序库的地步。你看，当你发现你正在跨多个项目重用代码时，你可能想要：
- 多个项目的独立构建和发布链。
这可能意味着两个代码库，但上面说的是一个代码库（也许每个项目一个，也许每个公司一个。我们先假设每个公司一个，很容易看出 non-ideal；因为，你会提交与项目提交历史中的项目无关的提交。好吧，每个项目一个，更明智；但是，如果项目需要共享代码怎么办？比如格式化它们的通信并控制发送/接收协议的库？好吧，我们可以创建第三个“协议库”，以便我们围绕协议进行修订；但是，这违反了“一个代码库（每个项目）”，因为现在您有两个代码库包含单个可发布项目。
这里的决定并不简单。另一种方法是将协议代码复制到两个项目中，并通过其他方式使它们保持同步。
- 依赖关系 - 显式声明和隔离依赖关系
这是个好主意；并且，它可以在许多方面简化开发。再次说明，如果没有关于如何实施该想法的明确指导方针，一个好想法会如何受到影响，当您使用一个不尝试隔离该库使用的依赖关系的库时，您会怎么做？很多比较复杂的库本身就依赖于其他库，一般都会明确声明自己的依赖关系，库使用的库也是如此；然而，有时多个项目（日志记录、配置等）使用的基础、核心库最终会在不同的发布版本中使用。隔离发生在 per-library 的基础上，而不是在 per-project 的基础上。你可以修复它，只要你想要（或可以）分叉和克隆库，重组它们以适当地隔离它们的依赖关系以实现版本号的整体协调；但是，通常您会没有时间处理其他人的项目。
总的来说，“12 因素应用”方法论下的建议是好的；但是，它让您完成将指南转化为开发协议的工作。执行就变成了一个解释的问题，执行的手段（以及解释）就落在你身上了。
有些指南看起来很危险over-simlpified:
- 并发 - 通过进程模型横向扩展
虽然这是一种更简单的方法，但它不是任何单个高性能 Web 服务器的工作方式。它们都使用线程、线程池和其他更复杂的结构来避免进程切换。由于传统过程模型的局限性，这些结构（公认的更难使用）是专门创建的。毕竟，每个 Web 请求都启动一个进程并不常见，您通常也不会通过在同一台机器上启动第二个副本来“调整程序以获得更好的性能”。当然，在某些架构中这可以发挥作用；但是，到目前为止，这些架构还没有超越他们的竞争对手。
机器之间，我完全同意。进程扩展是进入分布式环境的唯一途径；但是，在这种方法论中并没有太多讨论分布式算法，甚至分布式计算方法；所以，这又是留给实施者的另一件事。
最后，他们的过程评论似乎真的 out-of-place 用于编写命令行工具。推动事物守护进程对微服务非常有效；但是，即使是客户，您也无法通过微服务来处理。最终你将不得不编写一些不是“由 systemd 管理”的东西，因为在没有 always-on 服务的情况下开始执行和结束执行。
所以，这是一个很好的框架，即使它在很多方面都非常出色，但它可能不适用于某些事情；但是，在我看来，执行它的工具必须由使用它的组织构建，因为一个组织可能做出的解释可能与另一个组织不同。
我是一名工程师，目前正在开发 Linux 内核模式驱动程序和用户模式驱动程序。当我接触到 12 Factor App 的理论时，强烈 的声音在我的脑海中回荡：“这就是发展的未来！”。
我一直想知道如何将此方法应用于 Linux KMD 和 UMD 设计和开发，因为该理论太基于网络应用程序（我是兼职开源网络开发人员） .
当前开发语言：C
当前测试自动化：自定义实施 Python 测试框架（基于进度，无单元测试）
请给我一些建议。提前感谢和感谢。
与大多数开发指南一样，指南与执行之间存在差距。
例如，在您的“12 因素应用程序”方法中，因素之一是：
- 代码库 - 在修订控制中跟踪一个代码库，许多部署
这听起来很棒，而且确实可以简化事情。直到你到达实用程序库的地步。你看，当你发现你正在跨多个项目重用代码时，你可能想要：
- 多个项目的独立构建和发布链。
这可能意味着两个代码库，但上面说的是一个代码库（也许每个项目一个，也许每个公司一个。我们先假设每个公司一个，很容易看出 non-ideal；因为，你会提交与项目提交历史中的项目无关的提交。好吧，每个项目一个，更明智；但是，如果项目需要共享代码怎么办？比如格式化它们的通信并控制发送/接收协议的库？好吧，我们可以创建第三个“协议库”，以便我们围绕协议进行修订；但是，这违反了“一个代码库（每个项目）”，因为现在您有两个代码库包含单个可发布项目。
这里的决定并不简单。另一种方法是将协议代码复制到两个项目中，并通过其他方式使它们保持同步。
- 依赖关系 - 显式声明和隔离依赖关系
这是个好主意；并且，它可以在许多方面简化开发。再次说明，如果没有关于如何实施该想法的明确指导方针，一个好想法会如何受到影响，当您使用一个不尝试隔离该库使用的依赖关系的库时，您会怎么做？很多比较复杂的库本身就依赖于其他库，一般都会明确声明自己的依赖关系，库使用的库也是如此；然而，有时多个项目（日志记录、配置等）使用的基础、核心库最终会在不同的发布版本中使用。隔离发生在 per-library 的基础上，而不是在 per-project 的基础上。你可以修复它，只要你想要（或可以）分叉和克隆库，重组它们以适当地隔离它们的依赖关系以实现版本号的整体协调；但是，通常您会没有时间处理其他人的项目。
总的来说，“12 因素应用”方法论下的建议是好的；但是，它让您完成将指南转化为开发协议的工作。执行就变成了一个解释的问题，执行的手段（以及解释）就落在你身上了。
有些指南看起来很危险over-simlpified:
- 并发 - 通过进程模型横向扩展
虽然这是一种更简单的方法，但它不是任何单个高性能 Web 服务器的工作方式。它们都使用线程、线程池和其他更复杂的结构来避免进程切换。由于传统过程模型的局限性，这些结构（公认的更难使用）是专门创建的。毕竟，每个 Web 请求都启动一个进程并不常见，您通常也不会通过在同一台机器上启动第二个副本来“调整程序以获得更好的性能”。当然，在某些架构中这可以发挥作用；但是，到目前为止，这些架构还没有超越他们的竞争对手。
机器之间，我完全同意。进程扩展是进入分布式环境的唯一途径；但是，在这种方法论中并没有太多讨论分布式算法，甚至分布式计算方法；所以，这又是留给实施者的另一件事。
最后，他们的过程评论似乎真的 out-of-place 用于编写命令行工具。推动事物守护进程对微服务非常有效；但是，即使是客户，您也无法通过微服务来处理。最终你将不得不编写一些不是“由 systemd 管理”的东西，因为在没有 always-on 服务的情况下开始执行和结束执行。
所以，这是一个很好的框架，即使它在很多方面都非常出色，但它可能不适用于某些事情；但是，在我看来，执行它的工具必须由使用它的组织构建，因为一个组织可能做出的解释可能与另一个组织不同。