Eine kurze Geschichte der Modularität
Josh Emerson
21. November 2016
0 Min. LesezeitVor gut einer Woche waren wir als Sponsor bei der Konferenz ffconf in Brighton dabei. Es war ein Tag voller großartiger Vorträge, die zum Nachdenken anregten und zugleich praxisnah waren.Ashley Williams von npm hielt einen Vortrag mit dem Titel „Eine kurze Geschichte der Modularität“, der unserer Meinung nach besonders für Snyk relevant war. Deshalb möchten wir hier eine Zusammenfassung des Vortrags mit Ihnen teilen.
Zusätzlich zu unserer Zusammenfassung können Sie die Folien über npm herunterladen, indem Sie npm install a-brief-history ausführen (wir finden es toll, dass Ashleys Vortrag selbst ein npm-Modul ist!). Das Video wird in Kürze verfügbar sein. Sobald es so weit ist, verlinken wir es hier.
Warum modularisieren?
npm ist das größte Modul-Repository der Welt. Inzwischen gibt es dort mehr Module als bei Bower (JS), nuget (.NET), Packagist (PHP), PyPI und Rubygems.org zusammen. Warum gibt es also so viele Module bei npm?
Auf Ashleys Tweet gab es ganz unterschiedliche Reaktionen, doch die meisten nannten ähnliche Gründe für die Modularisierung von Code:
Gemeinsamer Code lässt sich wiederverwenden
Sie sorgt für eine klare Trennung der Zuständigkeiten
Sie erleichtert das Dokumentieren und Testen von Code
Warum nicht modularisieren?
Modularisierung bringt einen erheblichen Komplexitätsaufwand mit sich. Wie Guy Podjarny in Die 5 Dimensionen einer npm-Abhängigkeit beschreibt, verlassen Sie sich möglicherweise auf weit mehr Abhängigkeiten, als Ihnen zunächst bewusst ist. Bei jeder einzelnen müssen Sie sich viele Fragen stellen.
Irgendwann finden Sie ein Paket, das mehr oder weniger Ihren Anforderungen zu entsprechen scheint. Doch dann fangen die Probleme erst an. Sie müssen die Bibliothek bewerten: Gibt es Tests? Können Sie den Quellcode verstehen? Wird sie aktiv gepflegt? Ist die Dokumentation leicht zu finden und zu nutzen?
Rich Harris – Kleine Module: So einfach ist es nicht
Zusätzlich zu diesen Fragen sollten Sie auch die Sicherheit berücksichtigen. Beheben die Paketbetreuer Sicherheitslücken in ihrem Code? Gibt es bekannte Sicherheitslücken in der Abhängigkeit oder ihren Abhängigkeiten?
Softwareentwicklung bedeutet Veränderungsmanagement
Nachdem Ashley die Vorteile und Kosten der Modularisierung betrachtet hat, geht sie insbesondere auf die Diskrepanz zwischen der Wahrnehmung und der Realität der Modularisierung ein.
Wenn wir an Softwareentwicklung denken, denken wir wahrscheinlich daran, Probleme zu lösen und Systeme zu entwickeln, die Aufgaben erledigen. Was uns jedoch oft nicht bewusst ist: Software entwickelt sich kontinuierlich weiter – und nicht immer in dieselbe Richtung.
David Parnas veröffentlichte 1972 ein Buch mit dem Titel „Kriterien für die Zerlegung von Systemen in Module“, in dem er Modularisierung unter dem Gesichtspunkt des Veränderungsmanagements betrachtet.
[Beginnen Sie] mit einer Liste schwieriger Designentscheidungen oder solcher, die sich wahrscheinlich ändern werden. Jedes Modul wird dann so entworfen, dass es eine solche Entscheidung vor den anderen verbirgt.
Wenn Sie Modularisierung aus dieser Perspektive betrachten, versuchen Sie, die Komplexität in den Modulen zu verbergen, damit sich der Rest des Systems nicht mit der Implementierung befassen muss.
In seinem Blog programming is terrible zeigt uns Tef, wie Sie genau das erreichen können.
Schreiben Sie Code, der sich leicht löschen, statt leicht erweitern lässt. Statt wiederverwendbare Software zu entwickeln, sollten wir versuchen, Wegwerfsoftware zu schaffen. Ich muss Ihnen wohl nicht sagen, dass es mehr Spaß macht, Code zu löschen, als ihn zu schreiben.
Fazit
Zum Abschluss fasst Ashley zusammen, dass es schwierig ist, Code zu modularisieren, weil wir viel mehr verstehen müssen, bevor wir herausfinden können, wie und wann wir Code aufteilen sollten. Eine der größten Herausforderungen bei dieser Entscheidung ist der Faktor Zeit. Erst mit der Zeit zeigt sich, ob eine Strategie für uns funktioniert oder uns im Weg steht.
