Refactoring on markob.de

Zweimal `square()` - Teil 1

Mon, 17 Aug 2026 00:00:00 +0000

Manchmal beginnt Code-Archäologie nicht mit einem spektakulären Fund. Manchmal beginnt sie mit einem SQL-Injection-Fix – und einer Funktion, die eine Zahl quadriert.

Am 12. August 2026 wurde im LimeSurvey-Repository Pull Request #5225 eröffnet. Der Titel: “Fixed issue #20648: [security] SQL injection in statistics”.

Das Problem war ernst. In der Statistikfunktion konnten manipulierte Filterparameter dazu führen, dass vom Request stammende Feldnamen ungeprüft in SQL-Abfragen gelangten. Der Fix führte deshalb eine Allowlist ein: Nur Spalten, die tatsächlich im Schema der jeweiligen Response-Tabelle existieren, dürfen noch als Feldnamen verwendet werden¹.

Naming ist wichtig

Sat, 15 Aug 2026 00:00:00 +0000

Manchmal reicht ein einzelner Feldname, um zu zeigen, wie viel Architektur eigentlich in einer Namensentscheidung steckt. Ein aktueller Pull Request im LimeSurvey-Kernrepository liefert dafür ein besonders klares Beispiel.

Der Fall

Am 14. August 2026 wurde im LimeSurvey-Repository der Pull Request #5236 eingereicht: ein neues Feature, das Surveys um einen zusätzlichen, sprachunabhängigen Titel erweitert – gedacht als interne Bezeichnung zur Identifikation im Administrationsbereich, unabhängig vom öffentlich sichtbaren, lokalisierten Umfragetitel.

Technisch ist das ein sinnvolles Feature. Der bestehende Titel einer Survey (survey_languagesettings.surveyls_title) ist an eine Sprache gebunden und für interne Zwecke – etwa das Wiederfinden einer Umfrage in einer langen Liste – oft ungeeignet. Ein zweites, sprachneutrales Feld schließt eine echte Lücke.

SurveyIndex + SurveyRuntimeHelper – Anatomie eines God Flow

Wed, 06 May 2026 00:00:00 +0000

Wenn zu viel Verantwortung nicht in einer Klasse steckt, sondern in einem Ablauf

In den letzten Artikeln dieser Serie haben wir zwei bekannte Antipattern betrachtet: createFieldMap() als Beispiel einer Funktion, die zu viele Verantwortlichkeiten in sich vereint, und LimeMailer als Beispiel einer Klasse, die zu viel weiß, zu viel hält und zu viel tut. Beide Diagnosen folgten derselben Logik: Zu viel Verantwortung an einer Stelle.

Diesmal geht es um etwas anderes. Nicht eine Funktion. Nicht eine Klasse. Sondern einen Ablauf.

Refactoring – was kostet es, was kostet es nicht?

Thu, 30 Apr 2026 00:00:00 +0000

Im Artikel über createFieldMap() haben wir gesehen was eine GodFunction ist, wie sie entsteht, und wie ein Weg heraus aussehen könnte: ein sauberes Composer Package, vollständige QA-Kette, 100% Testbarkeit.

Der Plan ist klar. Die Frage die danach kommt, ist schwieriger:

Was kostet das? Und was kostet es, es nicht zu tun?

Das ist keine technische Frage mehr. Das ist eine unternehmerische. Und sie landet früher oder später auf dem Tisch des CTOs oder Lead Developers – meistens dann wenn das Budget knapp ist und die Roadmap voll.

createFieldMap() – die God Function

Sun, 26 Apr 2026 00:00:00 +0000

Im Artikel über die Helper-Funktionen haben wir common_helper.php als Ganzes betrachtet – 130+ globale Funktionen, über 11.000 Aufrufe im Code, ein Relikt aus der prozeduralen Ära. In einem anderen Artikel haben wir LimeMailer als GodClass analysiert: eine Klasse die zu viel weiß, zu viel tut, und deshalb praktisch nicht testbar ist.

