3. 任何软件的四个通用部分
任何应用程序软件，无论是图形界面、服务器端、商业、开源/免费、单体式等等，都始终具有四个通用部分
第一个 :: 软件本身：主体
可执行文件、库文件、静态数据文件、示例、手册和文档等。普通用户必须对这些文件具有只读访问权限。只有当系统管理员升级此软件时，这些文件才会被更改。
第二个 :: 配置文件：灵魂
这些文件定义了软件的运行方式，如何使用内容、安全、性能等。没有它们，软件本身通常是无用的。
根据您的软件，特定的特权用户可以更改这些文件，以使软件按照他们的意愿运行。
提供关于配置文件的文档非常重要。
第三个 :: 内容
是用户所有关注的焦点。是用户委托您的产品管理的东西。如果内容损坏，用户会抛弃您的产品而使用竞争对手的产品。
是数据库系统的表、文本编辑器的文档、Web 服务器的图像和 HTML 页面、应用服务器的 Servlet 和 EJB 等。
第四个 :: 日志、转储等
服务器软件通常会生成访问日志、跟踪文件以进行问题确定、临时文件等。其他类型的软件也使用这些文件，但不太常见。
这是最后一类文件，但很多时候它们是系统管理员最头疼的问题制造者，因为它们的体积甚至可能超过内容大小。因此，在设计时，考虑一些方法或工具来解决这个问题非常重要。
3.1. 实际例子
表 1. 四个部分的通用性
| 软件本身 | 配置 | 内容 | 日志、转储等 | |
|---|---|---|---|---|
| 数据库服务器 | 二进制文件、库文件、文档。 | 定义数据文件目录的文件。对于这种类型的软件，其余配置通常位于数据库中的特殊表中。 | 表文件、索引文件等。这种软件通常在同一目录下有整个树结构。而且很多时候它们需要多个文件系统来保证性能。它们在系统中的位置由它们的配置定义。 | 对于数据库，有每日生成的备份。日志被 DBA 用来定义索引策略。它们在系统中的位置也由配置定义。 |
| 文本处理器 | 相同的，模板，模块化文件格式过滤器等 | 作为面向用户的软件，其配置必须放在每个用户的$HOME目录下，并且是定义标准字体和制表符等的文件。 | 用户生成的文档，它们会放在用户的某个位置$HOME | 它们显示为可能很大的临时文件。用户可以使用友好的对话框定义它们的位置（这会将位置保存在某个配置文件中） |
| MP3 生成器 | 相同的，音频模块化过滤器 | 每个用户在他的目录下都有一个配置文件$HOME，并包含比特率偏好设置等 | 类似于文本编辑器 | 类似于文本编辑器 |
| Web 服务器 | 类似于数据库 | 定义内容目录、网络和性能参数、安全等的文件 | Web 管理员存放其创意作品的目录。同样由配置定义 | 宝贵的访问日志，对于营销情报至关重要，它们在由配置定义的位置和格式生成 |
| 电子邮件服务器 | 类似于数据库和 Web 服务器 | 定义如何访问用户数据库、邮件路由规则等的文件 | 宝贵的用户邮箱。同样由配置定义 | 邮件传输日志、病毒检测日志等。同样由配置定义 |
请注意，软件本身包含您产品的所有业务逻辑，如果您没有配置来定义如何处理用户提供的数据包，那么这些业务逻辑可能是无用的。因此，配置是将您的产品与用户连接起来的东西。
我们可以使用一个关于雕塑家（业务逻辑）的比喻，他需要青铜（内容）和来自赞助人（用户）的主题或灵感（配置），才能创作出美丽的艺术品（内容）。他会在他的日志（日志）中记录他每天的活动，以便向他的赞助人（用户）汇报。
3.2. 明确区分四个部分的重要性
好的，让我们更实际一点。事实是，如果我们正确使用通用部分概念，我们将大大提高我们产品的质量。我们将通过简单地将这些部分中的每一个都分离、封装到不同的系统目录中来实现这一点（仅仅为每个部分拥有不同的文件是不够的）。有一个名为 FHS 的标准定义了 Linux 中每个部分的目录，我们将在 第 4 节中稍后讨论它。
现在让我们看看这种分离对用户的价值
他可以清楚地了解每个部分的位置，特别是他的配置和内容，并且他感觉您的产品完全在控制之下。这种清晰性带来了易用性、安全性和对您产品的信心。实际上，它允许他独立地操作每个部分
现在很清楚，例如，在备份时，用户只需要关心配置和内容（纯粹主义者也会备份一些日志）。用户不必关心软件本身，因为它是安全的、原始的，在产品 CD 中，在他的书架上。
对于升级，新软件包将仅覆盖业务逻辑，而保持用户宝贵的配置和内容完好无损。这里非常重要的是保持旧内容和配置的兼容性，或者提供一些工具来帮助数据迁移
日志保存在单独的文件系统中（在您的文档中显然会建议这样做），避免了它们过度的增长干扰内容，或整个系统的稳定性
如果您的软件遵循一些目录标准，用户不必重新配置他的系统或环境即可使用它。他只需安装即用。
让我们做一个关于分离的练习，以一个名为 MySoftware 的系统为例，其中业务逻辑在示例 1 中，配置在示例 2 中。
示例 1. 引用外部配置文件的 Shell 程序
#!/bin/sh ############################################################################# ## ## /usr/bin/MySoftware ## ## Business logic of MyProgram system. ## Do not change nothing in this file. All configuration can be ## made on /etc/MySoftware.conf ## ## We'll not support any modifications made here. ## # Default configuration file CONF=/etc/MySoftware.conf |
示例 2. 仅包含 MySoftware 配置的文件
############################################################################# ## ## /etc/MySoftware.conf ## ## Configuration parameters for MySoftware. ## Change as much as you want. ## # Content directory. # A ':' separated list of directories for your content. # The directories /var/www and /var/MySofware are already there, so # include here your special directories, if any. CONF_CONTENT_PATH=/var/NewInstance:/var/NewInstance2 |
3.3. 一个主体，多个灵魂
当我在 IBM 电子商务托管服务公司担任系统管理员时，我对Apache 的灵活性着迷，它让我们能够做这样的事情
bash# /usr/sbin/httpd & bash# /usr/sbin/httpd -f /etc/httpd/dom1.com.br.conf & bash# /usr/sbin/httpd -f /etc/httpd/dom2.com.br.conf & bash# /usr/sbin/httpd -f /etc/httpd/dom3.com.br.conf & |
如果我们不传递任何参数（如第一个例子），Apache 会从/etc/httpd/conf/httpd.conf加载其默认的硬编码配置文件。我们为每个客户构建了其他配置，具有完全不同的结构、IP 地址、加载的模块、内容目录、密码、域名、日志策略等。
多用户桌面（如 Linux）的文本编辑器也使用了相同的概念。当代码加载时，它会在用户的$HOME中查找配置文件，并且根据调用它的人（用户 A 或用户 B），它会以不同的方式显示，因为每个用户都有自己的个人配置。
显而易见的结论是，软件的主体（业务逻辑）是纯粹的，并且完全由其操纵者的精神（配置）所引导。但竞争优势在于我们如何在不同的精神之间轻松切换，就像 Apache 的例子一样。将其推广给您的用户是非常有益的。您将让他们与您的产品建立亲密关系、可靠性和舒适感。
我们在当时的电子商务托管时期将这种方法用于许多不同的软件，并且它对于维护等非常有用。在版本迁移中，我们可以完全控制每个部分的位置，并且可以升级和降级软件而不会浪费时间，并取得明显的成功。
但是有一些产品拒绝以这种方式工作。它们有太多的硬编码参数，以至于我们无法区分主体与它们的灵魂（或其他部分）。这些软件被标记为坏家伙，并尽快被丢弃/替换。
我们得出的结论是，好家伙软件直观地受到了开发者 四个部分愿景 的眷顾。它们让我们的生活更轻松。事实上，在那时我们提出了这个 理论，它继续证明自身。
您想部署坏家伙还是好家伙软件？