it-swarm.com.de

Ich habe 200.000 Zeilen Spaghetti-Code geerbt - was jetzt?

Ich hoffe, das ist keine allzu allgemeine Frage. Ich könnte wirklich einige erfahrene Ratschläge gebrauchen.

Ich bin neu als einziger "SW-Ingenieur" in einem relativ kleinen Geschäft von Wissenschaftlern angestellt, die in den letzten 10 bis 20 Jahren eine riesige Codebasis zusammengeschustert haben. (Es wurde in einer praktisch veralteten Sprache geschrieben: G2 - denke Pascal mit Grafiken). Das Programm selbst ist ein physikalisches Modell einer komplexen chemischen Verarbeitungsanlage. Das Team, das es geschrieben hat, verfügt über unglaublich tiefes Fachwissen, aber wenig oder keine formale Ausbildung in Programmiergrundlagen. Sie haben kürzlich einige schwierige Lektionen über die Konsequenzen eines nicht vorhandenen Konfigurationsmanagements gelernt. Ihre Wartungsbemühungen werden auch durch die enorme Anhäufung von undokumentiertem "Schlamm" im Code selbst stark behindert. Ich werde Ihnen die "Politik" der Situation ersparen (es gibt immer Politik!), Aber es reicht zu sagen, es gibt keinen Konsens darüber, worüber wird für den Weg vor uns benötigt.

Sie haben mich gebeten, dem Team einige der Prinzipien der modernen Softwareentwicklung vorzustellen. Sie möchten, dass ich einige der branchenüblichen Praktiken und Strategien in Bezug auf Codierungskonventionen, Lebenszyklusmanagement, Entwurfsmuster auf hoher Ebene und Quellcodeverwaltung vorstelle. Ehrlich gesagt ist es eine ziemlich entmutigende Aufgabe und ich bin mir nicht sicher, wo ich anfangen soll.

Anfangs neige ich dazu, sie in einigen der zentralen Konzepte von The Pragmatic Programmer oder Fowler's = zu unterrichten Refactoring ("Code Smells" usw.). Ich hoffe auch, eine Reihe von agilen Methoden vorstellen zu können. Aber letztendlich, um effektiv zu sein, denke ich, dass ich mich auf 5-7 Kerngrundlagen konzentrieren muss; Mit anderen Worten, was sind die wichtigsten Prinzipien oder Praktiken, mit deren Umsetzung sie realistisch beginnen können, um das beste Preis-Leistungs-Verhältnis zu erzielen?.

Das ist also meine Frage: Was würden Sie in Ihre Liste der effektivsten Strategien aufnehmen, um die Spaghetti zu glätten (und in Zukunft zu verhindern)?

468
kmote

Vorwort

Dies ist in der Tat eine entmutigende Aufgabe, und es gibt viel zu tun. Ich schlage dies demütig als etwas umfassenden Leitfaden für Ihr Team vor, mit Hinweisen auf geeignete Tools und Lehrmaterialien.

Denken Sie daran: Dies sind Richtlinien , die als solche je nach den Umständen übernommen, angepasst oder gelöscht werden sollen .

Vorsicht: Das alles auf einmal in ein Team zu werfen, würde höchstwahrscheinlich scheitern. Sie sollten versuchen, Elemente auszuwählen, die Ihnen den besten Schweiß geben, und sie langsam nacheinander einführen.

Hinweis: Nicht alles gilt direkt für visuelle Programmiersysteme wie G2. Weitere Einzelheiten zum Umgang damit finden Sie im Abschnitt Addendum am Ende.