Heute schauen wir auf etwas das noch subtiler ist: eine GodFunction.

Keine Klasse. Eine einzelne Funktion. Mit über 600 Zeilen Code.

LimeSurvey und die Helper-Funktionen

Sun, 29 Mar 2026 00:00:00 +0000

Wer LimeSurvey als Plugin-Entwickler nutzt oder in der Codebasis arbeitet, begegnet früher oder später diesem Muster:

Yii::app()->loadHelper('common');
Yii::app()->loadHelper('surveytranslator');
Yii::app()->loadHelper('replacements');

Dahinter steckt ein einfacher Mechanismus: loadHelper('common') lädt die Datei application/helpers/common_helper.php und macht ihre Funktionen im globalen Scope verfügbar. Dasselbe Muster findet sich auch bei loadLibrary(), das auf application/libraries/ zeigt:

public function loadHelper($helper)
{
 Yii::import('application.helpers.' . $helper . '_helper', true);
}

public function loadLibrary($library)
{
 Yii::import('application.libraries.' . $library, true);
}

Der konzeptuelle Unterschied zwischen Helper und Library ist dabei in der LimeSurvey-Codebasis kaum greifbar – beide Mechanismen lösen dasselbe Problem auf dieselbe Art. Das war in einer Zeit sinnvoll, als PHP noch kein Autoloading kannte und Funktionen manuell eingebunden werden mussten. PHP 5.1 war 2005. Composer erschien 2012.

LimeMailer - Anatomie einer God Class

Sun, 22 Mar 2026 00:00:00 +0000

LimeMailer ist die zentrale E-Mail-Komponente von LimeSurvey. Sie erbt von PHPMailer, der weit verbreiteten PHP-Mailer-Bibliothek, und erweitert diese um LimeSurvey-spezifische Logik: Umfrage-Templates, Token-Ersetzungen, Anhänge nach E-Mail-Typ, Plugin-Events und vieles mehr.

Dieser Artikel betrachtet die Klasse nicht als Fehler ihrer Entwickler. Wer in einem laufenden Open-Source-Projekt unter Zeitdruck Features liefert, trifft Entscheidungen, die im Moment vernünftig sind. Technische Schulden entstehen nicht durch Unwissenheit, sondern durch die Realität von Softwareentwicklung. Was hier analysiert wird, ist das Muster – nicht die Person dahinter.

LimeSurvey und die Hungarian Notation

Sun, 15 Mar 2026 00:00:00 +0000

Wer schon einmal einen Blick in den Quellcode von LimeSurvey geworfen hat, dem begegnet unweigerlich Folgendes:

$iSurveyId = 42;
$sLanguage = 'de';
$oSurvey = Survey::model()->findByPk($iSurveyId);
$aQuestions = $oSurvey->getQuestions();
$bActive = true;

Das Präfix verrät den Typ: i für Integer, s für String, o für Object, a für Array, b für Boolean. Diese Konvention nennt sich Hungarian Notation – und sie stammt aus einer Zeit, in der PHP noch keinerlei Typisierung kannte. LimeSurvey existiert seit über 20 Jahren, und manche dieser Muster sind genauso alt.

Der Rewrite-Reflex

Sun, 08 Mar 2026 00:00:00 +0000

Wer zum ersten Mal in eine gewachsene Codebasis eintaucht – unbekannte Strukturen, kryptische Bezeichner, Abhängigkeiten, die sich wie ein Geflecht durch das System ziehen – kennt den Impuls: neu schreiben. Sauber. Modern. Diesmal richtig.

Dieser Reflex ist verständlich. Er ist menschlich. Und er ist einer der teuersten Fehler, den ein Entwicklungsteam machen kann.

Was ist Legacy-Code überhaupt?

Bevor man über Rewrite oder Modernisierung spricht, lohnt sich ein Blick auf die Frage: Was ist Legacy-Code?