Revisiting codebase organization practices from 2004

Source: Dev.to

Overview

I reviewed the file and directory structure of several web‑based free software projects released in 2003–2004: the Koha 1.2.0 library management system, the MRBS 1.2.1 meeting‑room booking system, and the DSpace 1.2 content repository system. These were written in Perl, PHP, and Java, respectively.

Endpoint Naming Conventions

Endpoint files are named using an action, optionally followed by an entity. Typical patterns include:

# Perl
search.pl
updatebibitem.pl
opac_reserve.pl

// PHP
search.php
edit_entry.php

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

The verbs or verb phrases may or may not align with user workflows. For example, Koha includes opac_reserve.pl, indicating it handles the reservation workflow via the Online Public Access Catalog (OPAC) API, but there is no dedicated “borrow” endpoint file.

Modular Structure of the Projects

Each system is designed in a modular style:

• Koha – provides a Borrower.pm module with a reserveslist function.
• MRBS – uses functions.inc, which contains functions such as make_room_select_html.
• DSpace – includes Item.java with methods like findAll.

However, they do not strictly follow a multi‑tier architecture; for instance, database queries are not isolated into a dedicated data‑access layer. DSpace does establish a distinct presentation layer by using Servlets and JSPs.

Architectural Observations

Because of the verb‑based naming convention, files emphasize what they do rather than which architectural layer they belong to. This makes their purpose easy to understand at a glance, but it also means that logical, data‑access, and presentation code are often mixed within the same file or even the same function.

Implications for Organization and Testing

The approach can make organization and testing more challenging:

• Logic, database queries, and presentation code are frequently intertwined.
• Lack of clear separation hampers unit testing and code reuse.
• Maintaining a consistent architectural boundary requires extra discipline from developers.