Zusammenfassung für den Ungeduldigen

  • Definieren Sie eine starre Projektstruktur mit:
    • Projektvorlagen ,
    • Codierungskonventionen ,
    • vertraute Build-Systeme ,
    • und Sätze von Verwendungsrichtlinien für Ihre Infrastruktur und Tools.
  • Installieren Sie ein gutes [~ # ~] scm [~ # ~] und stellen Sie sicher, dass sie wissen, wie man es verwendet.
  • Zeigen Sie sie für ihre Technologie auf good IDEs und stellen Sie sicher, dass sie wissen, wie sie verwendet werden.
  • Implementieren Sie Codequalitätsprüfer und automatische Berichterstellung im Build-System.
  • Koppeln Sie das Build-System mit Continuous Integration und Continuous Inspection Systemen.
  • Identifizieren Sie mit Hilfe der obigen Informationen Codequalität "Hotspots" und Refactor .

Nun zur langen Version ... Achtung, macht euch bereit !


Die Starrheit ist (oft) gut

Dies ist eine kontroverse Meinung, da Starrheit oft als eine Kraft gesehen wird, die gegen Sie arbeitet. Dies gilt für einige Phasen einiger Projekte. Wenn Sie es jedoch als strukturelle Unterstützung betrachten, als Rahmen, der das Rätselraten beseitigt, wird die Zeit- und Arbeitsverschwendung erheblich reduziert. Lass es für dich funktionieren, nicht gegen dich.

Starrheit = Prozess/ Verfahren.

Die Softwareentwicklung erfordert gute Prozesse und Verfahren aus genau den gleichen Gründen, aus denen Chemiefabriken oder Fabriken Handbücher, Verfahren, Bohrer und Notfallrichtlinien haben: Verhinderung schlechter Ergebnisse, Erhöhung der Vorhersehbarkeit, Maximierung der Produktivität ...

Starrheit kommt jedoch in Maßen!

Starrheit der Projektstruktur

Wenn jedes Projekt eine eigene Struktur hat, sind Sie (und Neulinge) verloren und müssen jedes Mal, wenn Sie sie öffnen, von Grund auf neu lernen. Sie möchten dies nicht in einem professionellen Software-Shop, und Sie möchten dies auch nicht in einem Labor.

Starrheit der Build-Systeme

Wenn jedes Projekt sieht anders aus, besteht eine gute Chance, dass sie auch anders bauen . Ein Build sollte nicht zu viel Recherche oder zu viel Rätselraten erfordern. Sie möchten in der Lage sein, das Kanonische zu tun, und müssen sich nicht um Einzelheiten kümmern: configure; make install, ant, mvn install, usw...

Die Wiederverwendung des gleichen Build-Systems und dessen Weiterentwicklung im Laufe der Zeit gewährleistet auch ein gleichbleibendes Qualitätsniveau.

Sie benötigen ein kurzes README, um auf die Besonderheiten des Projekts hinzuweisen und den Benutzer/Entwickler/Forscher, falls vorhanden, ordnungsgemäß zu führen.

Dies erleichtert auch andere Teile Ihrer Build-Infrastruktur erheblich, nämlich:

Halten Sie Ihren Build (wie Ihre Projekte) auf dem neuesten Stand, aber machen Sie ihn im Laufe der Zeit strenger und effizienter bei der Meldung von Verstößen und schlechten Praktiken.

Erfinden Sie das Rad nicht neu und verwenden Sie das, was Sie bereits getan haben.

Empfohlene Lektüre:

Starrheit bei der Wahl der Programmiersprachen

Insbesondere in einer Forschungsumgebung kann nicht erwartet werden, dass alle Teams (und noch weniger alle Entwickler) denselben Sprach- und Technologie-Stack verwenden. Sie können jedoch eine Reihe von "offiziell unterstützten" Tools identifizieren und deren Verwendung fördern. Der Rest sollte ohne eine gute Begründung nicht erlaubt sein (über das Prototyping hinaus).

Halten Sie Ihren Tech-Stack einfach und die Wartung und Breite der erforderlichen Fähigkeiten auf ein Minimum: einen starken Kern.

Starrheit der Kodierungskonventionen und -richtlinien

Codierungskonventionen und -richtlinien ermöglichen es Ihnen, sowohl eine Identität als Team als auch einen gemeinsamen Jargon zu entwickeln. Sie möchten nicht jedes Mal, wenn Sie eine Quelldatei öffnen, in terra incognita Irren.

Unsinnige Regeln, die das Leben erschweren oder explizite Handlungen verbieten, in dem Maße, in dem Commits aufgrund einzelner einfacher Verstöße abgelehnt werden, sind eine Belastung. Jedoch:

  • ein gut durchdachter Grundregelsatz nimmt viel Jammern und Denken weg: Nobody sollte unter keinen Umständen brechen;

  • und eine Reihe empfohlener Regeln bieten zusätzliche Anleitungen.

Persönlicher Ansatz: Ich bin aggressiv, wenn es um Codierungskonventionen geht, manche sagen sogar nazi, weil ich an ein glaube. lingua franca, ein erkennbarer Stil für mein Team. Wenn Mistcode eingecheckt wird, fällt er wie ein Fieberbläschen im Gesicht eines Hollywoodstars auf: Er löst automatisch eine Überprüfung und eine Aktion aus. Tatsächlich bin ich manchmal so weit gegangen, die Verwendung von Pre-Commit-Hooks zu befürworten, um nicht konforme Commits abzulehnen. Wie bereits erwähnt, sollte es nicht übermäßig verrückt sein und die Produktivität beeinträchtigen: Es sollte es vorantreiben. Führen Sie diese langsam ein, besonders am Anfang. Aber es ist viel besser, so viel Zeit damit zu verbringen, fehlerhaften Code zu reparieren, dass Sie nicht an echten Problemen arbeiten können.

Einige Sprachen erzwingen dies sogar mit Absicht:

  • Java sollte die Menge an langweiligem Mist reduzieren, den man damit schreiben kann (obwohl es zweifellos viele schaffen, dies zu tun).
  • Pythons Blockstruktur durch Einrücken ist eine weitere Idee in diesem Sinne.

  • Gehen Sie mit seinem Tool gofmt, das jegliche Debatte und Mühe ( und Ego !! ), die dem Stil innewohnt, vollständig wegnimmt: Führen Sie gofmt vorher aus Sie verpflichten sich.

Stellen Sie sicher, dass Code rot nicht durchrutschen kann. Code-Konventionen , kontinuierliche Integration und kontinuierliche Inspektion , Paarprogrammierung und Code Reviews sind dein Arsenal gegen diesen Dämon.

Wie Sie unten sehen werden, ist Code ist Dokumentation , und dies ist ein weiterer Bereich, in dem Konventionen die Lesbarkeit und Klarheit fördern.

Starrheit der Dokumentation

Die Dokumentation geht Hand in Hand mit dem Code. Code selbst ist Dokumentation. Es muss jedoch klare Anweisungen zum Erstellen, Verwenden und Warten von Dingen geben.

Die Verwendung eines einzigen Kontrollpunkts für die Dokumentation (wie ein WikiWiki oder DMS) ist eine gute Sache. Erstellen Sie Räume für Projekte, Räume für mehr zufällige Scherze und Experimente. Lassen Sie alle Räume gemeinsame Regeln und Konventionen wiederverwenden. Versuchen Sie, es Teil des Teamgeistes zu machen.

Die meisten Ratschläge zu Code und Werkzeugen gelten auch für die Dokumentation.

Starrheit in Codekommentaren

Codekommentare sind, wie oben erwähnt, ebenfalls Dokumentation. Entwickler drücken gerne ihre Gefühle bezüglich ihres Codes aus (meistens Stolz und Frustration, wenn Sie mich fragen). Daher ist es nicht ungewöhnlich, dass sie diese in Kommentaren (oder sogar im Code) ohne Zweifel ausdrücken, wenn ein formellerer Text die gleiche Bedeutung mit weniger Expletiven oder Dramen hätte vermitteln können. Es ist in Ordnung, ein paar aus Spaß und historischen Gründen durchzulassen: Es ist auch Teil von Entwicklung einer Teamkultur . Aber es ist sehr wichtig, dass jeder weiß, was akzeptabel ist und was nicht, und dieses Kommentarrauschen ist genau das: Rauschen .

Starrheit in Festschreibungsprotokollen

Commit-Protokolle sind kein lästiger und nutzloser "Schritt" im Lebenszyklus Ihres SCM: Sie überspringen sie NICHT, um pünktlich nach Hause zu kommen oder mit der nächsten Aufgabe fortzufahren oder um die Freunde zu treffen, die zum Mittagessen abgereist sind. Sie sind wichtig, und wie (die meisten) guten Weine werden sie umso wertvoller, je mehr Zeit vergeht. Also mach sie richtig. Ich bin verblüfft, wenn ich sehe, wie Mitarbeiter Einzeiler für riesige Commits oder für nicht offensichtliche Hacks schreiben.

Commits werden aus einem bestimmten Grund ausgeführt, und dieser Grund wird nicht immer klar durch Ihren Code und die von Ihnen eingegebene Zeile des Commit-Protokolls ausgedrückt. Es steckt mehr dahinter.

Jede Codezeile hat eine Geschichte und eine Geschichte. Die Diffs können ihre Geschichte erzählen, aber Sie müssen ihre Geschichte schreiben.

Warum habe ich diese Zeile aktualisiert? -> Weil sich die Schnittstelle geändert hat.

Warum hat sich die Benutzeroberfläche geändert? -> Weil die Bibliothek L1, die sie definiert, aktualisiert wurde.

Warum wurde die Bibliothek aktualisiert? -> Da die Bibliothek L2, die wir für Merkmal F benötigen, von der Bibliothek L1 abhängt.

Und was ist Feature X? -> Siehe Aufgabe 3456 im Issue Tracker.

Es ist nicht meine SCM-Wahl und möglicherweise auch nicht die beste für Ihr Labor. Aber Git macht das richtig und versucht, Sie zu zwingen, mehr gute Protokolle als die meisten anderen SCM-Systeme zu schreiben, indem Sie short logs und long logs. Verknüpfen Sie die Aufgaben-ID (ja, Sie benötigen eine) und hinterlassen Sie eine allgemeine Zusammenfassung für shortlog und erweitern Sie sie im langen Protokoll: Schreiben Sie die story des Änderungssatzes.

Es ist ein Protokoll: Es ist hier, um Aktualisierungen zu verfolgen und aufzuzeichnen.

Faustregel: Wenn Sie später nach etwas über diese Änderung suchen, wird Ihr Protokoll wahrscheinlich Ihre Frage beantworten?

Projekte, Dokumentation und Code LEBEN

Halten Sie sie synchron, sonst bilden sie keine symbiotische Einheit mehr. Es wirkt Wunder, wenn Sie:

  • löschen Sie Commit-Protokolle in Ihrem SCM mit Links zu Aufgaben-IDs in Ihrem Issue-Tracker.
  • wo die Tickets dieses Trackers selbst mit den Änderungssätzen in Ihrem SCM (und möglicherweise mit den Builds in Ihrem CI-System) verknüpft sind,
  • und ein Dokumentationssystem, das mit all diesen verknüpft ist.

Code und Dokumentation müssen zusammenhängend sein .

Starrheit beim Testen

Faustregeln:

  • Jeder neue Code muss (mindestens) Unit-Tests enthalten.
  • Jeder überarbeitete Legacy-Code muss mit Unit-Tests geliefert werden.

Natürlich brauchen diese:

  • um tatsächlich etwas Wertvolles zu testen (oder sie sind Zeit- und Energieverschwendung),
  • gut geschrieben und kommentiert zu sein (genau wie jeder andere Code, den Sie einchecken).

Sie sind ebenfalls Dokumentationen und helfen dabei, den Vertrag Ihres Codes zu skizzieren. Besonders wenn Sie TDD verwenden. Selbst wenn Sie dies nicht tun, brauchen Sie sie für Ihren Seelenfrieden. Sie sind Ihr Sicherheitsnetz, wenn Sie neuen Code (Wartung oder Funktion) und Ihren Wachturm einbauen, um sich vor Codefäule und Umweltfehlern zu schützen.

Natürlich sollten Sie weiter gehen und Integrationstests und Regressionstests für jeden reproduzierbaren Fehler haben, den Sie beheben.

Starrheit bei der Verwendung der Werkzeuge

Für gelegentliche Entwickler/Wissenschaftler ist es in Ordnung, einen neuen statischen Prüfer für die Quelle auszuprobieren, ein Diagramm oder Modell mit einem anderen zu generieren oder ein neues Modul mit DSL zu implementieren. Aber es ist am besten, wenn es eine kanonische Reihe von Tools gibt, die all Teammitglieder kennen und verwenden sollen.

Lassen Sie die Mitglieder darüber hinaus verwenden, was sie wollen, solange sie ALLE sind:

  • produktiv ,
  • benötigt NICHT regelmäßig Unterstützung
  • NICHT regelmäßig an Ihre allgemeine Infrastruktur anpassen ,
  • Ihre Infrastruktur NICHT stören (durch Ändern von allgemeinen Bereichen wie Code, Build-System, Dokumentation ...),
  • wirkt sich NICHT auf die Arbeit anderer aus ,
  • FÄHIG, um jede angeforderte Aufgabe rechtzeitig auszuführen .

Wenn dies nicht der Fall ist, erzwingen Sie, dass sie auf die Standardeinstellungen zurückgreifen.


Starrheit gegen Vielseitigkeit, Anpassungsfähigkeit, Prototyping und Notfälle

Flexibilität kann gut sein. Es ist in Ordnung, jemanden gelegentlich einen Hack, einen Quick-n-Dirty-Ansatz oder ein bevorzugtes Haustier-Tool verwenden zu lassen, um den Job zu erledigen . [~ # ~] nie [~ # ~] lass es zur Gewohnheit werden, und [~ # ~] nie [~ # ~] Lassen Sie diesen Code zur eigentlichen zu unterstützenden Codebasis werden.


Teamgeist ist wichtig

Entwickeln Sie ein Gefühl des Stolzes auf Ihre Codebasis

  • Entwickeln Sie ein Gefühl des Stolzes auf Code
    • Wandtafeln verwenden
      • rangliste für ein kontinuierliches Integrationsspiel
      • wallboards für Issue Management und Fehlerzählung
    • Verwenden Sie einen Issue-Tracker / Bug-Tracker

Vermeiden Sie Schuldzuweisungen

  • Verwenden Sie Continuous Integration/Continuous Inspection-Spiele: Sie fördern gutmütige und produktive Konkurrenz .
  • Behalten Sie Mängel im Auge: Es ist einfach eine gute Haushaltsführung.
  • DO Ursachen identifizieren : Es sind nur zukunftssichere Prozesse.
  • ABER NICHT Schuldzuweisung : Es ist kontraproduktiv.

Es geht um den Code, nicht um die Entwickler

Machen Sie Entwickler auf die Qualität ihres Codes aufmerksam, ABER lassen Sie sie den Code als eigenständige Einheit und nicht als Erweiterung ihrer selbst sehen, was nicht kritisiert werden kann.

Es ist ein Paradoxon: Sie müssen Programmierung ohne Ego für einen gesunden Arbeitsplatz fördern, sich aber aus Motivationsgründen auf das Ego verlassen.


Vom Wissenschaftler zum Programmierer

Menschen, die keinen Wert auf Code legen und stolz darauf sind, produzieren keinen guten Code. Damit diese Immobilie entstehen kann, müssen sie herausfinden, wie wertvoll und unterhaltsam sie sein kann. Bloße Professionalität und der Wunsch, Gutes zu tun, reichen nicht aus: Es braucht Leidenschaft. Sie müssen Ihre Wissenschaftler also in Programmierer (im großen Sinne) verwandeln.

Jemand argumentierte in Kommentaren, dass nach 10 bis 20 Jahren an einem Projekt und seinem Code jeder sich verbunden fühlen würde. Vielleicht irre ich mich, aber ich gehe davon aus, dass sie stolz auf die Ergebnisse des Codes und auf die Arbeit und sein Erbe sind, nicht auf den Code selbst oder auf das Schreiben.

Aus Erfahrung betrachten die meisten Forscher das Codieren als eine Notwendigkeit oder bestenfalls als eine lustige Ablenkung. Sie wollen nur, dass es funktioniert. Diejenigen, die sich bereits gut damit auskennen und Interesse an Programmierung haben, sind viel einfacher davon zu überzeugen, Best Practices und Switching-Technologien zu übernehmen. Sie müssen sie auf halbem Weg dorthin bringen.


Die Codepflege ist Teil der Forschungsarbeit

Niemand liest beschissene Forschungsarbeiten. Aus diesem Grund werden sie immer wieder von Fachleuten begutachtet, Korrektur gelesen, verfeinert, umgeschrieben und genehmigt, bis sie zur Veröffentlichung bereit sind. Gleiches gilt für eine These und eine Codebasis!

Machen Sie deutlich, dass das ständige Umgestalten und Aktualisieren einer Codebasis Codefäule verhindert, die technische Verschuldung verringert und die zukünftige Wiederverwendung und Anpassung der Arbeit für andere Projekte erleichtert.


Warum das alles??!

Warum beschäftigen wir uns mit all dem oben genannten? Für Codequalität . Oder ist es Qualitätscode ...?

Diese Richtlinien zielen darauf ab, Ihr Team auf dieses Ziel hinzuarbeiten. Einige Aspekte tun dies, indem sie ihnen einfach den Weg zeigen und sie es tun lassen (was viel besser ist), andere nehmen sie bei der Hand (aber so erziehen Sie Menschen und entwickeln Gewohnheiten).

Woher wissen Sie, wann das Ziel in Reichweite ist?

Qualität ist messbar

Nicht immer quantitativ, aber es ist messbar . Wie bereits erwähnt, müssen Sie ein Gefühl des Stolzes in Ihrem Team entwickeln, und es ist entscheidend, Fortschritte und gute Ergebnisse zu zeigen. Messen Sie die Codequalität regelmäßig und zeigen Sie den Fortschritt zwischen den Intervallen und wie es darauf ankommt. Machen Sie Rückblicke, um darüber nachzudenken, was getan wurde und wie es die Dinge besser oder schlechter gemacht hat.

Es gibt großartige Tools für kontinuierliche Inspektion . Sonar ist ein beliebtes Produkt in der Java Welt, aber es kann sich an alle Technologien anpassen, und es gibt viele andere. Behalten Sie Ihren Code unter dem Mikroskop und suchen Sie nach diesen lästige nervige Käfer und Mikroben.


Aber was ist, wenn mein Code schon Mist ist?

All das ist lustig und niedlich wie eine Reise nach Never Land, aber es ist nicht so einfach, wenn Sie bereits (einen Haufen dampfenden und stinkenden) Mistcodes haben und ein Team sich nur ungern ändert.

Hier ist das Geheimnis: du musst irgendwo anfangen .

Persönliche Anekdote: In einem Projekt haben wir mit einer Codebasis gearbeitet, die ursprünglich 650.000+ Java LOC, mehr als 200.000 Zeilen JSPs, mehr als 40.000 JavaScript LOC) wog und mehr als 400 MB binäre Abhängigkeiten.

Nach ungefähr 18 Monaten sind es 500.000 Java LOC (MOSTLY CLEAN) , 150.000 Zeilen JSPs und 38.000 JavaScript LOC mit Abhängigkeiten von bis zu knapp 100 MB (und diese sind nicht mehr in unserem SCM!).

Wie haben wir das gemacht? Wir haben gerade alles oben Genannte gemacht. Oder hart versucht.

Es ist eine Teamleistung, aber wir injizieren in unseren Prozessvorschriften und Tools, um die Herzfrequenz unseres Produkts zu überwachen, während wir hastig Slashing das "Fett" weg: Mistcode, nutzlose Abhängigkeiten ... Wir haben nicht jede Entwicklung gestoppt, um dies zu tun: Wir haben gelegentlich Perioden relativer Ruhe, in denen wir frei sind, verrückt nach der Codebasis zu werden und sie auseinander zu reißen Aber die meiste Zeit tun wir alles, indem wir bei jeder Gelegenheit standardmäßig einen "Überprüfungs- und Refaktor" -Modus verwenden: während der Builds, während des Mittagessens, während Sprints zur Fehlerbehebung, während der Freitagnachmittage ...

Es gab einige große "Arbeiten" ... Die Umstellung unseres Build-Systems von einem riesigen Ant-Build mit mehr als 8500 XML LOC auf einen Maven-Build mit mehreren Modulen war eine davon. Wir hatten dann:

  • eindeutige Module (oder zumindest war es schon viel besser und wir haben noch große Pläne für die Zukunft),
  • automatisches Abhängigkeitsmanagement (zur einfachen Wartung und Aktualisierung sowie zum Entfernen nutzloser Abhängigkeiten),
  • schnellere, einfachere und reproduzierbare Builds,
  • tägliche Qualitätsberichte.

Ein weiteres Problem war die Einführung von "Utility Tool-Belt", obwohl wir versucht haben, Abhängigkeiten zu reduzieren: Google Guava und Apache Commons verkleinern Ihren Code und reduzieren die Oberfläche für Fehler in your viel Code.

Wir haben auch unsere IT-Abteilung davon überzeugt, dass die Verwendung unserer neuen Tools (JIRA, Fisheye, Crucible, Confluence, Jenkins) möglicherweise besser ist als die vorhandenen. Wir mussten uns noch mit einigen verachten, die wir verachteten (QC, Sharepoint und SupportWorks ...), aber es war eine insgesamt verbesserte Erfahrung, mit etwas mehr Platz.

Und jeden Tag gibt es zwischen einem und Dutzenden von Commits, die sich nur mit dem Reparieren und Umgestalten von Dingen befassen. Wir brechen gelegentlich Dinge ab (Sie benötigen Komponententests, und Sie schreiben sie besser vor Sie überarbeiten Dinge weg), aber insgesamt war der Nutzen für unsere Moral UND für das Produkt enorm. Wir erhalten jeweils einen Bruchteil eines Prozentsatzes der Codequalität. Und es macht Spaß zu sehen, wie es zunimmt !!!

Hinweis: Auch hier muss die Starrheit erschüttert werden, um Platz für neue und bessere Dinge zu schaffen. In meiner Anekdote ist unsere IT-Abteilung teilweise richtig darin, uns some Dinge aufzuzwingen, und falsch für andere. Oder vielleicht haben sie war früher richtig . Dinge ändern sich. Beweisen Sie, dass dies bessere Möglichkeiten sind, um Ihre Produktivität zu steigern. Probeläufe und Prototypen sind dafür hier.


Der supergeheime inkrementelle Spaghetti-Code-Refactoring-Zyklus für hervorragende Qualität

       +-----------------+      +-----------------+
       |  A N A L Y Z E  +----->| I D E N T I F Y |
       +-----------------+      +---------+-------+
                ^                           |
                |                           v
       +--------+--------+      +-----------------+
       |    C L E A N    +<-----|      F I X      |
       +-----------------+      +-----------------+

Sobald Sie einige Qualitätswerkzeuge an Ihrem Werkzeuggürtel haben:

  1. Analyse Ihr Code mit Codequalitätsprüfern.

    Linters, statische Analysatoren oder was haben Sie.

  2. Identifizieren Ihre kritische Hotspots UND niedrig hängende Früchte .

    Verstöße haben Schweregrade, und große Klassen mit einer großen Anzahl von Schweregraden sind eine große rote Fahne: Als solche erscheinen sie als "Hot Spots" in Ansichten von Heizkörper-/Heatmap-Ansichten.

  3. Fix die Hotspots zuerst.

    Es maximiert Ihre Wirkung in kurzer Zeit, da sie den höchsten Geschäftswert haben. Im Idealfall sollten kritische Verstöße behandelt werden, sobald sie auftreten, da es sich um potenzielle Sicherheitslücken oder Absturzursachen handelt und ein hohes Risiko besteht, eine Haftung zu begründen (und in Ihrem Fall eine schlechte Leistung für das Labor).

  4. Clean die Verstöße auf niedriger Ebene mit automatisierten Codebasis-Sweeps .

    Es verbessert das Signal-Rausch-Verhältnis , sodass Sie signifikante Verstöße auf Ihrem Radar sehen können, sobald sie auftreten. Es gibt oft eine große Armee kleinerer Verstöße, wenn sie nie behoben wurden und Ihre Codebasis in freier Wildbahn frei gelassen wurde. Sie stellen kein echtes "Risiko" dar, beeinträchtigen jedoch die Lesbarkeit und Wartbarkeit des Codes. Beheben Sie sie entweder, wenn Sie sie bei der Arbeit an einer Aufgabe treffen, oder wenn möglich durch große Reinigungsquests mit automatisierten Code-Sweeps. Seien Sie vorsichtig mit großen Auto-Sweeps, wenn Sie keine gute Testsuite und kein gutes Integrationssystem haben. Stellen Sie sicher, dass Sie mit den Mitarbeitern den richtigen Zeitpunkt für die Ausführung vereinbaren, um den Ärger zu minimieren.

  5. Wiederhole bis du zufrieden bist.

    Was Sie im Idealfall niemals sein sollten, wenn dies noch ein aktives Produkt ist: Es wird sich weiterentwickeln.

Schnelle Tipps für eine gute Haushaltsführung

  • Im Hotfix-Modus , basierend auf einer Kundensupportanfrage:

    • Es ist normalerweise eine bewährte Methode, [~ # ~] nicht [~ # ~] andere Probleme zu beheben, da Sie möglicherweise unfreiwillig neue Probleme einführen.
    • Gehen Sie los SEAL-Stil: Steigen Sie ein, töten Sie den Fehler, steigen Sie aus und versenden Sie Ihren Patch. Es ist ein chirurgischer und taktischer Schlag.
  • Aber für alle anderen Fälle , wenn Sie eine Datei öffnen, machen Sie es sich zur Pflicht:

    • definitiv : review it (Notizen machen, Berichte über Dateiprobleme),
    • vielleicht : clean it (Stilbereinigungen und kleinere Verstöße),
    • idealerweise : refactor it (große Abschnitte und ihre Nachbarn neu organisieren).

Lassen Sie sich nur nicht davon ablenken, eine Woche von Datei zu Datei zu verbringen, und es kommt zu einem massiven Änderungssatz von Tausenden von Korrekturen, die mehrere Funktionen und Module umfassen - dies erschwert die zukünftige Nachverfolgung. Ein Problem im Code = ein Ticket in Ihrem Tracker. Manchmal kann ein Änderungssatz mehrere Tickets betreffen. Aber wenn es zu oft passiert, machen Sie wahrscheinlich etwas falsch.


Nachtrag: Verwalten von visuellen Programmierumgebungen

Die ummauerten Gärten maßgeschneiderter Programmiersysteme

Mehrere Programmiersysteme, wie das G2 des OP, sind verschiedene Bestien ...

  • Kein Quellcode "

    Oft bieten sie Ihnen keinen Zugriff auf eine Textdarstellung Ihres Quell- "Codes": Er wird möglicherweise in einem proprietären Binärformat gespeichert, oder er speichert Dinge im Textformat, verbirgt sie jedoch vor Ihnen. Maßgeschneiderte grafische Programmiersysteme sind in Forschungslabors keine Seltenheit, da sie die Automatisierung sich wiederholender Datenverarbeitungs-Workflows vereinfachen.

  • No Tooling

    Abgesehen von ihren eigenen. Sie sind häufig durch ihre Programmierumgebung, ihren eigenen Debugger, ihren eigenen Interpreter, ihre eigenen Dokumentationswerkzeuge und -formate eingeschränkt. Sie sind ummauerte Gärten , außer wenn sie irgendwann das Interesse von jemandem wecken, der motiviert genug ist, ihre Formate zurückzuentwickeln und externe Tools zu erstellen - sofern die Lizenz dies zulässt.

  • Fehlende Dokumentation

    Sehr oft sind dies Nischenprogrammiersysteme, die in ziemlich geschlossenen Umgebungen verwendet werden. Menschen, die sie verwenden, unterschreiben häufig NDAs und sprechen nie darüber, was sie tun. Programmiergemeinschaften für sie sind selten. Die Ressourcen sind also knapp. Sie bleiben bei Ihrer offiziellen Referenz, und das war's.

Das Ironische (und oft Frustrierende) ist, dass all die Dinge, die diese Systeme tun, offensichtlich durch die Verwendung von Mainstream- und Allzweck-Programmiersprachen erreicht werden können und höchstwahrscheinlich effizienter. Es erfordert jedoch tiefere Programmierkenntnisse, während Sie nicht erwarten können, dass Ihr Biologe, Chemiker oder Physiker (um nur einige zu nennen) genug über Programmierung weiß und noch weniger Zeit (und Wunsch) hat, um sie zu implementieren (und zu warten). komplexe Systeme, die langlebig sein können oder nicht. Aus dem gleichen Grund, aus dem wir DSLs verwenden, verfügen wir über diese maßgeschneiderten Programmiersysteme.

Persönliche Anekdote 2: Eigentlich habe ich selbst an einer davon gearbeitet. Ich habe die Verknüpfung nicht mit der Anfrage des OP hergestellt, aber mein Projekt bestand aus einer Reihe miteinander verbundener großer Datenverarbeitungs- und Datenspeichersoftware (hauptsächlich für die Forschung in den Bereichen Bioinformatik, Gesundheitswesen und Kosmetik, aber auch für Unternehmen) Intelligenz oder eine Domäne, die die Verfolgung großer Mengen von Forschungsdaten jeglicher Art und die Vorbereitung von Datenverarbeitungs-Workflows und ETLs impliziert). Eine dieser Anwendungen war ganz einfach eine visuelle IDE, die die üblichen Schnickschnack verwendete: Drag & Drop-Schnittstellen, versionierte Projektarbeitsbereiche (unter Verwendung von Text- und XML-Dateien für die Metadatenspeicherung), viele Steckbare Treiber für heterogene Datenquellen und eine visuelle Leinwand zum Entwerfen von Pipelines zur Verarbeitung von Daten aus N Datenquellen und zur Erzeugung von M-transformierten Ausgaben sowie möglichen glänzenden Visualisierungen und komplexen (und interaktiven) Online-Berichten. Ihr typisches maßgeschneidertes visuelles Programmiersystem leidet darunter ein bisschen NIH-Syndrom unter dem Vorwand, ein System zu entwerfen, das an die Bedürfnisse der Benutzer angepasst ist.

Und wie zu erwarten ist, handelt es sich um ein Nice-System, das für seine Anforderungen recht flexibel ist, manchmal jedoch etwas übertrieben, sodass Sie sich fragen, warum Sie nicht stattdessen Befehlszeilentools verwenden sollten, und das leider immer mittelgroß ist Teams, die an großen Projekten arbeiten, für viele verschiedene Personen, die sie mit unterschiedlichen "Best Practices" verwenden.

Großartig, wir sind zum Scheitern verurteilt! - Was tun wir dagegen?

Nun, am Ende gilt immer noch alles oben Genannte. Wenn Sie den größten Teil der Programmierung nicht aus diesem System extrahieren können, um mehr gängige Tools und Sprachen zu verwenden, müssen Sie sie "nur" an die Einschränkungen Ihres Systems anpassen.

Informationen zur Versionierung und Speicherung

Am Ende können Sie fast immer version Dinge, selbst in der am stärksten eingeschränkten und ummauerten Umgebung. Meistens verfügen diese Systeme immer noch über eine eigene Versionierung (die leider oft recht einfach ist und nur die Möglichkeit bietet, ohne große Sichtbarkeit zu früheren Versionen zurückzukehren und nur frühere Schnappschüsse zu behalten). Es werden nicht genau unterschiedliche Änderungssätze verwendet, wie dies bei einem SCM Ihrer Wahl der Fall sein könnte, und es ist wahrscheinlich nicht für mehrere Benutzer geeignet, die gleichzeitig Änderungen einreichen.

Wenn sie dennoch eine solche Funktionalität bieten, besteht Ihre Lösung möglicherweise darin, unsere oben genannten Richtlinien nach Industriestandard zu befolgen und sie auf dieses Programmiersystem zu übertragen !!

Wenn das Speichersystem eine Datenbank ist, stellt es wahrscheinlich Exportfunktionen bereit oder kann auf Dateisystemebene gesichert werden. Wenn ein benutzerdefiniertes Binärformat verwendet wird, können Sie möglicherweise einfach versuchen, es mit einem VCS zu versionieren, das Binärdaten gut unterstützt. Sie haben keine feinkörnige Kontrolle, aber zumindest haben Sie Ihren Rücken gegen Katastrophen geschützt und verfügen über ein gewisses Maß an Disaster Recovery-Konformität.

Über das Testen

Implementieren Sie Ihre Tests auf der Plattform selbst und verwenden Sie externe Tools und Hintergrundjobs, um regelmäßige Sicherungen einzurichten. Wahrscheinlich starten Sie diese Tests genauso wie die mit diesem Programmiersystem entwickelten Programme.

Sicher, es ist ein Hack-Job und entspricht definitiv nicht dem Standard, der für "normale" Programmierung üblich ist, aber die Idee ist, sich an das System anzupassen und gleichzeitig zu versuchen, einen Anschein eines professionellen Softwareentwicklungsprozesses aufrechtzuerhalten.

Die Straße ist lang und steil ...

Wie immer in Nischenumgebungen und maßgeschneiderten Programmiersystemen und wie oben beschrieben, haben Sie es mit seltsamen Formaten zu tun, nur mit einem begrenzten (oder völlig nicht vorhandenen) Satz möglicherweise klobiger Tools und einer Lücke anstelle einer Community.

Die Empfehlung: Versuchen Sie, die oben genannten Richtlinien so weit wie möglich außerhalb Ihres maßgeschneiderten Programmiersystems zu implementieren. Dies stellt sicher, dass Sie sich auf "allgemeine" Tools verlassen können, die über die richtige Unterstützung und Community-Unterstützung verfügen.

Die Problemumgehung: Wenn dies keine Option ist, versuchen Sie, dieses globale Framework in Ihre "Box" nachzurüsten. Die Idee ist, diesen Entwurf von Best Practices nach Industriestandard über Ihr Programmiersystem zu legen und das Beste daraus zu machen. Der Rat gilt weiterhin: Struktur und Best Practices definieren, Konformität fördern.

Leider bedeutet dies, dass Sie möglicherweise eintauchen und eine enorme Menge Beinarbeit leisten müssen. Damit...

Berühmte letzte Worte und bescheidene Anfragen:

  • Document alles was Sie tun.
  • Share Ihre Erfahrung.
  • Open Source jedes Tool, das Sie schreiben.

Wenn Sie dies alles tun, werden Sie:

  • erhöhen Sie nicht nur Ihre Chancen, Unterstützung von Menschen in ähnlichen Situationen zu erhalten.
  • bieten Sie aber auch anderen Menschen Hilfe und fördern Sie die Diskussion um Ihren Technologie-Stack.

Wer weiß, Sie könnten ganz am Anfang einer neuen lebendigen Community von Obscure Language X stehen. Wenn es keine gibt, starte eine!

  • Stellen Sie Fragen zu Stapelüberlauf ,
  • Vielleicht schreiben Sie sogar einen Vorschlag für eine neue StackExchange-Site in die Area 51 .

Vielleicht ist es innen wunderschön , aber niemand hat eine Ahnung bis jetzt, also hilf diese hässliche Mauer niederreißen und lassen Sie andere einen Blick darauf werfen!

464
haylem

Der allererste erste Schritt wäre die Einführung eines Versionskontrollsystems (SVN) , Git, Mercurial, TFS usw.). Dies ist ein Muss für ein Projekt mit Re-Factoring.

