Dies ist der erste Teil von „Code as Design“: Drei Aufsätze von Jack W. Reeves. Dieser Aufsatz erschien erstmals in der Herbstausgabe 1992 des C++ Journal. Als Basis für diese Übersetzung dient die Veröffentlichung auf developer.*
Objektorientierte Techniken, und insbesondere C++, scheinen die Software-Welt im Sturm zu erobern. Es sind zahlreiche Artikel und Bücher erschienen, die beschreiben, wie die neuen Techniken anzuwenden sind. Im Allgemeinen ist die Frage, ob O-O-Techniken nur ein Hype sind, durch die Frage ersetzt worden, wie man die Vorteile mit dem geringsten Aufwand erreichen kann. Objektorientierte Techniken gibt es schon seit einiger Zeit, aber diese explodierende Popularität scheint etwas ungewöhnlich zu sein. Warum das plötzliche Interesse? Es wurden alle möglichen Erklärungen angeboten. In Wahrheit gibt es wahrscheinlich keinen einzigen Grund. Wahrscheinlich hat eine Kombination von Faktoren endlich eine kritische Masse erreicht, und die Dinge kommen in Schwung. Nichtsdestotrotz scheint es, dass C++ selbst ein wichtiger Faktor in dieser jüngsten Phase der Software-Revolution ist. Auch dafür gibt es wahrscheinlich eine Reihe von Gründen, aber ich möchte eine Antwort aus einer etwas anderen Perspektive vorschlagen: C++ ist populär geworden, weil es das gleichzeitige Entwerfen von Software und Programmieren erleichtert.
Wenn diese Bemerkung etwas ungewöhnlich erscheint, dann ist sie beabsichtigt. Was ich in diesem Artikel tun möchte, ist, einen Blick auf die Beziehung zwischen Programmierung und Software-Design zu werfen. Seit fast 10 Jahren habe ich das Gefühl, dass die Softwareindustrie kollektiv einen subtilen Punkt über den Unterschied zwischen der Entwicklung eines Software-Designs und dem, was ein Software-Design wirklich ist, übersieht. Ich denke, es gibt eine tiefgreifende Lektion in der wachsenden Popularität von C++ darüber, was wir tun können, um bessere Software-Ingenieure zu werden, wenn wir es nur sehen. Diese Lektion besagt, dass es beim Programmieren nicht darum geht, Software zu bauen; beim Programmieren geht es darum, Software zu entwerfen.
Vor Jahren habe ich an einem Seminar teilgenommen, bei dem die Frage aufkam, ob Softwareentwicklung eine Ingenieursdisziplin ist oder nicht. Ich erinnere mich zwar nicht an die sich daraus ergebende Diskussion, aber ich erinnere mich, wie sie mein eigenes Denken katalysierte, dass die Softwareindustrie einige falsche Parallelen zur Hardwaretechnik geschaffen hat, während einige vollkommen gültige Parallelen fehlen. Im Wesentlichen kam ich zu dem Schluss, dass wir keine Software-Ingenieure sind, weil wir nicht erkennen, was ein Software-Design wirklich ist. Davon bin ich heute noch mehr überzeugt.
Das Endziel jeder Ingenieurtätigkeit ist irgendeine Art von Dokumentation. Wenn eine Designarbeit abgeschlossen ist, wird die Designdokumentation dem Fertigungsteam übergeben. Dies ist eine völlig andere Gruppe mit völlig anderen Fähigkeiten als das Konstruktionsteam. Wenn die Konstruktionsunterlagen wirklich eine vollständige Konstruktion darstellen, kann das Fertigungsteam mit dem Bau des Produkts fortfahren. In der Tat kann es ohne weiteres Zutun der Konstrukteure mit dem Bau von Losen des Produkts fortfahren. Nachdem ich den Softwareentwicklungs-Lebenszyklus, so wie ich ihn verstanden habe, überprüft hatte, kam ich zu dem Schluss, dass die einzige Softwaredokumentation, die tatsächlich die Kriterien eines technischen Entwurfs zu erfüllen scheint, die Auflistung des Quellcodes ist.
Es gibt wahrscheinlich genug Argumente sowohl für als auch gegen diese Prämisse, um zahlreiche Artikel zu füllen. Dieser Artikel geht davon aus, dass der endgültige Quellcode der eigentliche Softwareentwurf ist, und untersucht dann einige der Konsequenzen dieser Annahme. Ich bin vielleicht nicht in der Lage zu beweisen, dass dieser Standpunkt richtig ist, aber ich hoffe, zeigen zu können, dass er einige der beobachteten Tatsachen der Softwareindustrie erklärt, einschließlich der Popularität von C++.
Es gibt eine Konsequenz, Code als Software-Design zu betrachten, die alle anderen völlig überwältigt. Es ist so wichtig und so offensichtlich, dass es für die meisten Software-Organisationen ein totaler blinder Fleck ist. Das ist die Tatsache, dass Software billig zu bauen ist. Sie gilt nicht als billig; sie ist so billig, dass sie fast kostenlos ist. Wenn der Quellcode ein Software-Design ist, dann wird die eigentliche Erstellung von Software von Compilern und Linkern erledigt. Wir bezeichnen den Prozess des Kompilierens und Verknüpfens eines kompletten Softwaresystems oft als „einen Bau ausführen“. Die Investition in Software-Baumaschinen ist gering, man braucht eigentlich nur einen Computer, einen Editor, einen Compiler und einen Linker. Sobald eine Build-Umgebung zur Verfügung steht, dauert das eigentliche Erstellen eines Software-Builds nur noch ein wenig Zeit. Das Kompilieren eines C++-Programms mit 50.000 Zeilen scheint ewig zu dauern, aber wie lange würde es dauern, ein Hardwaresystem zu bauen, dessen Design dieselbe Komplexität aufweist wie 50.000 Zeilen C++.
Eine weitere Folge der Betrachtung von Quellcode als Software-Design ist die Tatsache, dass ein Software-Design relativ einfach zu erstellen ist, zumindest im mechanischen Sinne. Das Schreiben (d.h. der Entwurf) eines typischen Software-Moduls von 50 bis 100 Zeilen Code ist normalerweise nur ein paar Tage Arbeit (es vollständig zu debuggen ist eine andere Geschichte, aber dazu später mehr). Es ist verlockend zu fragen, ob es irgendeine andere Ingenieursdisziplin gibt, die Entwürfe von solcher Komplexität wie Software in so kurzer Zeit erstellen kann, aber zuerst müssen wir herausfinden, wie man Komplexität messen und vergleichen kann. Nichtsdestotrotz ist es offensichtlich, dass Software-Entwürfe ziemlich schnell sehr groß werden.
Angesichts der Tatsache, dass Software-Designs relativ einfach zu erstellen und im Wesentlichen frei zu bauen sind, ist eine nicht überraschende Offenbarung, dass Software-Designs