重新审视2004年的代码库组织实践

Source: Dev.to

概览

我审查了几款在 2003–2004 年发布的基于 Web 的自由软件项目的文件和目录结构：Koha 1.2.0 图书馆管理系统、MRBS 1.2.1 会议室预订系统以及 DSpace 1.2 内容仓库系统。它们分别使用 Perl、PHP 和 Java 编写。

端点命名约定

端点文件的命名采用动词，后面可选实体。典型模式包括：

# Perl
search.pl
updatebibitem.pl
opac_reserve.pl

// PHP
search.php
edit_entry.php

// Java (Servlets)
SimpleSearchServlet.java
EditProfileServlet.java

这些动词或动词短语可能与用户工作流对齐，也可能不对齐。例如，Koha 包含 opac_reserve.pl，表明它通过在线公共访问目录（OPAC）API 处理预约工作流，但没有专门的 “borrow” 端点文件。

项目的模块化结构

每个系统都采用了模块化风格：

• Koha – 提供一个 Borrower.pm 模块，其中有 reserveslist 函数。
• MRBS – 使用 functions.inc，其中包含诸如 make_room_select_html 的函数。
• DSpace – 包含 Item.java，其中有 findAll 等方法。

然而，它们并未严格遵循多层架构；例如，数据库查询并未被隔离到专门的数据访问层。DSpace 通过使用 Servlets 和 JSPs 确立了独立的表现层。

架构观察

由于采用基于动词的命名约定，文件更强调 它们做了什么 而不是 它们属于哪个架构层。这使得一眼就能了解其用途，但也意味着逻辑、数据访问和表现代码常常混杂在同一个文件甚至同一个函数中。

对组织和测试的影响

这种做法可能使组织和测试更加困难：

• 逻辑、数据库查询和表现代码经常交织在一起。
• 缺乏明确的分离阻碍了单元测试和代码复用。
• 维持一致的架构边界需要开发者付出额外的纪律性。