Erstmals holte das Land die erste Stufe einer Trägerrakete kontrolliert zurück. Die Stufe der neuen Rakete „Langer Marsch 10B“ wurde auf einer Plattform auf See aufgefangen, wie die staatliche Nachrichtenagentur Xinhua berichtete.

Es war der erste Flug der neuen Rakete. Xinhua sprach von einem „bedeutenden Durchbruch“. Ein von der Agentur veröffentlichtes Video zeigt, wie die Raketenstufe mit laufendem Triebwerk auf die Plattform zufliegt und nahezu senkrecht in ein hohes, rechteckiges Gerüst sinkt.

Nach Angaben der Zeitung „China Daily“ wartete das Rückholschiff „Linghangzhe“ („Pfadfinder“) auf die Raketenstufe. Das Schiff verfolgte sie und passte seine Position laufend an. Spezielle Metallhaken klappten schließlich aus und griffen in die gespannten Seile der Fangvorrichtung. Die Rakete war vom Weltraumbahnhof Hainan gestartet und brachte einen Satelliten in die vorgesehene Umlaufbahn.

SpaceX ist schon deutlich weiter

China sei laut der staatlichen Zeitung damit nach den USA das zweite Land, das über eine zuverlässige Technik für wiederverwendbare Raketen verfüge. Zugleich sei weltweit erstmals die erste Stufe einer mit einer solchen Seil-Fangvorrichtung geborgen worden.

Vor allem das US-Raumfahrtunternehmen SpaceX ist bei wiederverwendbaren Raketen deutlich weiter. China treibt die Entwicklung seit Jahren voran. Neben dem staatlichen Raumfahrtprogramm arbeiten auch mehrere private chinesische Unternehmen an der Technik, die es ermöglichen soll, Satelliten und andere Lasten günstiger ins All zu bringen.

(afl)

Microsoft hat die finale Version von TypeScript 7.0 veröffentlicht. Im Gegensatz zu früheren TypeScript-Versionen basiert der Compiler nicht mehr auf JavaScript/Node.js, sondern ist nahezu eins zu eins in Go nachimplementiert und parallelisiert viele Arbeitsabläufe, statt sie wie bisher sequenziell abzuarbeiten. Beides führt laut Microsoft dazu, dass die Toolchain je nach Anwendungsfall zehnmal schneller kompiliert als bei TypeScript 6.0.

Gegenüber der im April veröffentlichten Beta-Version hat sich nichts Grundlegendes mehr geändert. Das finale Release konzentriert sich auf den produktionsreifen Abschluss, wie Microsoft im Blogpost zu TypeScript 7.0 schreibt: Umstellung auf das reguläre typescript-Paket, verbesserter --watch-Modus, vollständigerer Editor-Support, mehr Stabilität und klarere Migrationspfade für das TypeScript-Ökosystem.

Schneller kompiliert und geladen, weniger Speicherhunger

In seinem Blog nennt Microsoft Performance-Beispiele, die sich jeweils auf einen hardwareseitig nicht näher spezifizierten Computer beziehen.

Den Quellcode von VS-Code baut TypeScript 7.0 auf dem Testsystem um den Faktor 11,9 schneller als unter TypeScript 6.0, was die Kompilierungszeit von mehr als zwei Minuten auf knapp 11 Sekunden drückt. Bei Sentry, Bluesky und Playwright ergeben sich Beschleunigungsfaktoren von jeweils knapp unter 9 Sekunden, tldraw-Beispielprojekte kommen auf 7,7-faches Tempo.

Das Öffnen einer fehlerbehafteten Datei in VS Code auf dem gleichen Testsystem läuft ebenfalls schneller ab. Vergehen bei TypeScript 6.0 noch 17,5 Sekunden vom Öffnen einer fehlerhaften Datei bis zur Anzeige der Fehlermeldung, dauert das Gleiche bei TypeScript 7.0 unter 1,3 Sekunden. Neben dem Geschwindigkeitszuwachs ergibt sich laut Microsoft projektübergreifend auch ein geringerer Speicherbedarf. Während er bei Sentry um sechs Prozent sinkt, reduziert er sich bei VS Code um 18 Prozent und bei Bluesky um etwas mehr als ein Viertel.

TypeScript 6.0/7.0: Parallelbetrieb möglich

