Mein Projekt veranlasst mich, viele Änderungen am Produktionscode vorzunehmen. 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?
Ich habe das schon oft gesehen 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" verfügbar gemacht 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 kaputt macht. (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 aufdecken können.)
Also, ich denke, Sie müssen einen Schritt zurück machen 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 liegt es an dem Benutzer, zu begründen, warum das Brechen des Release-Zyklus sinnvoll ist.
Oh, und wie alle anderen vermuten, benötigen Sie technische Infrastruktur wie ein Staging / Testsystem, Ein-Klick-Freigabeverfahren usw. (Siehe Der Joel-Test .)
Testing, Sie brauchen ein solides Testframework, um sicherzustellen, dass Ihre Fixes nichts anderes kaputt machen.
Bearbeiten: Beantworten Sie die Frage des Kommentars.
Leider kann ich nicht an ein wirklich vernünftiges Muster / eine echte Lösung denken, um die Architektur intakt zu halten, abgesehen von der Zeit, die "Hacks" zu überarbeiten. Aber Sie haben wahrscheinlich wenig Zeit, seit Sie in der Produktion sind. So ist es nicht einfach ...
Wichtiger jedoch, wenn die Architektur verdorben wird, weil Sie die Lösung wirklich "hacken" müssen, könnte dies ein Zeichen dafür sein, dass das ursprüngliche Design nicht den Anforderungen des Produkts entspricht tatsächliche Anforderungen , denn wenn dies der Fall ist, sollten Sie in der Lage sein, das aktuelle Framework zu reparieren.
Wenn Sie also versuchen, die ganze Situation positiv zu sehen, sollten Sie Ihre Fixes zur Kenntnis nehmen, und wie die aktuelle Architektur nicht hilft / sich anpasst, so können Sie später die Straße runter, wenn sich die Hotfixes einstellen, haben Daten und Hinweise zur Neugestaltung aller Teile der Architektur erfordern Design, da Sie genau die Anforderungen haben, die Sie während der Produktion festgestellt haben.
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: "Mit welchem Prozess kann ich das verhindern?"
Leider (und es ist dasselbe, wo ich arbeite) ist Design ein Problem für Entwickler und Architekten, aber Prozess ist ein Problem für Manager. Und es braucht wirklich Führung, um gute Prozesse zu implementieren und dabei zu bleiben. Leider fehlt das oft.
Das ist vielleicht zu einfach für eine Antwort, aber ich denke, Sie sollten etwas über agile Softwareentwicklung .
Ich bin in der glücklichen Lage, 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 Veröffentlichung tatsächlich ziemlich praktisch und wird normalerweise gemacht ...
Unmittelbar vor der Bereitstellung für die Bereitstellung stufe ich meinen Code für einen Release-Zweig hoch. Ich lege immer den gleichen Code zum Leben bereit, der zuvor beim Staging getestet wurde.
Dringende Korrekturen 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 wieder richtig implementieren.
Ich habe eine gute Suite von Entwicklertests, die bei jedem Check-in automatisch ausgeführt werden und 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 warten und einen Continuous Integration Server und eine Ein-Klick-Build-and-Deploy-Funktion zu erhalten.
Im Rahmen meiner normalen Entwicklungsaktivitäten verbringe ich regelmäßig Zeit mit der Bereinigung meines Codes. 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 ständig mache. Ich meine damit Refactoring im Sinne einer Reihe von individuell kleinen Transformationen zu existierendem Code, anstatt im Sinne von "alles wegwerfen und wieder umsetzen" (was etwas gefährlicher ist).
>Meiner Meinung nach ist diese "kontinuierliche Freisetzbarkeit" der größte Vorteil agiler Methoden.
Neben den offensichtlichen Antworten auf Revisionskontrolle, Komponententests und ein automatisiertes Build-System klingt es auch so, als müssten Sie einige schwere Aufgaben erledigen. Refactoring . Wenn sich Ihr Design aufgrund sich ändernder Anforderungen ständig ändert, sollten Sie versuchen, die Teile des Codes, die sich in ihren eigenen Modulen ändern, zu isolieren.
Sie müssen Disziplin bei Ihrem Anforderungsstau aufbringen. 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 streng darüber, was Sie in diesen Zeitrahmen einschließen.
Es gibt viele Entwurfsmuster, die Ihnen helfen können, wenn Sie eine definierte Domäne mit Problemen und deren Lösungen haben. Überprüfen Sie speziell das Befehlsmuster , das Strategy Pattern und Plug-in-Architektur , so wie sie wird Ihnen helfen, Ihre Lösung einfacher zu erweitern. Wenn Sie ein .Net-Entwickler sind, werfen Sie einen Blick auf die Plugin-Architektur von Migeul Castro, die er auf DNRTV überprüft hat. p>
Es gibt mehrere Projektlebenszyklen, gegen die Sie Ihren Ansatz strukturieren können. Diese Seite listet ein paar auf (es klingt, als würden Sie den "Code-And-Fix" verwenden!) , aber das ist keine definitive Liste, eine größere Liste finden Sie hier .
zwei offensichtliche Werkzeuge sind Versionskontrolle und Testen. Versuchen Sie, das Release-System mit ihnen zu integrieren, damit Sie Ihre Änderungen bei jedem Schritt festschreiben können. Wenn alle Tests bestanden sind (einschließlich derjenigen für die neuen Anforderungen), wählt das Release-System die "bekannt gute" Version aus .
ich weiß nicht über andere Systeme, aber monotone hat einige Hooks speziell, um die Tests taggen die Commits, so gibt es einen Befehl, "mir die letzte Version zu geben, die alle Tests besteht"
Natürlich ist Testen wichtig. Aber für mich ist Automatisierung noch viel mehr. Sie sollten in der Lage sein, das gesamte Projekt in weniger als 3 Befehlen von der Quellcodeverwaltung auf den Produktionsserver zu verteilen. Werkzeuge wie Maven , Ant , Capistrano , (fügen Sie hier Ihr Lieblingswerkzeug ein & lt; ... & gt;) kann Ihnen sehr helfen. Ein kontinuierliches Integrationssystem, das bei jeder Änderung der Quellcodeverwaltung automatisch auf einem Test- oder Integrationsserver bereitgestellt wird, kann ebenfalls hilfreich sein.
Wenn Sie all diese Automatisierung an Ort und Stelle setzen, brauchen Sie beim ersten Mal Zeit ...
Dies ist eine Prozess-Sache, keine Design-Sache.
Als erstes müssen Sie Ihre Benutzer schulen, damit sie eine Vorstellung von den Kosten für die Änderung der Anforderungen haben. Dies soll sie nicht davon abhalten, sie zu ändern, sondern sie so schnell wie möglich zu ändern und die Implementierung so schnell wie möglich zu beantragen, es sei denn, es besteht ein eindeutiger Geschäftsbedarf. (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 Ihre Fähigkeiten am besten sind und welche Kosten in der Gesamtlösung anfallen Dinge.)
Die zweite Sache ist, einen Zwei-Fix-Prozess für schnelle Fixes einzurichten. 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 einige Benutzerschulungen erfordern, und Sie können die Idee von "technischen Schulden" nützlich finden, dies zu erklären.
Die dritte Sache ist, 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, ist das auch gut.
Nun kann es passieren, dass Ihre Benutzer nicht erreichbar sind, dass Sie die Leute nicht davon überzeugen können, dass Schnellkorrekturen 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.
Tags und Links design-patterns project-management version-control