In der Softwareentwicklung sind TODO-Kommentare eine beliebte Methode, um auf noch ausstehende Arbeiten im Code hinzuweisen. Doch was passiert, wenn sich diese TODOs wie Schokosplitter in einem Stracciatella-Eis verteilen und den gesamten Code durchziehen? In diesem Blogbeitrag werfen wir einen genaueren Blick auf diese g\u00e4ngige Entwickler-Gewohnheit, beleuchten die damit verbundenen Probleme und zeigen auf, wie man es besser machen kann \u2013 und warum das wichtig ist.
\n<\/p>\n
Jeder Entwickler kennt es: Im Laufe der Entwicklung entsteht Code, der aus verschiedenen Gr\u00fcnden nicht vollst\u00e4ndig ist. M\u00f6glicherweise handelt es sich um \u00dcbergangsl\u00f6sungen, die aufgrund externer Abh\u00e4ngigkeiten notwendig sind, oder um Workarounds, die anstelle einer noch fehlenden Library-Funktion implementiert wurden. Der erste Schritt, diese Stellen im Code durch einen TODO-Kommentar zu kennzeichnen, ist naheliegend und sinnvoll. Doch h\u00e4ufig bleibt es nicht bei einem einzigen TODO. Im hektischen Entwickleralltag k\u00f6nnen sich solche Kommentare vermehren und geraten dabei oft in Vergessenheit. Manchmal sind sie sogar \u00dcberbleibsel aus der Entwicklungsphase eines Tickets, die unbemerkt das Code Review \u00fcberstanden haben.<\/p>\n
Das Problem hierbei: Mit der Zeit entstehen verstreute TODO-Kommentare, die den Code wie ein Stracciatella-Eis durchziehen \u2013 kleine, unscheinbare \u201eSchokosplitter\u201c, die auf offene Baustellen hinweisen. Doch was als schnelle Notiz f\u00fcr die Zukunft gedacht ist, kann sich langfristig als problematisch erweisen.<\/p>\n
TODO-Kommentare haben eine zentrale Schw\u00e4che: Sie verbleiben im Code und werden leicht \u00fcbersehen. Auch wenn sie darauf hinweisen, dass es noch etwas zu tun gibt, geschieht dies oft nur auf Ebene des individuellen Entwicklers. In modernen Entwicklungsprojekten, egal ob agil oder klassisch gemanagt, sind es jedoch nicht die einzelnen Entwickler, die allein entscheiden, was als N\u00e4chstes erledigt werden muss. Diese Entscheidungen liegen bei Projektmanagern, Product Ownern oder \u00e4hnlichen Rollen, die den \u00dcberblick \u00fcber das gesamte Projekt behalten m\u00fcssen.<\/p>\n
Das Problem ist, dass TODO-Kommentare nicht sichtbar genug f\u00fcr diese Entscheider sind. So bleibt der n\u00f6tige Raum f\u00fcr Wartungsarbeiten, das Entfernen von Workarounds oder das Aufl\u00f6sen von Abh\u00e4ngigkeiten oft unber\u00fccksichtigt. Zudem manifestiert sich ein Problem selten nur an einer einzigen Stelle im Code. Einzelne TODOs schaffen es nicht, gr\u00f6\u00dfere Zusammenh\u00e4nge darzustellen, was zu einer unstrukturierten und unvollst\u00e4ndigen Bearbeitung von Aufgaben f\u00fchren kann.<\/p>\n
TODO-Kommentare sind n\u00fctzlich \u2013 aber nur, wenn sie richtig eingesetzt werden. Sobald sich abzeichnet, dass ein TODO-Kommentar \u00fcber die Implementierung des aktuellen Tickets hinaus Bestand haben wird, sollte ein neues Ticket im Projektmanagementsystem angelegt werden. Dieser Schritt sorgt daf\u00fcr, dass die offene Aufgabe sichtbar und nachvollziehbar wird. Durch das Anlegen eines Tickets wird ein Anker gesetzt, \u00fcber den alle TODOs, die sich auf dasselbe Problem beziehen, zugeordnet werden k\u00f6nnen.<\/p>\n
Dar\u00fcber hinaus sollten TODO-Kommentare immer nach einer einheitlichen Syntax gestaltet werden. So lassen sie sich mithilfe einer IDE schnell und zuverl\u00e4ssig finden. Ein hilfreicher Tipp ist, bereits w\u00e4hrend der Entwicklung die Ticket-ID direkt im Kommentar zu hinterlegen. Dies erleichtert nicht nur die sp\u00e4tere Kontrolle, sondern beschleunigt auch das Code Review, da die Kommentare sofort im Kontext des entsprechenden Tickets eingeordnet werden k\u00f6nnen.<\/p>\n
Die strukturierte Handhabung von TODO-Kommentaren verbessert die Transparenz im Entwicklungsprozess erheblich. Durch das Anlegen von Tickets werden offene Aufgaben sichtbar und k\u00f6nnen in die Projektplanung integriert werden. Das hilft nicht nur den Entscheidern, sondern auch dem gesamten Team, die \u00dcbersicht zu behalten. Einzelne TODOs bleiben nicht l\u00e4nger isolierte Hinweise im Code, sondern werden Teil eines gr\u00f6\u00dferen Zusammenhangs, der gezielt und systematisch bearbeitet werden kann.<\/p>\n
Einheitliche Syntax und die Zuordnung von Ticket-IDs schaffen zudem Klarheit. Entwickler k\u00f6nnen schneller arbeiten, da sie nicht erst nach den passenden TODOs suchen m\u00fcssen. Das Code Review wird effizienter, und die Wartung des Codes vereinfacht sich. Insgesamt f\u00fchrt dies zu einer h\u00f6heren Codequalit\u00e4t, besserer Planbarkeit und letztlich zu einem produktiveren Team.<\/p>\n
TODO-Kommentare sollten also nicht wie zuf\u00e4llige Schokosplitter im Code verstreut bleiben, sondern strukturiert und bewusst eingesetzt werden. So kann aus einem anf\u00e4nglich kleinen Hinweis eine gut dokumentierte und nachverfolgbare Aufgabe werden, die im Team effektiv bearbeitet wird.<\/p>\n
Wie werden ToDo’s bei Ihrer Entwicklung gehandhabt?<\/p>\n