Bearbeiten: in Bezug auf VSC - Jedes Quellcodeverwaltungspaket kann Binärdateien verwalten, wenn auch mit einigen Einschränkungen. Die meisten Tools auf dem Markt können einen benutzerdefinierten Differenz-Viewer und -Editor verwenden. Verwenden Sie diese Funktion. Binäre Quelldateien sind keine Entschuldigung , die Versionskontrolle nicht zu verwenden.

Es gibt einen ähnlichen Beitrag zum Umgang mit Legacy-Code . Möglicherweise ist dies eine gute Referenz - Hinweise zur Arbeit mit Legacy-Code

101
Yusubov

Wenn ich mit Spaghetti-Code arbeiten muss, arbeite ich zuerst an Modularisierung . Suchen Sie Orte, an denen Sie Linien zeichnen und (mehr oder weniger) unabhängige Teile der Codebasis extrahieren können. Sie werden wahrscheinlich aufgrund eines hohen Maßes an Vernetzung und Kopplung nicht sehr klein sein, aber einige Modulleitungen entstehen, wenn Sie nach ihnen suchen.

Sobald Sie Module haben, stehen Sie nicht mehr vor der entmutigenden Aufgabe, ein ganzes chaotisches Programm zu bereinigen. Stattdessen müssen Sie jetzt mehrere kleinere, unabhängige, unordentliche Module bereinigen. Wählen Sie nun ein Modul aus und wiederholen Sie den Vorgang in kleinerem Maßstab. Suchen Sie nach Orten, an denen Sie große Funktionen in kleinere Funktionen oder sogar Klassen extrahieren können (sofern G2 diese unterstützt).