TypeScript 7.0 lässt sich via npm mit npm install -D typescript parallel zu TypeScript 6.0 installieren und ist mit dessen Type-Checking- und Kommandozeilenverhalten kompatibel. Der bekannte Befehl tsc startet dann den neuen TypeScript-7.0-Compiler. Zusätzlich gibt es das Kompatibilitätspaket @typescript/typescript6, das zusätzlich tsc6 sowie die bisherige TypeScript-6.0-API bereitstellt, damit bestehende Tools vorerst unverändert weiterlaufen können. Eine neue API soll erst mit TypeScript 7.1 kommen.

(mro)

Die Unmöglichkeit eines verteilten Konsens war das Thema des dritten Teils dieser Serie. Eine andere Form von Unmöglichkeit zeigt sich beim Versuch, ein scheinbar einfaches Konzept messbar zu machen: die Qualität von Code. Anders als bei verteiltem Konsens scheitert dieser Versuch nicht an einem Beweis aus der theoretischen Informatik, sondern an etwas, das sich für die Praxis ebenso unverrückbar anfühlt.

Seit den 1970er-Jahren versucht die Branche, Codequalität zu quantifizieren: Lines of Code, zyklomatische Komplexität, Halstead-Metrik, Maintainability Index, Code Coverage. Jede neue Methodik bringt neue Zahlen mit, jedes IDE-Plug-in zeigt aktuelle Werte an, jede CI-Pipeline produziert Reports. Die Vorstellung dahinter ist verständlich: Wenn sich Codequalität messen lässt, lässt sich Codequalität systematisch verbessern. Wenn sich Codequalität verbessern lässt, lassen sich Wartungskosten senken, Bugs reduzieren und Entwicklungszeiten kürzer planen.

Trotzdem lässt sich allein anhand einer einzelnen Zahl nicht verlässlich sagen, ob ein konkretes Stück Code gut ist. Erfahrene Entwicklerinnen und Entwickler erkennen guten Code beim Lesen, und schlechten ebenso. Das ist keine Frage von Erfahrungswissen, das sich noch nicht in Zahlen fassen ließe, sondern hat strukturelle Gründe. Codequalität ist ein vielschichtiges Konstrukt, dessen wichtigste Dimensionen sich der Quantifizierung entziehen. Und wo Metriken doch existieren, machen sie Probleme, die im Mess- und Anreizsystem selbst angelegt sind.

Vom Sinn und Unsinn klassischer Metriken

Die wohl älteste Codemetrik ist die Anzahl der Programmzeilen, oft als LOC oder SLOC abgekürzt. Sie ist trivial zu erheben und auf den ersten Blick objektiv. Auf den zweiten Blick fragt sich, was sie eigentlich aussagt. Bill Gates wird das Zitat zugeschrieben, Programmierproduktivität in Codezeilen zu messen sei wie Fortschritt im Flugzeugbau am Gewicht zu messen. Die Pointe trifft den Kern: Mehr Codezeilen sind nicht besser, oft sogar schlechter. Eine Funktion in zwei Zeilen ist häufig wartbarer als die gleiche Funktion in zwanzig.

Die zyklomatische Komplexität wurde 1976 von Thomas McCabe eingeführt. Sie zählt die Anzahl unabhängiger Pfade durch eine Funktion und gibt damit ein Maß für die Verzweigungstiefe. Die Idee: Je mehr Pfade, desto mehr Testfälle nötig, desto schwerer der Code zu verstehen. Das ist nicht falsch, aber unvollständig. Eine switch-Anweisung mit zwanzig Fällen hat eine hohe zyklomatische Komplexität, ist aber oft trivial zu verstehen, weil alle Fälle ähnlich strukturiert sind. Eine Funktion mit drei tief geschachtelten if-Anweisungen hat eine niedrigere Komplexität, kann aber schwer durchschaubar sein.

Die Halstead-Metrik, 1977 von Maurice Halstead vorgeschlagen, geht einen anderen Weg. Sie zählt Operatoren und Operanden im Code und leitet daraus Maße für Programmlänge, Schwierigkeitsgrad und benötigten Aufwand ab. Auch hier liegt eine plausible Intuition zugrunde, doch die abgeleiteten Formeln wurden in zahlreichen Studien nur mit gemischtem Erfolg validiert.

