Über die Faulheit von Programmierern

Letzte Änderung am 25. Dezember 2015 by Christoph Jüngling

Dass Daten (und zunächst ist Programmcode auch nicht mehr als das) fast nach Belieben kopiert werden können, bejammert die Musikindustrie täglich auf’s Neue. Was dort aufgrund der Gesetzeslage verboten ist, versuchen Programmierer mit Fleiß überhaupt erst möglich zu machen. Denn, mal ehrlich, warum sollte jemand ein und dieselbe Funktion immer und immer wieder neu programmieren, wenn er sie doch genauso gut wiederverwenden kann?

Ja, die Faulheit von Programmierern ist bekannt, aber sie hat auch ihren Grund. Während es in klassischen Fertigungsbetrieben darauf ankommt, immer wieder das gleiche zu machen, wird ein Programmierer dies tunlichst vermeiden. Genau genommen sind Softwareentwicklung und Fertigung in diesem einen Punkt aber gar nicht so verschieden, denn in beiden Fällen wird versucht, die Arbeit jeden Tag ein wenig besser zu machen. Nur dass dies in der Fertigung den Herstellungsprozess betrifft, während in der Softwareentwicklung das Produkt selbst direkt von der Verbesserung profitiert. Das ist auch verständlich: Dieses eine Getriebe, das Franziskus gerade zusammengeschraubt hat, wird er nie wieder verbessern können, auch wenn er beim nächsten Getriebe bessere Arbeit leistet. Doch wenn Programmierer Karl feststellt, dass eine Klasse einen kleinen Fehler enthält, wird er den Fehler eliminieren und die Klasse wird fortan (und vielleicht sogar in bereits fertigen Programmen) ihren Job besser machen.

Wiederverwendbarkeit

Damit Programmcode wiederverwendet werden kann, muss er natürlich in einer Weise geschrieben sein, die dies möglich macht. Ein paar Basisanforderungen an solchen Code könnten sein:

  1. Eine einzige klar umrissene Aufgabe
  2. Saubere Schnittstelle
  3. Gute Dokumentation
  4. Einhaltung von Code-Konventionen

Das bis hierher gesagte ist zunächst von einer konkreten Programmiersprache unabhängig. Ich will nun einen konkreten Fall schildern, bei dem mir dies besonders aufgefallen ist. Schauen wir uns den folgenden Python-Code an:

with open (path, 'r') as myfile:
    filelist = FileList(myfile)

Die Klasse FileList könnte dann so anfangen:

import xml.etree.ElementTree as ET

class FileList(object):
    def __init__(self, filename):
        tree = ET.parse(filename)
        root = tree.getroot()

Dann stellte ich mir vor (man will ja alles richtig machen), dass ich zunächst einen Unit-Test dafür schreiben sollte will. Dieser müsste die Datei im Filesystem bereit stellen, damit die Klasse FileList bei der Testausführung darauf zugreifen kann. Klingt umständlich, oder? Was also tun?

Separation of Concerns

Unter diesem Begriff versteht man, dass “verschiedene Elemente der Aufgabe (…) möglichst in verschiedenen Elementen der Lösung repräsentiert werden [sollten]” (Wikipedia). Was bedeutet das im konkreten Fall?

Die Klasse FileList, so klein sie im Moment auch ist, hat bereits mehrere erkennbare Aufgaben:

  1. Eine Datei öffnen
  2. Den Inhalt der Datei lesen
  3. Den Inhalt der Datei als XML interpretieren

Trennen wir die ersten beiden Teile ab und überlassen der Klasse nur noch den Umgang mit dem Dateiinhalt (XML), dann wird das hier nicht nur übersichtlicher, sondern auch der Unit-Test wird um einiges einfacher. Und das sieht dann so aus ( Code zum Artikel: Über die Faulheit von Programmierern (2576 Downloads ) ):

Aufruf:

with open (path, 'r') as myfile:
    filelist = FileList(myfile.readlines())

Klasse:

import xml.etree.ElementTree as ET

class FileList(object):
    def __init__(self, filedata):
        self._root = ET.fromstring(filedata)

    def getsomething(self):
        return 'whatsoever'

Unit-Test:

import unittest
from filelist import FileList

class Test(unittest.TestCase):
    def setUp(self):
        self._filedata = """
    Hier steht das XML, das WordPress oder Genshi
    aber leider komplett zerrissen haben.
"""

    def testReadFileList(self):
        fl = FileList(self._filedata)
        expected = 'whatsoever'
        actual = fl.getsomething()
        self.assertEqual(expected, actual)

Natürlich ist die Methode “getsomething” ziemlich sinnlos, aber das mag uns im Moment nicht weiter stören. Das Prinzip ist hoffentlich klar geworden: Klar umrissene Aufgabe, saubere Schnittstelle. Faulheit kann also so schlimm nicht sein.

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

7 + 7 =