Dies ist alles viel einfacher, wenn die Sprache über ein ausreichend starkes Typsystem verfügt, da Sie den Compiler dazu bringen können, einen Großteil des schweren Hebens für Sie zu erledigen. Sie nehmen irgendwo eine Änderung vor, die (absichtlich) die Kompatibilität beeinträchtigt, und versuchen dann zu kompilieren. Die Kompilierungsfehler führen Sie direkt zu den Stellen, die geändert werden müssen, und wenn Sie sie nicht mehr erhalten, haben Sie alles gefunden. Führen Sie dann das Programm aus und testen Sie alles! Kontinuierliches Testen ist beim Refactoring von entscheidender Bedeutung.

43
Mason Wheeler

Ich weiß nicht, ob dies eine Option für Sie ist, aber ich würde versuchen, sie davon zu überzeugen, professionellere Entwickler einzustellen. Auf diese Weise könnten sie sich auf Domänenprobleme konzentrieren (ich bin sicher, dass sie dort genug haben).

Ich glaube, sie sind sehr kluge Leute, aber ein guter Entwickler zu werden, erfordert viel Zeit. Sind sie bereit, so viel Zeit in einer Aktivität zu verbringen, die nicht ihr Hauptgeschäft ist? Meiner Meinung nach ist dies nicht der Weg, um die besten Ergebnisse zu erzielen.

