Gibt es einen Zusammenhang zwischen Codekomplexität und Entwicklerproduktivität?

10

Lohnt sich die Zeit für die Überarbeitung einer Codebasis auf lange Sicht im Hinblick auf die Entwicklerproduktivität?

Mir scheint ziemlich klar zu sein, dass das Ändern eines sauberen, gut gestalteten Systems viel einfacher und schneller ist als das Arbeiten an einem schlecht gestalteten System, aber ich bin auf der Suche nach soliden Beweisen. Gibt es Studien zu diesem Thema?

productivity complexity

— Benny Hallett
quelle

Siehe Wiederaufbau

— hakre

1

Fangen Sie an, selbst ein Chaos aufrechtzuerhalten, und seien Sie der Richter.

— Tulains Córdova

16

Empirisch ist es schwieriger, Software mit Metriken mit höherer Komplexität, wie z. B. zyklomatischer Komplexität, zu warten. Es gibt Forschungen, die dies aus den 1970er Jahren belegen ("Program Complexity and Programmer Productivity", ET Chen) . Es gibt auch Arbeiten, die darauf hinweisen , dass sich die Komplexitätsdichte, dh die zyklomatische Komplexität über die Größe des Systems, auch auf die Wartungszeit bezieht ("Zyklomatische Komplexitätsdichte und Produktivität der Softwarewartung", GK Gill, CF Kemerer) , die hier ebenfalls kostenlos verfügbar ist . Leider ist für Chens Artikel ein IEEE-Abonnement erforderlich, aber Sie können versuchen, es bei Interesse in anderen Quellen nachzuschlagen.

Unter Qualitätsgesichtspunkten lohnt es sich oft, einige Zeit mit dem Refactoring zu verbringen, vorausgesetzt, Sie verfügen über ein Test-Framework, um die Einführung neuer Fehler zu verhindern. Auf diese Weise können Sie neue Funktionen einfacher in Ihr System implementieren, zusätzliche Tests hinzufügen und neue Entwickler für die Arbeit schulen.

Letztendlich besteht jedoch der Druck, neue Funktionen und Mehrwert zu liefern. Sie müssen das Refactoring mit der Implementierung neuer Funktionen und der Reparatur von Fehlern in Einklang bringen.

— Thomas Owens
quelle

2

Ein weiterer Punkt, den Sie hinzufügen sollten, ist, dass Sie beim Refactor wahrscheinlich auch Funktionen besser / effizienter / sauberer implementieren. Es gibt ein Sprichwort, das ich unzählige Male gehört habe: "In 5 Jahren wirst du zusammenzucken, dass du denkst, dein Code sei 'gut'"

— warren

1

@hakre Ich habe dies überprüft, als ich dies und jetzt wieder gepostet habe, und zwar sowohl mit einer Google-Websuche als auch mit Google Scholar. Zu der Zeit, als ich diesen Beitrag ursprünglich schrieb, war kein Papier ohne Kauf verfügbar. Seitdem wurde jedoch ein Artikel auf einer Domain der Universität von Pittsburgh veröffentlicht, die anscheinend einem der Autoren gehört, und ich habe einen Link dazu hinzugefügt. Das andere Papier ist nicht kostenlos erhältlich. Ich habe die Titel zum Textkörper des Beitrags hinzugefügt, um die Suche nach ihnen etwas zu vereinfachen. Wenn Sie die Artikel nicht lesen möchten, müssen Sie meine Analyse zusammen mit meinem Wissen und meiner Erfahrung akzeptieren.

— Thomas Owens

0

Ich bin nach soliden Beweisen

Dann hör auf, deine Zeit hier zu verschwenden.

Finden Sie einen Code, dessen Wartung teuer ist. Es ist einfach. Sehen Sie sich die Trouble Tickets Ihrer Organisation an.
Finden Sie einen Code, der billig zu warten ist. Suchen Sie nach Code, der häufig ausgeführt wird, aber nur wenige oder keine Trouble-Tickets enthält.
Messen Sie die Komplexität mit einem der weit verbreiteten Komplexitätswerkzeuge.
Genießen Sie die Beweise.

Sie haben jetzt Nummern angegeben, um das Offensichtliche zu bestätigen.

— S.Lott
quelle

5

Nicht wirklich. Die Komplexität der von der Software ausgeführten Aufgabe muss von der zusätzlichen Komplexität unterschieden werden, die durch die gewählte Implementierung verursacht wird.

— Reinierpost

4

-1 keine Antwort

— Dave Hillier