Wie pflegt man eine Codebasis von schlechter Qualität?

Question

Um den Code, den ich schreibe, beibehalten zu können, muss ich die Variablen gut benennen, meinen Code dokumentieren, sicherstellen, dass sich nichts wiederholt, dass Abstraktionen funktionieren, sodass keine Hacks erforderlich sind.und kommentieren Sie sparsam, da Kommentare mich oft beim Lesen des Codes unterbrechen.

Aber viele andere Codebasen, die ich gesehen habe, ähneln eher einem Strudel.Die Variablennamen sind foobar, Dinge werden berechnet, auch wenn sie nie benötigt werden, viele Hacks und Patches werden angewendet, Abstraktionen schlagen fehl, Bereitstellungsskripte schlagen fehl ...Der Code ist eine unverständliche und nahezu unbrauchbare Suppe.

Also!Ich bin neugierig.Wie schaffen Sie es, eine Codebasis von schlechter Qualität aufrechtzuerhalten?

Answer 1

Disziplin

Answer 2

Konstante Refactoring; wenn Sie eine Code-Datei öffnen und Sie sehen etwas seltsam, können Sie ein paar Minuten Zeit investieren, um die Gestaltung des bestehenden Codes zu verbessern.

eine Reihe von Komponententests haben, können Ihnen mit ihm helfen, wie es Ihnen Vertrauen gibt, ob den Code, den Du zu ändern immer noch funktioniert oder bricht aufgrund Ihrer Änderung.

Es ist ein bisschen wie die Geschichte ein zerbrochenes Fenster in einem Haus zu haben. Wenn Sie ein zerbrochenes Fenster sehen, sollten Sie es beheben. Wenn Sie es nicht beheben, werden die Dinge von dort starten detoriate, und es wird in einem unmaintenable Chaos zur Folge hat.

Die meisten meiner Projekte sind auch onder Kontinuierliche Integration setzen; neben dem Aufbau und Unittests, eine statische Codeanalyse (FxCop) wird ebenfalls durchgeführt, ausgeführt wird. Hin und wieder habe ich einen Blick auf die Ergebnisse, und versuchen, einige Verletzungen zu beheben, die gemeldet werden.

Answer 3

Im Allgemeinen, was Sie beschreiben, ist die natürliche Tendenz jeder Codebasis Entropie zu erhöhen. Es geschieht in jedem Projekt von der Tugend der es entwickelt und gepflegt werden. Um diesen stetigen Anstieg zu bekämpfen würde ich vorschlagen, die folgende:

1. Jemand im Team mit genügend Autorität hat zu kümmern. Dies ist der wichtigste Teil. Wenn niemand kümmert, wird es nicht getan. Dieser Punkt scheint offensichtlich, aber es ist nicht.

2. Set-Standards und Best Practices. Die meisten Sprachen haben ein Buch von jemandem über die besten Praktiken geschrieben. Zum Beispiel in PERL ist es ein sehr gutes Perl Best Practices Buch von Damain Conway. Es sei denn, Sie dies tun, hat jede Person im Team seine eigene Art und Weise zu schreiben Code, Namen Variablen, Kommentar und so weiter.

3. Code Reviews. Hier finden Sie eine Checkliste für Code-Reviews muß. Es ist nicht genug, dass Ihre Änderung funktioniert, hat es auch auf die Liste der besten Praktiken entsprechen. Wir setzten einen zweireihigen Code-Reviews auf, erste Stufe ist Peer-Code-Reviews und die zweite Stufe ist ein Release-Manager, der die Code-Qualität kümmert sich um.

4. Design Reviews. Wenn Fehler oder Verbesserung in Bug-Tracking-System gefüllt ist, ist es wichtig, sie durch eine Änderung Steuerkarte überprüft werden, die auf Planung der Arbeit entscheidet, und auch darüber, wer die Gestaltung der Arbeit überprüfen muß. Hier können Sie die Code-Abstraktionen halten und sicherzustellen, dass die Änderung für das Projekt zu entwerfen, Dokumente und Ziele werden entsprechen. Der Software-Architekt des Teams oder einem Lead Designer sollte ein Teil der CCB.

sein

5. Check-Code-Qualität auslöst. Einige Best Practices können direkt Code erzwungen werden. Schreiben Sie kleine Skripte, die Ihren Code überprüfen für Dinge wie Formatierung, Verwendung von Tabs / Räume und so weiter. Dies wird helfen, denken Sie über die Qualität des Codes in einer anderen Art und Weise.