22
Gilney

Beeindruckend. Klingt so, als hätten Sie eine wirklich große Herausforderung vor sich! Ich würde etwas in die folgende Richtung tun:

  • Zuallererst: Priorisieren Sie . Was möchten Sie zuerst erreichen? Was ist für den aktuellen Stand des Projekts am wichtigsten? Was werden Sie am meisten davon bekommen und wie viel Zeit wird es dauern, um dorthin zu gelangen?.
  • Stellen Sie sicher, dass Sie über ein Versionskontrollsystem verfügen. Git oder Mercurial zum Beispiel.
  • Holen Sie sich eine Art System zur kontinuierlichen Integration (z. B. Jenkins ) zum Laufen.
  • Starten Sie ein Bug-Tracking-System . Mantis ist meiner Meinung nach ganz nett.
  • Schauen Sie in statische Code-Analyse (wenn etwas für die Sprache verfügbar ist, mit der Sie gerade arbeiten).
  • Versuchen Sie, so viel Konsistenz zu erreichen, von der Benennung von Variablen bis hin zu allgemeinen Codekonventionen und Richtlinien in der Codebasis.
  • Testen Sie das System . Dies ist meiner Meinung nach für ein großes Legacy-System wie dieses äußerst wichtig. Verwenden Sie Testfälle, um vorhandenes Verhalten zu dokumentieren , unabhängig davon, ob sich das Verhalten seltsam anfühlt oder nicht (normalerweise gibt es einen Grund, warum der Code ein bestimmtes Warum aussieht, könnte gut oder schlecht sein oder beides; P). Michael Feathers arbeitet effektiv mit Legacy-Code ist eine hervorragende Ressource dafür.
20

Sie sagen, dass der erste Schritt bei der Lösung eines Problems darin besteht, zuzugeben, dass Sie eines haben. Vor diesem Hintergrund können Sie zunächst ein Abhängigkeitsdiagramm erstellen, das das große Gewirr darstellt, das Ihre aktuelle Codebasis darstellt. Gutes Werkzeug zum Generieren eines Abhängigkeitsdiagramms? ist ein paar Jahre alt, enthält jedoch einige Hinweise auf Werkzeuge, die beim Erstellen solcher Diagramme helfen können. Ich würde mit einer großen, hässlichen Grafik gehen, die so viel wie möglich zeigt, um den Punkt nach Hause zu fahren. Sprechen Sie über Probleme, die sich aus zu vielen Abhängigkeiten ergeben, und werfen Sie vielleicht eine Zeile von Buckaroo Banzai :

Sie können Ihre Anatomie nach Belieben überprüfen, und obwohl es normale Abweichungen geben kann, sieht alles so gleich im Kopf gleich aus, wenn es darauf ankommt. Nein, nein, nein, zieh nicht daran. Sie wissen nie, woran es hängen könnte.

Stellen Sie von dort aus einen Plan vor, um das Chaos zu beseitigen. Teilen Sie den Code in Module auf, die so eigenständig wie möglich sind. Seien Sie offen für Vorschläge, wie das geht - die Leute, mit denen Sie sprechen, kennen den Verlauf und die Funktionalität des Codes besser als Sie. Das Ziel ist jedoch, ein großes Problem in eine Reihe kleinerer Probleme umzuwandeln, die Sie dann priorisieren und mit der Bereinigung beginnen können.

Einige Dinge, auf die Sie sich konzentrieren sollten:

  • Erstellen Sie saubere Schnittstellen zwischen Modulen und verwenden Sie diese. Der alte Code verwendet diese netten neuen Schnittstellen möglicherweise noch eine Weile nicht - das ist das Problem, das Sie zu lösen beginnen. Aber lassen Sie alle zustimmen, künftig nur die neuen Schnittstellen zu verwenden. Wenn sie etwas benötigen, das nicht in den Schnittstellen enthalten ist, reparieren Sie die Schnittstellen und gehen Sie nicht um sie herum.

  • Suchen Sie nach Fällen, in denen dieselbe Funktionalität wiederholt wurde. Arbeite auf die Vereinigung hin.

  • Erinnern Sie alle von Zeit zu Zeit daran, dass diese Änderungen das Leben erleichtern und nicht erschweren sollen. Der Übergang kann schmerzhaft sein, hat aber einen guten Zweck. Je mehr alle an Bord sind, desto schneller werden die Vorteile.

10
Caleb

Nach einem kurzen Blick auf Gensym G2 sieht es so aus, als ob die Art und Weise, wie dieses Problem angegangen wird, stark davon abhängt, wie viel von der Codebasis so aussieht:

enter image description here

oder dieses:

enter image description here

im Gegensatz dazu mit freundlicher Genehmigung von 99 Flaschen Bier :

beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall"; 
        end 
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then 
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall"; 
           end
    end
end

Im letzteren Fall arbeiten Sie mit Quellcode, der praktisch eine bekannte Größe ist, und einige der anderen Antworten bieten einige sehr weise Ratschläge für den Umgang damit.

Wenn der größte Teil der Codebasis die letztere ist oder selbst wenn es sich um einen beträchtlichen Teil handelt, werden Sie auf das interessante Problem stoßen, Code zu haben, der wahrscheinlich nicht überarbeitet werden kann, weil er extrem spezialisiert ist oder noch schlimmer, etwas, das aussieht Es kann entfernbar sein, aber wenn es nicht ordnungsgemäß dokumentiert ist, wissen Sie nicht, ob Sie kritischen Code entfernen (denken Sie an etwas in der Art eines Scram-Vorgang ), das anscheinend nicht so ist erster Blick.

Obwohl Ihre erste Priorität offensichtlich darin besteht, eine Art Versionskontrolle online zu stellen, wie bereits erwähnt ElYusubov , und es scheint, dass die Versionskontrolle unterstützt wurde seit Version 8. . Da es sich bei G2 um eine Kombination mehrerer verschiedener Sprachmethoden handelt, ist es wahrscheinlich am effektivsten, die mitgelieferte Versionskontrolle zu verwenden, anstatt zu versuchen, etwas anderes zu finden und es zum Laufen zu bringen.

Als nächstes, obwohl einige wahrscheinlich befürworten würden, mit der Umgestaltung zu beginnen, bin ich ein starker Befürworter, sicherzustellen, dass Sie das System, mit dem Sie arbeiten, vollständig verstehen, bevor Sie anfangen, einen der Codes zu berühren, insbesondere wenn Sie sich mit Code und visuellen Diagrammen befassen, die von entwickelt wurden Entwickler ohne formale Ausbildung (oder Hintergrund) in Software-Engineering-Methoden. Der Grund dafür ist vielfältig, aber der offensichtlichste Grund ist, dass Sie mit einer Anwendung arbeiten, in die möglicherweise mehr als 100 Personenjahre Arbeit investiert sind, und dass Sie wirklich sicherstellen müssen, dass Sie wissen, was sie tut und wie viel Dokumentation ist drin. Da Sie nicht gesagt haben, in welcher Branche das System eingesetzt wird, kann man aufgrund meiner Lektüre über G2 davon ausgehen, dass es sich wahrscheinlich um eine geschäftskritische Anwendung handelt, die möglicherweise sogar Auswirkungen auf die Lebenssicherheit hat . Daher wird es sehr wichtig sein, genau zu verstehen, was es tut. Es gibt Code, der nicht dokumentiert ist. Arbeiten Sie mit den anderen im Team zusammen, um sicherzustellen, dass die Dokumentation vorhanden ist, damit die Mitarbeiter bestimmen können, was der Code tut.

Wickeln Sie als Nächstes Unit-Tests so weit wie möglich um die Codebasis und die visuellen Diagramme. Ich muss zugeben, dass ich etwas Unwissenheit darüber habe, wie dies mit G2 gemacht werden soll, aber es könnte sich fast lohnen, ein eigenes Test-Framework zu erstellen, um dies zu erreichen. Dies ist auch ein idealer Zeitpunkt, um die anderen Mitglieder des Teams vorzustellen und sie an einige der strengeren Konstruktionspraktiken zu gewöhnen, die mit der Codequalität verbunden sind (d. H. Jeder Code muss Unit-Tests und Dokumentation enthalten).

Sobald Sie Unit-Tests für eine angemessene Menge des Codes durchgeführt haben, können Sie sich dem Refactoring auf eine Weise nähern, wie sie von haylem vorgeschlagen wird. Denken Sie jedoch daran, dass Sie sich mit etwas befassen, das für die Entwicklung von Expertensystemen und die Umgestaltung gedacht ist. Dies könnte ein harter Kampf sein. Dies ist tatsächlich eine Umgebung, in der etwas zu sagen ist, wenn nicht manchmal extrem generischer Code geschrieben wird.

Stellen Sie schließlich sicher, dass Sie genau darauf achten, was die anderen Teammitglieder sagen, nur weil die Code- und Diagrammqualität nicht die beste ist, werden sie nicht unbedingt schlecht reflektiert. Letztendlich wissen sie wahrscheinlich vorerst mehr über die Funktionsweise der Anwendung als Sie. Deshalb ist es für Sie umso wichtiger, sich hinzusetzen und sicherzustellen, dass Sie verstehen, was sie tut, bevor Sie ebenfalls umfassende Änderungen vornehmen.

9
rjzii

