Mein Projekt lässt mich viele Änderungen am Produktionscode vornehmen. Die Anforderung wird immer lauter und ich muss Änderungen vornehmen und so schnell wie möglich bereitstellen. Manchmal habe ich am Ende Patch-Art Code erstellt, weil einige der Anforderungen nicht in das Gesamtdesign der Software passen würden. Wie kann das effektiv gehandhabt werden? Irgendein Entwurfsmuster, um damit umzugehen?Wie wird häufig geänderter Produktionscode verwaltet?
Ich habe gesehen, dass dies oft passiert und es endet immer in Tränen. Das letzte Mal hat der Kunde Millionen von Dollar verloren, bevor er seinen Prozess verbessert hat.
Benutzer möchten immer, dass neue Anforderungen "so schnell wie möglich" zur Verfügung gestellt werden, aber sie verstehen nicht die Risiken, die Änderungen auf die gleiche Weise wie Sie zu machen. Sie sehen die Kosten von nicht mit der Funktion, aber sie erwarten nicht, was passieren würde und wie viel Geld würde verloren gehen, wenn die Änderung etwas bricht. (Ich möchte nicht vorschlagen, dass Sie kein guter Entwickler sind, nur dass es in jeder nicht-trivialen Software Fehler gibt und dass unkontrollierte Änderungen sie schneller aussetzen.)
Also, denke ich Sie müssen einen Schritt zurücktreten und versuchen, einen regelmäßigen Veröffentlichungsplan zu erstellen. Es wird Widerstand geben, aber Sie können auf diese Weise effektiver sein. Natürlich wird manchmal wird eine Änderung sein, die sofort vorgenommen werden muss, aber wenn es einen Zeitplan gibt, dann wird die Belastung auf den Benutzer zu rechtfertigen, warum die Unterbrechung des Release-Zyklus Sinn macht.
Oh, und wie alle anderen vermuten, benötigen Sie technische Infrastruktur wie ein Staging/Test-System, Ein-Klick-Freigabeverfahren, etc. (Siehe The Joel Test.)
Ich stimme völlig mit Ihnen Stephen Darlington, aber es gibt Zeiten, die unerwartete Situation treffen, wenn sie freigegeben werden, und sie müssen schnell behoben werden. Denken Sie über jedes Betriebssystem auf dem Markt nach. Sie folgen großen Releases, aber es wird immer eine Notwendigkeit für Hot-Fixes geben, weil es zu kritisch ist. –
@Robert Gould, ich bin mir nicht sicher, ob Sie seine ganze Post lesen, aber er sagt, dass es Zeiten gibt, wenn Sie sofort veröffentlichen müssen. "Natürlich gibt es manchmal eine Änderung, die sofort vorgenommen werden muss" – mmcdole
@Robert Es gibt absolut einen Platz für Hot-Fixes. Dies sollte jedoch die Ausnahme sein. Sie müssen eine bewusste Entscheidung treffen, um eine anzuwenden; Es sollte nicht die Standardoption sein. –
Das kann zu einfach eine Antwort sein, aber ich denke, dass Sie etwas Forschung auf agile software development tun sollten.
Testen, Sie benötigen ein solides Test-Framework, um sicherzustellen, dass Ihre Fixes nichts anderes kaputt machen.
Edit: Beantworten Sie die Frage des Kommentars.
Leider kann ich nicht an ein wirklich vernünftiges Muster/Lösung denken, um die Architektur intakt zu halten, zusätzlich Zeit zu nehmen, um die "Hacks" zu überarbeiten. Aber Sie haben wahrscheinlich wenig Zeit, seit Sie in der Produktion sind. So ist es nicht einfach ...
aber was noch wichtiger ist, wenn die Architektur wird immer verdorben, weil Sie wirklich brauchen, um „Hack“, um die Lösung in, könnte dies tatsächlich ein Zeichen dafür sein, dass der ursprüngliche Entwurf nicht, war die Begegnung der Produkt tatsächlichen Anforderungen, denn wenn es war, sollten Sie in der Lage sein, zu reparieren/Patch innerhalb der aktuellen Architektur der Architektur.
So versuchen, über die ganze Situation positiv zu sein, sollten Sie Ihre Fixes zur Kenntnis nehmen, und wie die aktuelle Architektur nicht hilft/Einhaltung, so dass Sie später die Straße hinunter, wenn die Hot-Fixes beginnen, sich niederzulassen, Sie haben Daten und Hinweise, um die Teile neu zu gestalten, die für die Konstruktion erforderlich sind, da Sie genau die Anforderungen haben, die Sie während der Produktion festgestellt haben.
Vielen Dank für diesen Vorschlag! Ich mache mir Sorgen um eine weitere Sache. Ich verwöhne eigentlich die ganze Architektur den Code regelmäßig zu modifizieren. Irgendwelche Vorschläge diesbezüglich? – Manoj
+1 Wenn die Veränderung die Architektur "durchbricht", dann war die Architektur normalerweise nicht richtig. Selten bricht die Architektur, weil die Veränderung eine äußerst schlechte Idee ist. –
Ja, ich denke, ich muss einen Blick auf die Architektur werfen Ich sollte die Fixes zur Kenntnis nehmen und versuchen, es auf den Weg zu bringen.Danke für den Vorschlag! – Manoj
Wie Robert Gould darauf hingewiesen hat, benötigen Sie wirklich eine Staging-Plattform, um zu überprüfen, ob Sie bei der Bereitstellung zu Lebzeiten nichts kaputt machen werden.
Ich bin in der glücklichen Position, wo mein Kopf fast immer freigebbar ist. Mindestens einmal pro Woche habe ich Code in HEAD, den ich als Entwickler gerne veröffentlichen würde. Das bedeutet nicht, dass jede Release-Version tatsächlich veröffentlicht wird, aber es könnte. In meiner Umgebung ist eine wöchentliche Version tatsächlich ziemlich praktisch und wird in der Regel erstellt ...
Unmittelbar vor dem Bereitstellen auf Staging, fördere ich meinen Code zu einem Release-Zweig. Ich verwende immer den gleichen Code für die Live-Wiedergabe, der zuvor beim Staging getestet wurde.
Alle dringenden Fixes können dann im Release-Zweig vorgenommen und vor dem Deployment auf Staging getestet werden. Wenn der Fix gut genug ist, kann ich ihn wieder in HEAD einfügen. Wenn es ein schrecklicher Hack war, kann ich es später in HEAD richtig implementieren.
Ich habe eine gute Suite von Entwicklertests, die automatisch bei jedem Check-in ausgeführt werden, die bestätigen, dass ich nichts Wichtiges gebrochen habe. Meine Anwendung führt bei jeder Bereitstellung auch interne Tests durch, was mich wieder zuversichtlich macht.
Eigentlich ist Glück weniger ein Faktor, als Sie vielleicht denken. Dies geschah nicht zufällig. Ich musste arbeiten, um es möglich zu machen. Ich musste mich dazu verpflichten, gute automatisierte Tests zu schreiben und zu pflegen, und einen Continuous Integration Server und eine Ein-Klick-Build-and-Deploy-Funktion zu bekommen.
Ich verbringe regelmäßig Zeit, meinen Code aufzuräumen, als Teil meiner normalen Entwicklungsaktivitäten. Dies hat zwei Vorteile. Erstens bedeutet das, dass meine Codebasis relativ sauber beginnt, daher ist die Architektur ziemlich flexibel. Zweitens bedeutet das, dass ich gut im Refactoring bin, da ich es die ganze Zeit mache. Damit meine ich Refactoring im Sinne einer Reihe von individuell kleinen Transformationen zu existierendem Code, anstatt im Sinne von "alles wegwerfen und wieder einführen" (was etwas gefährlicher ist).
Meiner Meinung nach ist diese "kontinuierliche Freisetzbarkeit" der größte Vorteil von Agile-Methoden.
zwei offensichtliche Tools sind Versionskontrolle und Tests. Versuchen Sie, das Release-System mit ihnen zu integrieren, damit Sie Ihre Änderungen bei jedem Schritt festschreiben können und wenn alle Tests bestanden sind (einschließlich derjenigen für die neuen Anforderungen), wählt das Release-System die "bekannte gute" Version aus, die die neue sein wird .
ich weiß nicht, über andere Systeme, aber monotone hat einige Haken speziell die Tests die Commits Tag zu machen, so gibt es einen Befehl „gib mir die letzte Version, die alle Tests bestanden“
Offensichtlich Test ist wichtig. Aber für mich ist Automatisierung noch viel mehr. Sie sollten das gesamte Projekt in weniger als drei Befehlen von der Quellcodeverwaltung auf den Produktionsserver bereitstellen können. Werkzeuge wie Maven, Ant, Capistrano, (fügen Sie hier Ihr Lieblingswerkzeug ein < ...>) kann Ihnen sehr helfen. Ein kontinuierliches Integrationssystem, das bei jeder Änderung der Quellcodeverwaltung automatisch auf einen Test- oder Integrationsserver verteilt wird, kann ebenfalls hilfreich sein.
ganze Automatisierung SETZEN wird Zeit das erste Mal, wenn Sie es tun, nehmen ...
Neben den offensichtlichen Antworten der Revisionskontrolle, Unit-Tests und ein automatisiertes Build-System, es klingt wie Sie auch benötigen Mach etwas Schweres refactoring. Wenn sich Ihr Design aufgrund sich ändernder Anforderungen ändert, sollten Sie versuchen, die Teile des Codes zu isolieren, die sich in ihren eigenen Modulen ändern.
Jeder hier hat ziemlich gute Dinge vorgeschlagen, wie Testen usw. Aber ich denke, ich sollte darauf hinweisen, dass Sie vielleicht die falsche Frage stellen.Sie fragen, ob es ein "Muster" gibt, das bei dieser Situation helfen kann. Ein Muster ist eine Entwurfswahl, um Designprobleme zu lösen. Was Sie im Wesentlichen haben, ist ein "Prozess" -Problem.
Ich würde fragen: „Welche Verfahren kann ich dies verhindern verwenden?“
Leider (und es ist das gleiche, wo ich arbeite) Entwurf ist ein Problem für Entwickler und Architekten, aber Prozess ist ein Thema für Führungskräfte. Und es braucht wirklich Führung, um gute Prozesse zu implementieren und dabei zu bleiben. Leider fehlt das oft.
Sie müssen Ihrem Anforderungsstau Disziplin auferlegen. Unter dem Risiko, alte Schule und Schrullen zu hören, sagen Sie den Leuten nein und dass sie mit Ihnen sitzen und die spezifischen Punkte von Schmerz und Anstrengung für drastische Designänderungen lernen müssen. Informieren Sie sich in Datenbanken über die Kardinalität und wie dies zu Herzschmerz führt. Werfen Sie Ihr Heu gegen den Käfig und bestehen Sie auf einen geplanten Veröffentlichungszyklus, in dem Sie jeden Dienstag nur in die Produktion einsteigen, aber erst nachdem die Benutzerakzeptanz stattgefunden hat. Brechen Sie jede Anfrage in Segmente von 2,4 und 8 Wochen und seien Sie starr, was Sie in diesen Zeitrahmen einschließen.
Es gibt viele Entwurfsmuster, die Ihnen helfen können, wenn Sie eine bestimmte Domäne von Problemen und deren Lösungen. Überprüfen Sie speziell die Command Pattern, die Strategy Pattern und Plug-in architecture, wie sie Ihnen helfen, Ihre Lösung einfacher zu erweitern. Wenn Sie .NET-Entwickler sind, werfen Sie einen Blick auf die Plug-in-Architektur von Miguel Castro, die er unter DNRTV überprüft hat.
Was hilft nicht, wenn die App gerade nicht auf eine kritische Weise funktioniert, und es bis Dienstag nach dem nächsten verlassen wird Millionen von Dollar kosten. –
Dies ist eine Prozess-Sache, keine Design-Sache.
Das erste, was Sie tun müssen, ist Ihre Benutzer zu erziehen, damit sie eine Vorstellung von den Kosten der wechselnden Anforderungen haben. Dies soll sie nicht daran hindern, sie zu ändern, sondern sie so schnell wie möglich zu ändern und die Implementierung so schnell wie möglich zu fordern. (Ich gehe davon aus, dass dies eine geschäftliche Angelegenheit ist. In diesem Fall ist es Ihre Aufgabe, das zu tun, was das Unternehmen nach besten Kräften benötigt, und die Leute wissen zu lassen, was das Beste aus Ihrer Fähigkeit ist und welche Funktionalitätskosten im Gesamtplan von Dinge.)
Die zweite Sache ist, einen zwei-fix Prozess für schnelle Korrekturen zu etablieren. Zuerst wird der Patch installiert, damit die App mehr oder weniger zufriedenstellend läuft. Dann brauchen Sie etwas Zeit und finden die richtige Lösung. Dies kann auch eine Benutzerschulung erfordern, und Sie können die Idee der "technischen Schulden" nützlich finden, dies zu erklären.
Die dritte Sache ist, um sicherzustellen, dass Sie die Ressourcen haben. Wenn Sie mit Änderungen der Anforderungen nicht Schritt halten können, brauchen Sie Hilfe und Sie müssen zeigen, warum. Wenn die Mächte beschließen, nicht mehr Leute einzubringen, und sie verstehen, dass das Ausmaß der Modifikation begrenzt, das ist auch gut.
Nun kann es passieren, dass Ihre Benutzer nicht erreichbar sind, dass Sie die Leute nicht davon überzeugen können, dass schnelle Lösungen auf lange Sicht sehr teuer sind, und so weiter. In diesem Fall empfehle ich das vierte: poliere deinen Lebenslauf und suche nach einem neuen Job. Im Moment sieht es so aus, als ob Sie zum Scheitern verurteilt sind, und das ist ein sehr schlechter Ort. Wie das alte Sprichwort sagt, ändern Sie Ihren Job oder ändern Sie Ihren Job.
Häufig geänderter Produktionscode?!?! LIEBE GOTT, NOOOOOOO! –
Keine andere Option :(! – Manoj
Es gibt immer andere Optionen ... – Ilya