Code Coverage misst schließlich nicht den Code selbst, sondern wie viel davon durch Tests ausgeführt wird. Sie ist die populärste Metrik in modernen Entwicklungsumgebungen, gerade weil sie sich automatisch erheben und in Pipelines durchsetzen lässt. Was sie aussagt, ist allerdings begrenzt. Eine Zeile, die einmal von einem Test durchlaufen wurde, gilt als abgedeckt, ganz gleich, ob dieser Test eine sinnvolle Aussage trifft oder nur eine Funktion aufruft, ohne ihre Ausgabe zu prüfen. 100 Prozent Code Coverage bedeuten nicht, dass 100 Prozent des Verhaltens geprüft sind.

Goodharts Gesetz

Diese Schwächen einzelner Metriken sind aber nur ein Teil des Problems. Das tieferliegende Problem hat 1975 der britische Wirtschaftswissenschaftler Charles Goodhart in einer Aussage über Geldpolitik formuliert, die längst weit über die Ökonomie hinaus gilt: Sobald eine Metrik zum Ziel wird, hört sie auf, ein guter Indikator zu sein. Diese Beobachtung ist heute als Goodharts Gesetz bekannt.

Die Mechanik dahinter ist einfach. Solange eine Metrik nur beobachtet wird, korreliert sie womöglich tatsächlich mit der Eigenschaft, die sie messen soll. Sobald aber Anreize an die Metrik gekoppelt werden, beginnen die Beteiligten, gezielt diese Metrik zu optimieren, und nicht die Eigenschaft, die sie eigentlich erfassen sollte. Die Korrelation bricht zusammen.

In der Softwareentwicklung lässt sich das Phänomen in zahlreichen Varianten beobachten. Wer Codezeilen als Produktivitätsmaß heranzieht, erntet aufgeblähten Code mit überflüssigen Hilfsfunktionen und gekünstelten Abstraktionen. Wer Code Coverage als verbindliches Ziel setzt, erntet Tests, die Funktionen aufrufen, ohne deren Ergebnisse zu prüfen. Wer die Anzahl gefundener Bugs als Produktivität von Testenden misst, erntet endlose Diskussionen darüber, was als Bug gilt. Wer geschlossene Tickets als Performance-Indikator verwendet, erntet zerlegte Tickets, die einzeln keinen Wert haben.

Das ist kein Versagen einzelner Beteiligter, sondern eine logische Konsequenz aus dem Anreizsystem. Menschen optimieren das, woran sie gemessen werden. Wenn die Messung nicht das Gleiche misst wie das Ziel, optimieren sie an der eigentlichen Aufgabe vorbei. Goodharts Gesetz ist nicht spezifisch für Software, aber besonders sichtbar in einer Disziplin, in der sich so vieles automatisch erfassen und in Dashboards anzeigen lässt.

Was Weyuker formal gezeigt hat

Auch jenseits des Anreizproblems gibt es einen formaleren Grund, warum die Suche nach der einen Codemetrik scheitern muss. Die Informatikerin Elaine Weyuker formulierte 1988 in einem einflussreichen Aufsatz neun Eigenschaften, die eine sinnvolle Komplexitätsmetrik erfüllen sollte. Diese Eigenschaften sind nicht willkürlich gewählt, sondern geben intuitiven Erwartungen eine formale Form. Wenn ein Programm intuitiv komplexer ist als ein anderes, sollte die Metrik das widerspiegeln. Wenn zwei Programme zu einem zusammengesetzt werden, sollte die Komplexität nicht kleiner werden als die Komplexität jedes einzelnen Bestandteils. Die Reihenfolge der Anweisungen sollte sich auf die Metrik auswirken, weil sie sich auf das Verhalten des Programms auswirkt.

Das Ergebnis von Weyukers Untersuchung war ernüchternd. Keine der zu diesem Zeitpunkt etablierten Metriken erfüllte alle neun Eigenschaften. Lines of Code versagt bereits bei einfachen Anforderungen, weil identische Programme als unterschiedlich eingeordnet werden, sobald die Formatierung variiert. Zyklomatische Komplexität versagt bei der Zusammensetzung, weil zwei sequenziell ausgeführte Funktionen mit jeweils Komplexität fünf zusammen nur eine Komplexität von neun ergeben, nicht von zehn oder mehr. Die Halstead-Metrik versagt bei der Reihenfolge, weil eine Permutation der Anweisungen sie nicht ändert, obwohl das Verhalten ein völlig anderes sein kann.