Einige Lesen für eine Referenz.

Answer 4

Peer Reviews schnell eine Code Qualitätsnorm schaffen, die auf einem Stück Papier zu quantifizieren ist hart. Unit-Tests können Sie Code mit wenig Angst ändern. Disziplin, viel davon.

Answer 5

Eine weitere Frage: Wie die Menschen weg von schlechter Qualität Code mit dem Schreiben erhielten

Hier ist die Antwort.

Eine gute Strategie für inkompetent Menschen in unserer Branche ist dies:

1. Die Fähigkeit entwickelt beeindruckend zu klingen vor allem auf die nicht-technischen und halbtechnischen Menschen. Die Lage sein, zu klingen plausibel genug, um die technischen Menschen, genug, um sie zu halten off-balance.

2. Machen Sie eine komplette Chaos der Code, den Sie berühren.

3. Nun ist dies der entscheidende Teil: Lassen Sie und eine bessere Arbeit finden anderswo, kurz bevor Sie herausgefunden werden. Der beste Zeitpunkt hängt von den jeweiligen Umständen ab.

Answer 6

Ich möchte Sie auf einen Begriff einzuführen hörte ich vor ein paar Jahren - Technische Schulden . Hier ist ein (1) Wikipedia-Eintrag und ein anderer von Martin Fowler (2) Webseite .

Im Grunde glaube ich nicht Leute das Ziel beginnen crummy Software zu bauen. Was normalerweise passiert ist, dass Zeitrahmen komprimiert sind, werden Anforderungen modifiziert oder Mitte der Entwicklung und eine beliebige Anzahl von anderen kommerziellen Realitäten beißen in den Mittelpunkt der Qualitätsentwicklung und Design ersetzt.

Von Fowler:

  

"Dinge zu tun, die eine schnelle und schmutzige Art und Weise   setzt uns mit einer technischen Schulden auf,   was zu einer Finanzschuld ähnlich ist.   Wie ein Finanzschulden, die technischen   Schulden entstehen Zinszahlungen, die   kommt in Form des zusätzlichen Aufwand   dass wir auch in Zukunft tun   Entwicklung aufgrund der schnellen und   schmutzig Design Wahl. "

Aus Wikipedia:

  

"Aktivitäten, die verschoben werden könnten,   umfassen Dokumentation, Schreiben von Tests,   Teilnahme Kommentare Todo und   Bekämpfung der Compiler und statischer Code   Analyse Warnungen. Andere Instanzen   Technische Schulden umfassen Wissen, dass   nicht um die Organisation geteilt   und Code, der zu verwirrend sein   leicht modifiziert. "

Was ich gesehen habe (und leitete mehr Entwicklungsteams zu tun) ist die Code-Basis Iterationen früh in der Entwicklung, Refactoring und zu reinigen, in der Regel zu Beginn, bevor neue Arbeit entwickelt wird.

Peer Reviews, Unit-Tests und professionelle Software-Tester alle dazu beitragen, einen Teil dieser technischen Schulden, sowie gute Prognose (und eine gute Wiederverwendung von Code) zu erstatten.

Wenn Sie das Budget haben, automatisierte Tests können eine gute Investition sein, solange Sie bereit sind, die Instandhaltung (Zeit, Aufwand) zu zahlen.

Es gibt viele hochwertige Werkzeuge um heute wie FXCop (und andere wie es) aber Sie sorgfältig wählen, welche Ansätze Sie gehen zu unterhalten.

Effort Qualität in Design und in der Code-Basis bei der Aufrechterhaltung hat zu bilanzieren, so denken Sie sorgfältig über die effektivste und nützliche Art und Weise für Ihre Entwicklungsteam / Produkte / Unternehmen / Kunden etc.