Normalerweise haben die Beschwerden, die Sie im Voraus hören, nichts mit den wichtigen Problemen zu tun. Schließlich ist es völlig normal, in Softwareprojekten von diesen Beschwerden zu hören.

Schwer zu verstehender Code? Prüfen. Massive Codebasis? Prüfen.

Das eigentliche Problem ist, dass die Leute gehen und wenn die neue Person der Organisation beitritt, gibt es eine typische Desorientierung. Darüber hinaus gibt es ein Problem mit unrealistischen Erwartungen und Problemen mit der Codequalität.

Folgendes würde ich in der folgenden Reihenfolge angehen:

  1. Backups, sowohl der Server als auch die lokale Version
  2. Richten Sie den Bug Tracker ein
  3. Richten Sie das Versionsverwaltungssystem ein
  4. Richten Sie FAQ/Wiki ein
  5. Erste Nachbesprechung aller Wissenschaftler/Programmierer
    • Erinnern Sie sie an die 80/20-Regel. 20% der Fehler sind für 80% der Probleme verantwortlich.
    • Konzentrieren Sie sich auf die größten Probleme und halten Sie Verbesserungswünsche usw. fern.
    • Der Zweck hier ist nicht, Leute mit einer großen Liste zu erschrecken, sondern eine Liste von kleinen erreichbaren Gewinnen. Schließlich müssen Sie auch Ihren Wert beweisen.
  6. Build-System einrichten
    • Arbeiten Sie daran, zuverlässige Builds zu erhalten (dies kann eine Weile dauern).
    • jedes Projekt identifizieren und benennen
    • zyklische Abhängigkeiten identifizieren
    • wenn einige Open-Source-Projekte Binärdateien enthalten, versuchen Sie, Quellen abzurufen
  7. Identifizieren Sie, wie der G2-Code modularisiert werden kann, z. APIs, Dienste
  8. Identifizieren Sie, wie der G2-Code getestet und dokumentiert werden kann.
  9. Richten Sie das Code-Überprüfungssystem ein
  10. Zweite Nachbesprechung
  11. Identifizieren Sie ein Crack-Team besserer Programmierer und arbeiten Sie mit ihnen zusammen, um ihre Module zu verpacken.
  12. In dieser Phase gibt es Codeüberprüfungen, um die Kommunikation und Dokumentation zu verbessern. Halten Sie es in dieser Phase einfach. Beheben Sie alle Prozessprobleme.
  13. Stellen Sie das System anderen Programmierern zur Verfügung. Lassen Sie die Mitglieder des Crack-Teams zu Peer-Mentoren für den Rest werden. Denken Sie daran, dass hier die Skalierung das Problem ist. Sie sind effektiv in einer Managementrolle.
9
Chui Tey

Fragen wie diese sind der ganze Grund, warum das Projekt Software Carpentry existiert.

In den letzten 14 Jahren haben wir Wissenschaftlern und Ingenieuren grundlegende Fähigkeiten in der Softwareentwicklung beigebracht: Versionskontrolle, Testen, Modularisieren von Code usw. Alle unsere Materialien sind unter einer Creative Commons-Lizenz frei verfügbar. Wir veranstalten jedes Jahr ein paar Dutzend kostenlose zweitägige Workshops, um den Einstieg zu erleichtern.

Auf dieser Grundlage denke ich, dass der beste Ausgangspunkt wahrscheinlich Robert Glass 'ausgezeichnetes (kurzes) Buch Fakten und Irrtümer der Softwareentwicklung ist: Sein evidenzbasierter Ansatz ist gut Der Weg, Wissenschaftler davon zu überzeugen, dass das, was wir ihnen über gute Programmierpraktiken erzählen, mehr als nur eine Meinung ist.
In Bezug auf bestimmte Praktiken sind die beiden, zu denen die Menschen am ehesten bereit sind, Versionskontrolle und Komponententests; Sobald diese vorhanden sind, können sie die Art von systematischem Refactoring in Angriff nehmen, die Michael Feathers in Effektiv mit Legacy-Code arbeiten beschreibt.
Ich empfehle The Pragmatic Programmer (viel Ermahnung, die für Anfänger schwer in die Praxis umzusetzen ist), und ich denke McConnells Code Complete ist zu viel für den Anfang (obwohl es eine großartige Sache ist, ihnen sechs Monate oder ein Jahr Zeit zu geben, sobald sie die Grundlagen beherrschen).

Ich würde auch Paul Dubois 'ausgezeichnetes Papier "Aufrechterhaltung der Korrektheit in wissenschaftlichen Programmen" ( Computing in Science & Engineering, Mai-Juni 2005), das beschreibt, wärmstens empfehlen Ein "Tiefenverteidigungs" -Ansatz, der ein Dutzend verschiedener Praktiken auf logische, kohärente Weise kombiniert.

9
Greg Wilson

Ich denke zuerst müssen Sie Ihre Situation klären. Was wollen sie von Ihnen?

  • Es ist sehr unwahrscheinlich, dass sie möchten, dass Sie eine alte Sprache lernen, da dies nun eine Sackgasse zu sein scheint: Es besteht eine abnehmende Chance, jemanden zu finden, der G2 kennt oder lernen möchte, sodass das Wissen in dem zusammenbrechenden Haufen Code vergraben wird, wenn Die aktuellen Wissenschaftler gehen oder der vollständig gepatchte Code schlägt immer häufiger fehl.
  • Sind die Wissenschaftler (oder einige von ihnen) bereit, eine neue Sprache und viele Programmierparadigmen zu lernen? Oder wollen sie die Programmier- und wissenschaftlichen Aktivitäten langfristig trennen und vielleicht bei Bedarf weitere Programmierer haben? Dies scheint eine rationale und effizientere Trennung von Fachwissen zu sein.

Ich denke, die Grundvoraussetzung hier ist, "das Wissen im System zu speichern", also muss man es ausgraben!

Die erste Aufgabe besteht darin, eine Dokumentation zu schreiben.

Analysieren Sie die Struktur und die Anforderungen so, als wäre dies eine neue Aufgabe, jedoch mithilfe eines vorhandenen Systems. Sie werden sich freuen, weil Sie fragen, anstatt zuerst zu unterrichten - und Sie werden schnell genug, aber besser organisiertes Hintergrundwissen aus Sicht eines Programmierers erhalten: "Was ist hier los?" Die Dokumente (statische Systemstruktur, Workflow, Komponenten, Probleme) sind für sie sofort wertvoll und zeigen ihnen möglicherweise relevantere Informationen als Ihnen (einige der Jungs haben möglicherweise "AHA!" Und beginnen sofort mit der Korrektur einiger Codes ) ...

Sie sollten dann fragen, wohin sie wollen?

Wenn sie bereit sind, sich von G2 zu entfernen , welches System möchten sie sehen (Plattform, Sprache, Schnittstelle, allgemeine Struktur)? Sie können nach Möglichkeit einen externen Wrapper um das System schreiben, der die Zielstruktur aufweist, aber die ursprünglichen Komponenten beibehält, und so langsam eine Art Framework starten, mit dem neue Komponenten in dieser Zielumgebung implementiert werden können. Sie müssen die Kerndienste finden (dauerhafte Datenverbindungen und "Toolkits": Kernberechnung, Zeichnen, ... Bibliotheken) und ihnen eine vertraute Umgebung in einer neuen Plattform und Sprache bieten, die den Übergang entweder von Ihnen oder von Ihnen ermöglicht sie: nimm die alten Codes eins nach dem anderen, implementiere sie neu (und reinige sie!) in der neuen Umgebung. Wenn das fertig ist, kennen sie die neue Sprache; und die Service-Schicht (meistens von Ihnen erstellt, sorry) ist bereit, die neuen Komponenten zu hosten.

Wenn sie sich nicht bewegen , müssen Sie G2 lernen und dort das modulare Framework erstellen, in das Sie oder sie die Komponenten verschieben sollen (mit Reinigung). . Wie auch immer, die Sprache ist nur eine Serialisierung von Daten und Algorithmusbaum ...

Während Sie die Dokumente analysieren und schreiben, lesen, verwenden und bewerben Sie GoF-Designmuster! :-)

... meine 2 Cent

7
Lorand Kedves

Ich habe gerade eine Reihe von Präsentationen über Robert Martins SOLID Prinzipien für meine Mitarbeiter) durchgeführt. Ich weiß nicht, wie gut sich diese Prinzipien auf G2 übertragen lassen, aber da Sie nach 5 suchen -7 Kerngrundlagen, diese scheinen zunächst ein gut etablierter Satz zu sein. Wenn Sie ihn auf 7 aufrunden möchten, können Sie mit DRY] beginnen und Fail-Fast einwerfen.

4

"Das Programm selbst ist ein physikalisches Modell einer komplexen chemischen Verarbeitungsanlage ..."

"Da G2 wie kein Code ist, sondern eher automatisierter Code, der von einer gawawful GUI geschrieben wurde ..." - Erik Reppen

Angenommen, das Hauptziel Ihrer Software besteht darin, eine komplexe Chemiefabrik oder Teile einer solchen zu simulieren (möglicherweise zu optimieren, Parameterschätzungen durchzuführen) ... dann bin ich ' Ich möchte einen etwas anderen Vorschlag machen:

Sie sollten die Verwendung einer mathematischen Modellierungssprache auf hoher Ebene in Betracht ziehen, um die Essenz, die wichtigsten mathematischen Modelle, aus handcodierter Software, zu extrahieren.

Eine Modellierungssprache entkoppelt die Beschreibung des Problems von den zur Lösung des Problems verwendeten Algorithmen. Diese Algorithmen sind im Allgemeinen auf die meisten Simulationen/Optimierungen einer bestimmten Klasse (z. B. chemische Prozesse) anwendbar. In diesem Fall sollten sie wirklich nicht neu erfunden und intern gewartet werden.

Drei kommerzielle Pakete, die in Ihrer Branche weit verbreitet sind, sind: gPROMS, Aspen Custom Modeller und (wenn Ihre Modelle keine Phänomene enthalten, die über räumliche Domänen verteilt sind) Modelica-basierte Softwarepakete wie Dymola.

Alle diese Pakete unterstützen "Erweiterungen" auf die eine oder andere Weise, sodass Teile Ihrer Modelle, die eine benutzerdefinierte Programmierung erfordern, in ein Objekt (z. B. eine DLL) eingekapselt werden können, auf das durch die Gleichungen in der verwiesen werden kann Modell. In der Zwischenzeit bleibt der Großteil Ihres Modells prägnant und wird in einer Form beschrieben, die von den Wissenschaftlern direkt gelesen werden kann. Dies ist eine viel bessere Möglichkeit, das Wissen und die IP Ihres Unternehmens zu erfassen.