Spätere Arbeiten haben einzelne Metriken entwickelt, die mehr von Weyukers Eigenschaften erfüllen, aber keine Metrik, die alle erfüllt. Das ist kein Zufall, sondern ein formales Indiz, dass die Suche nach der einen Komplexitätszahl strukturell scheitert. Komplexität ist nicht eindimensional. Verschiedene Aspekte wie Verzweigungstiefe, Datenflusskomplexität, Schnittstellenkomplexität und kognitive Last können nicht alle gleichzeitig in einer einzigen Zahl repräsentiert werden, ohne wesentliche Informationen zu verlieren.

Die multidimensionale Natur von Qualität

Selbst wenn es eine perfekte Komplexitätsmetrik gäbe, wäre damit das Problem der Codequalität nicht gelöst. Codequalität ist nicht gleich Komplexität, und sie ist auch nicht gleich Korrektheit oder Wartbarkeit oder Performance. Sie ist ein Bündel mehrerer Eigenschaften, die teilweise miteinander in Spannung stehen.

Korrektheit bedeutet, dass der Code macht, was er machen soll. Lesbarkeit, dass andere ihn verstehen können. Wartbarkeit, dass er sich verändern lässt, ohne Schaden anzurichten oder Fehler einzubauen. Performance, dass er die nötige Geschwindigkeit erreicht. Sicherheit, dass er sich nicht missbrauchen lässt. Erweiterbarkeit, dass sich neue Funktionen ergänzen lassen. Testbarkeit, dass sich sein Verhalten nachvollziehen lässt. Diese Dimensionen sind nicht orthogonal. Höhere Performance kann Lesbarkeit kosten, weil hochoptimierter Code oft kryptischer ist. Höhere Sicherheit kann Erweiterbarkeit kosten, weil restriktive Schnittstellen weniger Spielraum lassen. Höhere Testbarkeit kann Performance kosten, weil testbarer Code oft mehr Indirektion enthält.

Eine einzelne Metrik kann notwendigerweise nur eine dieser Dimensionen erfassen, oder sie kann mehrere aggregieren und verliert dabei die Information, welche Dimension wie stark beiträgt. Ein Maintainability Index, der aus zyklomatischer Komplexität, Halstead-Metrik und Kommentaranteil berechnet wird, gibt am Ende eine Zahl zwischen null und hundert aus. Diese Zahl mag als Indikator für grobe Trends nützlich sein, aber sie sagt nicht, ob der Code im konkreten Fall gut ist, und schon gar nicht, woran es liegt, wenn er es nicht ist.

Was keine Metrik je erfassen wird

Den vielleicht wichtigsten Aspekt von Codequalität verfehlen die etablierten Metriken aus einem Grund, der oft übersehen wird. Sie konzentrieren sich auf strukturelle Eigenschaften des Codes wie Verzweigungen, Operatoren und Pfade und ignorieren etwas, das für die Verständlichkeit zentral ist: die Namensgebung der Bezeichner.

Zwei Funktionen können bezüglich aller etablierten Metriken identisch sein, in zyklomatischer Komplexität, Halstead-Metrik und Codezeilen. Trotzdem kann die eine deutlich besser verständlich sein als die andere. Eine Funktion berechne(a, b, c) mit den Variablen x, y und z im Rumpf gibt keinen Hinweis darauf, was sie eigentlich macht. Dieselbe Funktion als berechneRechnungssumme(bruttopreis, menge, rabatt) mit den entsprechenden Bezeichnern im Rumpf erschließt sich beim Lesen sofort. Die Struktur des Codes ist identisch, die Verständlichkeit grundlegend verschieden.

Sprechende Namen aus der Fachdomäne machen Code zu einer Form von Dokumentation, die mit dem Code selbst lebt und nicht veraltet. Sie verbinden den Code mit dem Problem, das er löst, und nicht nur mit der Maschine, auf der er läuft. Donald Knuth hat diese Sicht mit dem Begriff des Literate Programming auf die Spitze getrieben. Er versteht Programme als ausführbare Texte, die für Menschen geschrieben sind, und für die Maschine nur sekundär. Eric Evans hat mit Domain-Driven Design einen ähnlichen Anspruch in den industriellen Mainstream gebracht, mit dem Konzept der ubiquitären Sprache: Begriffe aus der Fachdomäne ziehen sich konsistent durch alle Schichten der Software, von Anforderungen über Code bis zu Datenbankschemata.

