Förslag på organisationsprocess

För så mycket som jag skriver om – och är ett fan av – objektorienterad programmering, så skriver jag inte så mycket om de tider då jag arbetar med en procedurkodbas.

Procedurprogrammering är ett programmeringsparadigm, härlett från strukturerad programmering, baserat på konceptet med proceduranropet. Procedurer, även kända som rutiner, subrutiner eller funktioner, innehåller helt enkelt en serie beräkningssteg som ska utföras.

Ibland kommer jag på detta från kraven i ett projekt, ibland är det från ett projekt som jag har ärvt, eller ibland på grund av något annat.

Jag tror att det är viktigt att vi som programmerare inte håller ett paradigm så högt att vi drar oss för att arbeta med andra sätt att skriva kod. När allt kommer omkring handlar handlingen att skriva kod i sin kärna om att lösa ett problem.

Hur problemet löses kan anses vara sekundärt.

Oavsett, när jag arbetar med en kodbas; men det är skrivet, jag försöker fortfarande se till att det är organiserat på ett sätt som är sammanhållet, så lätt att följa som möjligt och kan underhållas över tid.

Jag tänkte dela med mig av hur jag närmar mig att skriva WordPress-plugins med procedurprogrammering kontra objektorienterad programmering och hur jag går tillväga för att organisera procedurkod.

Om inte annat, kanske detta ger dig några idéer för ett pågående eller framtida projekt.

Organisationsprocessbalken

När det gäller att arbeta med procedurkod finns det en stor potential att inkludera nästan allt i en enda, monolitisk fil.

Jag är inte av det här tillvägagångssättet eftersom det gör det svårare att hitta var något finns i filen (åtminstone om du är någon som precis kommer in i ett projekt).

För det ändamålet är det de här sakerna jag brukar göra.

1. Separata åtgärder och filter. Vanligtvis tar jag alla åtgärder och placerar dem i en fil och jag tar alla filter och placerar dem i en annan fil. Det är också möjligt att ytterligare separera dessa filer i underkataloger (om inte namnområden också) baserat på deras fokusområden. Till exempel kan alla åtgärder relaterade till administrationsområdet gå i en admin- underkatalog.
2. Skriv en felsökningsfil. Jag inkluderar normalt ett enkelt felsökningsskript i ett plugin så att jag enkelt kan återge felsökningsinformation på skärmen, skriva till felsökningsloggfilen eller skriva till båda. Detta kan vara en bekvämlighet om inte annat, men det hjälper till att ge ett sätt att enkelt se vad som händer utan att behöva starta Xdebug och stega igenom koden (om det inte är ett mer komplicerat problem).
3. Autoloader. Om du använder procedurkod kanske du inte använder namnutrymmen alls, men i så fall inkluderar jag även en autoloader som jag har skrivit för att göra det lättare att automatiskt inkludera filer. Detta är annorlunda än autoloadern än vad Composer genererar, men det gör fortfarande samma sak.

Uppenbarligen är det inget komplicerat med ovanstående rekommendationer. Faktum är att jag skulle säga något av ovanstående, särskilt det första steget kan räcka långt för att förbättra hanterbarheten av procedurkod.

Huvudinsticksfilen

Om du väljer att göra allt ovanstående bör den slutliga versionen av pluginens bootstrap-fil vara riktigt enkel. I själva verket kan det se ut som något så enkelt som detta :

<?php
/**
 * Plugin Name: Acme Plugin
 * Plugin URI:  https://acmeplugins.com/acme
 * Description: This is the plugin description.
 * Version:     1.0.0
 * Author:      Acme Plugins Co.
 * Author URI:  https://acmeplugins.com/acme
 * License:     GPL-3.0+
 * License URI: http://www.gnu.org/licenses/gpl-3.0.txt
 *
 * @since   1.0.0
 * @package Acme
 */

namespace Acme;

defined( 'WPINC') || die;

// Include the custom autoloader.
require_once __DIR__. '/inc/autoload.php';

// Include action and filters.
require_once __DIR__. '/inc/actions.php';
require_once __DIR__. '/inc/filters.php';

Återigen, detta förutsätter att du tillämpar alla tre rekommendationerna. Om inte, kan din implementering variera.