[(1) http://en.wikipedia.org/wiki/Technical_debt ]
[(2) http://martinfowler.com/bliki/TechnicalDebt.html ]

Answer 7

Dies ist nur dann der Fall, wenn Sie schreiben den Code und andere Die Leute haben es gelesen
1.Verließ die schlechte Angewohnheiten
2. Sinnvoll verwenden Prozedur, Funktion, Variablenname
3. Nutzen Sie die Dokumentation Machen Sie keine unnötigen Kommentare dazu, wie es funktioniert (Prozedur/Funktion/Berechnung usw.) und was daraus resultiert
4.Versuchen zu Geben Sie Ihrer Codierung Stil damit die Leute es wissen können (z. B. durch die Verwendung von Code im GNU-Stil)
oder
Verwenden Sie dazu Code Beautifier
5. Denken Sie daran, als Team zu arbeiten (auch wenn Sie alleine wären) und nicht nur Sie werden Ihren Code lesen (selbst wenn es so wäre)
6. Refactoring-Code sollte auch gut sein
7. Beraten Sie sich mit Ihren Teamkollegen Können sie den Code, den Sie geschrieben haben, lesen?
8. Lernen Sie von der OpenSource-Community, wie sie funktionieren und Codes und Patches teilen
9.Wenn Sie können, verwenden Sie SVN oder CVS für die Pflege Ihres Codes

und merke dir KUSS Prinzip (Kpiep ICHT Seinfach, Sdumm)

und natürlich Einfach, schlank, gemein und schön

Wenn es umgekehrt wäre (andere Leute schreiben, du liest), wusste ich nicht, was ich sagen sollte :D (vielleicht gib den Leuten oben Ratschläge, LOL)

Answer 8

Dokumentation, Quellcodeverwaltung, Komponententests und ein guter Programmierer zu sein.

Answer 9

Eine umfassende Suite von Unit-Tests, die ohne sich Gedanken über brechen vorhandenen Code für Änderungen und Refactoring erlaubt.

Ich empfehle, eine Kopie von Michael Feathers picking up "Effektives Arbeiten mit Legacy Code".

Answer 10

fridgemagnet sagen: "Dull Programmierer haben einwandfrei Codebases"

Answer 11

können Sie erhalten nur die Aufrechterhaltung einer Code-Basis schlecht weg, wenn Sie einen sehr kleinen (weniger als 10 bis 20 Personen oder so auf einem einzigen Projekt) sind Entwicklungsteam. Wenn Ihr Projekt wächst und Ihr Team wächst, entweder Ihre Praktiken skalieren oder Sie werden scheitern.

Die Änderung Sie fragen ist im Wesentlichen der Übergang von der Programmierung Hacking und schließlich Software Engineering.

Mit Software Engineering erkennen Sie, dass nicht alle im Team perfekt. Sie überprüfen Code, stellen Sie sicher, dass andere Test, Sie einander Quer überprüfen.

Sie starten die Notwendigkeit für einen Architekten zu sehen, dass die Kunden Wünsche verdauen können und sie in ein Design-Dokument übersetzen. Dies kann leicht einen Monat Zeit essen, bevor jemand anderes auch zu dem Projekt hinzugefügt wird (aber im Laufe der Entwicklungszeit können Monate oder sogar Jahre sparen!). Er sorgt dafür, dass alles, was Sinn macht und paßt zusammen recht gut.

Sie haben Design-Dokumente, UML basiert in der Regel so, dass verschiedene Teile des Teams Integrationspunkte verstehen. Sie erkennen, dass alles, was getan wurde, können Sie ohne die Menschen wieder tun müssen, die es taten, so dass Sie dokumentieren.

Ihr Qualitätsprozess wird viel strenger und sie beginnen Durchsetzung der Regeln, wie Sie nur in Veränderungen überprüfen, die bestimmte Fehler während des Tests befassen.

Testing, Refactoring, etc. ist offensichtlich Schlüssel und wird von Peer und Team Überprüfung erneut durchgesetzt werden.

Ich sage nicht, diese Art von Sachen immer notwendig ist, offensichtlich ist es nicht, aber in Ihrer Frage, Sie crufty Codebasen, und diese guten Praktiken sind oft die Lösung für dieses Problem diskutieren.

In der Regel werden diese bewährten Verfahren nach einem riesigen Projekt umgesetzt, das vollständig versagt, weil die Code-Basis so schlecht saugt. Dann feuern sie alle, die die Schuld nicht ausweichen können, einige Manager einstellen, die hoffentlich einige Erfahrung mit größeren Projekten haben und Neustart von Ground Zero (wenn sie nicht das Geld ausgeht).

Zumindest ist das meine Erfahrung. YMMV

Answer 12

Sie müssen nur die Praxis, gute Werkzeuge und die Fähigkeit und Bereitschaft, schlechte Gewohnheiten zu brechen und lernen.

Answer 13

Die Codierung ist ähnlich wie Handschrift. Jeder hat seinen eigenen unverwechselbaren Stil. Eine der größten Herausforderungen, die ich konfrontiert habe, während Legacy-Code beibehalten wird, wird versucht, herauszufinden, was los ist. Normalerweise kommt es auf Mangel an Kohärenz in der Codebasis.