Diese Aspekte, die Aussagekraft der Namen, die Übereinstimmung mit der Domäne, die Klarheit der Abstraktionen, entziehen sich jeder mechanischen Messung. Eine Metrik, die feststellen würde, ob ein Variablenname „aussagekräftig“ ist, müsste verstehen, wovon der Code handelt, was die Domäne ist und welche Begriffe in dieser Domäne etabliert sind. Sie müsste, kurz gesagt, den Code nicht nur strukturell analysieren, sondern semantisch deuten. Genau dieser Schritt ist von keiner heute existierenden statischen Analyse zu leisten. Auch große Sprachmodelle, die Code zumindest oberflächlich beurteilen können, liefern keine Metriken im engeren Sinne, sondern subjektive Einschätzungen, die sich nicht zuverlässig automatisieren lassen.

Pragmatischer Umgang mit Metriken

Die Konsequenz aus all dem ist nicht, Metriken abzuschaffen. Sie können nützliche Indikatoren sein, solange sie als Hinweise verstanden werden und nicht als Ziele. Eine plötzlich steigende zyklomatische Komplexität in einem Modul kann ein sinnvolles Warnsignal sein. Ein Trend zu fallender Code Coverage kann Anlass für eine Diskussion sein. Eine Funktion mit auffällig vielen Zeilen kann ein Kandidat für ein Refactoring sein.

Was sich aus Goodharts Gesetz und der multidimensionalen Natur von Qualität ergibt, ist ein anderer Umgang mit diesen Werten. Mehrere komplementäre Metriken statt einer einzelnen, weil keine einzelne Metrik die Qualität abdeckt. Trends statt absoluter Werte, weil ein Wert allein wenig aussagt, eine Veränderung aber durchaus. Indikatoren statt Ziele, weil das Koppeln von Anreizen die Aussagekraft zerstört.

Die unersetzliche Rolle bleibt das menschliche Urteil. Code-Reviews sind in fast allen ernsthaften Entwicklungsteams etabliert, nicht aus Tradition, sondern weil sie genau das erfassen, was Metriken nicht abbilden: ob der Code für andere Menschen verständlich ist. Erfahrene Entwicklerinnen und Entwickler bringen ein implizites Qualitätsverständnis mit, das sich nicht in Regeln erschöpft, aber bei der Lektüre eines Pull Requests sofort wirksam wird. Ein gutes Code-Review findet die Probleme, die keine statische Analyse je erkennen würde, nicht weil Werkzeuge nicht genutzt werden, sondern weil Reviewerinnen und Reviewer verstehen, was der Code zu sagen versucht.

Was sich messen lässt, und was nicht

Codequalität entzieht sich der einen Zahl, nicht weil bessere Metriken noch nicht erfunden wurden, sondern weil sie ein vielschichtiges Konstrukt ist, dessen wichtigste Dimensionen sich der Quantifizierung prinzipiell entziehen. Was sich messen lässt, also Zeilen, Pfade, Operatoren, Coverage, sagt etwas über die Struktur des Codes, aber wenig über seine Qualität. Was die Qualität ausmacht, also Klarheit der Absichten, Übereinstimmung mit der Domäne, Aussagekraft der Namen, Angemessenheit der Abstraktionen, lässt sich nicht in Zahlen pressen.

Wer trotzdem versucht, Codequalität auf eine einzelne Zahl zu reduzieren, erreicht meist das Gegenteil des angestrebten Ziels. Goodharts Gesetz wirkt zuverlässig, und Teams, die nach Metriken gesteuert werden, optimieren irgendwann die Metriken statt die Qualität. Wer die Codequalität wirklich verbessern will, kommt um menschliches Urteil nicht herum, ergänzt durch Metriken als Indikatoren, aber nicht ersetzt durch sie.

Eine besonders verführerische Metrik in dieser Reihe ist die Code Coverage. Sie suggeriert, dass mehr abgedeckte Zeilen besser getesteten Code bedeuten, und sie ist in modernen Entwicklungsumgebungen so leicht zu erheben, dass sie schnell zur zentralen Steuerungsgröße wird. Im nächsten Teil dieser Serie zeigt sich, warum auch das Testen selbst an fundamentale Grenzen stößt, mit dem Halteproblem als altem Bekannten in einer neuen Rolle.

(mro)