Die meisten dieser Programme sollten es Ihnen auch ermöglichen, kleine Teile (Untermodelle) Ihres monolithischen Codes zu starten und in ihr Format zu portieren, indem Sie extern aufgerufen werden. Dies kann eine gute Möglichkeit sein, ein funktionierendes System zu warten und Stück für Stück zu validieren.

Voller Haftungsausschluss: Ich habe 8 Jahre als Software-Ingenieur bei der Firma hinter gPROMS gearbeitet. In dieser Zeit sah ich Beispiele für kundenspezifische Software (z. B. aus der Wissenschaft), die klein und ordentlich angefangen hatte, eine clevere Lösung oder einen cleveren Algorithmus implementierte, aber im Laufe der Jahre mit Erweiterungen und Modifikationen explodierte - ohne die hilfreiche Anleitung von ein Softwareentwickler, um es sauber zu halten. (Ich bin ein großer Fan von multidisziplinären Teams.)

Daher kann ich mit einiger Erfahrung sagen, dass bestimmte Schlüsselentscheidungen, die zu Beginn der Softwareentwicklung schlecht getroffen wurden (wie eine Sprache oder eine Schlüsselbibliothek), dazu neigen, lange Zeit zu bleiben und Schmerzen zu verursachen ... Sie haben die bereits "geformt" Software um sie herum. Es hört sich für mich so an, als könnten Sie hier viele, viele Jahre reiner Code-Reinigung gegenüberstehen. (Ich zögere, Zahlen zu verwenden, aber ich denke über 10 Personenjahre nach, vielleicht viel mehr, wenn Sie den Code nicht von G2 auf etwas portieren können, das gute automatisierte Refactoring-Tools wie Eclipse/Java Quick-Smart unterstützt.)

Während mein Standardstatus "Refactor und Beibehalten eines funktionierenden Systems" ist, denke ich auch, dass ein radikaleres Ändern/Umschreiben insgesamt schneller wird, sobald ein Problem "zu groß" wird. (Und bringt möglicherweise zusätzliche Vorteile mit sich, z. B. den Sprung zu einer moderneren Technologie.) Ich sage, dass mit etwas Erfahrung das Portieren auf eine neue Softwareplattform, aber meiner Erfahrung nach ist es mit einem Port auf ein mathematisches Modellierungspaket noch dramatischer.

Um eine Perspektive zu geben, könnten Sie über die Größenreduzierung ziemlich erstaunt sein. Z.B. Die 200.000 LoC könnten tatsächlich in etwa 5.000 Gleichungszeilen dargestellt werden (OK, ich vermute hier, aber ich könnte versuchen, Ihnen ein aktuelles Zeugnis von Freunden im Geschäft zu geben). plus ein paar relativ kleine Funktionsbausteine, die in so etwas wie C geschrieben sind (zum Beispiel Berechnungen der physikalischen Eigenschaften - obwohl abhängig von Ihrem chemischen Prozess möglicherweise wieder Standardpakete vorhanden sind). Dies liegt daran, dass Sie den algorithmischen Lösungscode buchstäblich einfach wegwerfen und einen universellen Stapel mathematischer Löser die harte Arbeit erledigen lassen. Sobald Sie Simulationen ausgeführt haben, können Sie viel mehr damit tun, z. B. den Prozess optimieren - ohne eine Codezeile zu ändern.

Abschließend würde ich sagen: Wenn die einzige zuverlässige Dokumentation der verschiedenen mathematischen Modelle (und Algorithmen) der Code selbst ist, möchten Sie die Hilfe der Wissenschaftler und Originalautoren, um diese Modelle so schnell wie möglich herauszuholen, und nicht Jahre später Einige von ihnen sind vielleicht weitergezogen. Sie sollten feststellen, dass eine mathematische Modellierungssprache eine sehr natürliche Möglichkeit ist, diese Modelle zu erfassen - sie können es sogar (Schockhorror) genießen, sie (neu) zu schreiben.


Da meine Antwort möglicherweise falsch ist, möchte ich der Liste der guten Bücher, auf die hier bereits verwiesen wird, noch ein weiteres Buch hinzufügen: Clean Code von Robert Martin. Voller einfacher (und gerechtfertigter) Tipps, die leicht zu erlernen und anzuwenden sind, aber für Menschen, die in Ihrem Unternehmen neuen Code entwickeln, einen großen Unterschied bedeuten können.

3
Luke Usherwood

Das einzige Produktionsproblem klingt nach einem Problem mit dem Änderungsmanagement. Wenn dies der Fall ist und die Software dies anderweitig ausführt, würde ich als ersten Ratschlag dem Drang widerstehen, zu schnell zu viel zu tun.

Quellcodeverwaltung, Refactoring und besser ausgebildete Entwickler sind gute Vorschläge. Wenn Sie sich jedoch zum ersten Mal mit solchen Problemen befassen müssen, die sich langsam bewegen und kontrollierte Änderungen vornehmen, kann dies nicht genug betont werden.

Der Drang, das Chaos zu überwinden, wird manchmal groß sein, aber bis Sie genug davon rückentwickelt haben, dass Sie wissen, dass Sie Ihre Ersatzversion angemessen testen können, müssen Sie sehr vorsichtig sein.

3
Bill

Die wichtigsten Prinzipien für das Arbeiten in einer solchen Situation sind:

  1. Sei geduldig. Ein Loch, das Dig 20 Jahre gekostet hat, wird in ein paar Wochen nicht mehr gefüllt sein.

  2. Sei positiv. Widerstehen Sie der Versuchung, sich zu beschweren und zu meckern.

  3. Sei pragmatisch. Schauen Sie sich eine positive Veränderung an, die Sie an einem Tag erreichen können, und tun Sie dies heute. Hast du schon ein Versionskontrollsystem? Implementieren Sie es und schulen Sie Menschen. Überprüfen Sie dann, ob Sie das Testen automatisieren können (Unit-Test oder ähnliches). Spülen. Wiederholen.

  4. Sei ein Model. Zeigen Sie den Menschen, wie agil funktioniert, indem Sie agil sind. Die ersten drei Punkte oben sind der Schlüssel, um ein guter Kerl zu sein, der der Vorgänger eines effektiven agilen Kerls ist. Meiner Meinung nach sind Leute, die bewundernswerte Entwickler sind, nicht nur schlau, sondern auch gute, vorbildliche Mitarbeiter und Kollegen.

  5. Kartieren Sie Ihr Gebiet. Ich habe eine Technik zum Abbilden von riesigen Legacy-Codebasen. Ich klone das Repo, erstelle eine Arbeitskopie und versuche dann, etwas zu ändern und zu sehen, was sonst noch kaputt geht. Indem ich die Kopplung untersuche (über einen globalen Status oder defekte APIs oder einen Mangel an konsistenter API oder Abstraktionen oder Schnittstellen, gegen die programmiert werden kann) und den Code lese, der beim Ändern von Dingen kaputt geht, entdecke ich die Cruft und stelle Fragen, die dazu führen Erkenntnisse aus dem Rest des Teams (Oh, wir haben hinzugefügt, dass es nie funktioniert hat, weil Boss X dies vor 5 Jahren gefordert hat!). Im Laufe der Zeit erhalten Sie eine mentale Karte des Territoriums. Sobald Sie wissen, wie groß es ist, wissen Sie genug, um Ihre Karte zu erstellen und nach Hause zu kommen. Ermutigen Sie andere, das Territorium Ihrer riesigen Codebasis abzubilden und das technische Wissen des Teams aufzubauen. Einige Leute scheuen "Dokumentation", weil sie nicht agil ist. Wie auch immer. Ich arbeite auch in wissenschaftlichen Umgebungen und Dokumentation ist für mich König, agile Manifeste sind verdammt.

  6. Erstellen Sie kleine Apps. Wenn ich mit einer alten Codebasis arbeite, finde ich, dass ich zu Brei zermahlen werde. Ich bekomme meinen Geist zurück, indem ich kleine Helfer-Apps baue. Vielleicht helfen Ihnen diese Apps beim Lesen, Verstehen und Ändern dieser riesigen G2-Codebasis. Vielleicht können Sie ein Mini IDE oder Parser-Tool erstellen, das Ihnen bei der Arbeit in Ihrer Umgebung hilft. In vielen Fällen helfen Ihnen Meta-Programmierung und Tool-Erstellung nicht nur, aus dem Riesen auszubrechen Deadlocks, die Ihnen ältere Codebasen auferlegen, geben Ihrem Gehirn auch die Möglichkeit, uneingeschränkt von Ihrer G2-Sprache zu fliegen. Schreiben Sie Ihre Tools und Helfer in jeder Sprache, in der Sie sie am schnellsten und besten ausführen können. Zu diesen Sprachen gehören für mich Python und Delphi Wenn Sie ein Perl-Typ sind oder tatsächlich gerne in C++ oder C # programmieren, schreiben Sie Ihre Hilfsprogramme in dieser Sprache. Bringen Sie dem Rest des Teams bei, kleine Hilfsprogramme und -tools sowie "Komponenten" zu erstellen. Ich werde irgendwann sehen, dass Ihre alte Codebasis doch nicht so entmutigend ist.

3
Warren P
  1. Revisionskontrolle: Zeigen Sie den Domain-Experten den Vorteil, dass Sie zurücksetzen, sehen können, wer was geändert hat usw. (Dies ist schwieriger bei rein binären Dateien, aber wenn der Inhalt tatsächlich Code ist, gibt es ihn sicherlich eine Art G2-zu-Text-Konverter, der Unterschiede aktivieren kann.)

  2. Kontinuierliche Integration und Test: Binden Sie die Domain-Experten in die Erstellung von End-to-End-Tests (einfacher, da sie bereits irgendwo Eingaben und erwartete Ausgaben haben müssen) und kleine Komponententests (schwieriger, weil Spaghetti-Code wahrscheinlich) ein beinhaltet viele globale Variablen), die nahezu alle Funktionen und Anwendungsfälle abdecken.

  3. Refactor Common Code in wiederverwendbare Routinen und Komponenten. Nicht-Software-Benutzer ohne Revisionskontrolle kopieren und fügen wahrscheinlich Hunderte von Zeilen gleichzeitig ein, um Routinen zu erstellen. Finden Sie sie und überarbeiten Sie sie. Dies zeigt, dass alle Tests bestanden wurden und der Code kürzer geworden ist. Dies wird Ihnen auch helfen, die Architektur zu lernen. Wenn Sie Glück haben, wenn Sie anfangen müssen, die schwierigen architektonischen Entscheidungen zu treffen, sind Sie möglicherweise auf 100KLOC gesunken.

Politisch Wenn Sie in diesem Prozess auf Widerstand der Oldtimer stoßen, stellen Sie einen Berater ein, der einen Vortrag über eine gute Softwaremethodik hält. Stellen Sie sicher, dass Sie eine gute finden, deren Ansichten Sie zustimmen, und veranlassen Sie das Management, die Notwendigkeit des Beraters zu prüfen, auch wenn die Domain-Experten dies nicht tun. (Sie sollten zustimmen - schließlich haben sie Sie eingestellt, so dass sie offensichtlich erkennen, dass sie Software-Engineering-Know-how benötigen.) Dies ist natürlich ein geldverschwenderischer Trick, aber der Grund ist, dass Sie - der neue Hotshot-Youngster-Programmierer - davon erzählen Wenn sie etwas tun müssen, können sie es ignorieren. Aber wenn das Management einem Berater 5.000 US-Dollar zahlt, um ihm zu sagen, was er tun muss, wird er mehr Vertrauen in ihn setzen. Bonuspunkte : Lassen Sie den Berater doppelt so viele Änderungen empfehlen, wie Sie wirklich möchten. Dann können Sie der "Gute" sein und auf der Seite der Domain-Experten stehen Kompromisse eingehen, um nur halb so viel zu ändern, wie der Berater vorgeschlagen hat.

3
Conrad Poelman

Führen Sie zuerst die Analyse durch.

Ich würde einige Analysen durchführen, bevor ich mich entscheide, was ich unterrichten soll. Finden Sie heraus, wo die größten Schmerzpunkte liegen. Verwenden Sie diese, um zu priorisieren, welche Praktiken durchlaufen werden sollen.

Führen Sie jeweils nur wenige Änderungen ein (in einer ähnlichen Situation habe ich alle 2 Wochen 2-3 Übungen durchgeführt) .

Ich würde die Praktiken auf ~ 3 beschränken, abhängig vom Grad der Änderung des Programmierstils von SDLC. bis sie anfangen, sich mit ihnen vertraut zu machen (ich würde mich bemühen, alle ~ 1-2 Wochen 1 neue Änderung einzuführen, da sie sich mit der Idee, neue Ansätze zu lernen, besser vertraut machen). Es ist auch eine gute Idee, die Erfolgskriterien zu ermitteln. Was die Praxis erreichen sollte (auch wenn es ein weiches Ziel wie die Moral des Teams ist). Auf diese Weise können Sie zeigen, ob es effektiv ist oder nicht.

  • Warum die Anzahl der Änderungen begrenzen?

Selbst wenn Sie davon ausgehen, dass diese Leute bessere Programmierer sein wollen und offen für das Lernen sind, gibt es Grenzen, wie viel und wie schnell Leute neue Konzepte lernen und anwenden können. vor allem, wenn sie keine CS-Grundlage haben oder zuvor an einem Software Development Life Cycle teilgenommen haben.

Fügen Sie eine wöchentliche Abschlussbesprechung hinzu, um zu besprechen, wie sich die Praktiken auf sie ausgewirkt haben.

Das Treffen sollte genutzt werden, um zu diskutieren, was gut gelaufen ist und was Arbeit braucht. Erlauben Sie ihnen, eine Stimme zu haben und zusammenzuarbeiten. Besprechen und planen Sie, um Probleme zu beheben und eine Vorschau auf die nächsten Änderungen zu erhalten. Konzentrieren Sie sich auf die Praktiken und deren Anwendung. Evangelisieren Sie ein wenig über die Vorteile, die sich aus der Anwendung der Praktiken ergeben sollten.

Bestimmte Praktiken haben Vorrang.

Die ordnungsgemäße Verwendung eines Versionskontrollsystems (IMO) übertrifft alles andere. Knapp dahinter liegen Lektionen in Modularisierung, Kopplung/Zusammenhalt und Feature/Bug-Ticket-Tracking.

Entfernen Sie Praktiken, die nicht funktionieren.

Haben Sie keine Angst, Praktiken loszuwerden, die nicht funktionieren. Wenn es hohe Kosten und wenig bis gar keinen Nutzen gibt, entfernen Sie die Praxis.

Verbesserung ist ein Prozess.

Vermitteln Sie, dass eine nachhaltige, konsequente Verbesserung ein Prozess ist. Identifizieren Sie die größten Schwachstellen, wenden Sie eine Lösung an, warten Sie/coachen Sie und wiederholen Sie dann. Es wird sich anfangs quälend langsam anfühlen, bis Sie etwas Schwung aufbauen. Konzentrieren Sie sich auf die kommenden Verbesserungen und die bereits erfolgreichen Verbesserungen.

2
dietbuddha

Ich würde folgendes runterwerfen:

  1. Hier gibt es einen Programmierer. Scheiß auf Politik. Sie kennen ihr Handwerk. Du kennst deins. Markiere dieses Gebiet, auch wenn du darauf pissen musst. Sie sind Wissenschaftler. Sie können so etwas respektieren oder sollten es, da sie so ziemlich ständig dasselbe selbst tun. Markieren Sie jetzt mit allen Mitteln die Grenzen. Das werde ich beheben. Dafür kann ich nicht verantwortlich sein.

  2. Wissenschaftler schreiben/testen die Algorithmen. Wissenschaftler, die ihre eigenen Algorithmen in 1-3 Sprachen schreiben möchten, können sich darauf einigen, dass Sie in Kerncode konvertieren. Das bringt sie dazu, ihre Sachen zu testen. Darüber hinaus müssen sie Ihnen helfen, die wichtigen wissenschaftlichen Dinge im Vergleich zu dem, was sie für die Architektur getan haben, zu isolieren. Die Codebasis ist abgespritzt. Es gibt viele Brandrodungen, die durchgeführt werden müssen. Geben Sie ihnen Optionen, um Ihnen Arbeitsversionen von Dingen zu übergeben, die das verwenden, was sie am besten wissen, damit Sie das tun können, was Sie am besten können. Stecken Sie ihr Wissen in eine Box, für die sie verantwortlich sind, mit der Sie jedoch arbeiten können. Idealerweise geht es bei Mega-Refactor-Gesprächen eher darum, welche aufregenden Dinge Sie mit der Benutzeroberfläche tun können, als darum, was Tentakel Z9 von drBobsFuncStructObjThingMk2_0109 getan hat, als es die globale Variable X19a91 verärgert hat.

  3. Verwenden Sie eine ereignisgesteuerte Sprache mit erstklassigen Funktionen, wenn Sie können. Wenn alles andere fehlschlägt, kann das Auslösen eines Ereignisses oder das Zurückwerfen eines Rückrufs auf ein Objekt mit einer tatsächlich sinnvollen Schnittstelle und einem Statusmechanismus eine enorme Zeitersparnis bedeuten, wenn Sie knietief in Code stecken, der keinen blutigen Sinn ergibt und möglicherweise nie werden. Wissenschaftler scheinen Python zu mögen. Es ist nicht schwer, mathematisch intensives C-Zeug auf niedrigerer Ebene damit zu verkleben. Ich sag bloß'

  4. Suchen Sie nach jemandem, der dieses oder ein ähnliches Problem gelöst hat. Verbringen Sie einige Zeit mit Nachforschungen. Diese Leute haben von jemandem von G2 gehört.

  5. Designmuster. Adapter. Benutze sie. Verwenden Sie sie häufig in solchen Situationen.

  6. Erfahren Sie, was Sie von der Wissenschaft können. Je mehr Sie wissen, desto besser können Sie die Absicht im Code bestimmen.

2
Erik Reppen

Die Quellcodeverwaltung ist Schritt 1, wie bereits mehrfach angegeben. Während die Leute, mit denen Sie arbeiten, möglicherweise keine professionellen Entwickler sind und nicht auf viele unternehmerische oder agile Hokuspokus reagieren. Sie sind auch keine Low-Level-Code-Affen, und der Versuch, sie so zu behandeln, indem sie gezwungen werden, Dinge auf Ihre Weise zu tun, wird nicht fliegen.

Sie müssen überblicken, was da draußen ist. Wenn sie die Quellcodeverwaltung nicht verwendet haben, wird es lange dauern, nur die richtigen Versionen des Codes (falls möglich) zu identifizieren und alle möglichen Ergebnisse zu ermitteln. Dann haben Sie die Aufgabe, Ihren Kollegen den Umgang mit der Quellcodeverwaltung beizubringen und sie davon zu überzeugen, dass sich ihre Zeit lohnt. Beginnen Sie mit den Vorteilen!

Finden Sie dabei andere niedrig hängende Früchte und beheben Sie diese Probleme.

Hören Sie vor allem zu, was sie zu sagen haben, und arbeiten Sie daran, ihre Situation zu verbessern. Machen Sie sich keine Sorgen darüber, was sie tun.

Viel Glück!

0
Bill

Klingt so, als ob der erste Schritt darin besteht, dem Team die Notwendigkeit zu verkaufen, in neue Softwaremethoden zu investieren. Gemäß Ihrer Aussage gibt es keine Übereinstimmung im Team, und Sie benötigen diese, um ein langsames "Upgrade" des Codes durchführen zu können.

Ich würde (wenn ich kann) persönlich die harten Lektionen nehmen und jedes der Schlüsselkonzepte vorstellen, die Sie als Lösung für das Problem in der Softwareindustrie wollen.

Z.B. Zwei Entwickler hatten unterschiedliche Kopien und stellten schließlich eine nicht getestete Hybridversion bereit -> Einführung in Versionskontrolle, Verzweigung und Testen.

Jemand hat ein paar Codezeilen entfernt, die er nicht verstanden hat, und einen Ausfall verursacht -> DDD einführen.

Wenn die harten Lektionen nicht detailliert genug mit Ihnen geteilt werden, zeigen Sie einfach Ihre eigenen Beispiele dafür, wie etwas schief gelaufen ist, als diese Disziplin nicht eingehalten wurde.

0
M Afifi