Verbessern Sie Ihr Softwareprojekt - Teil zwei: Änderungen vornehmen

Haben Sie schon einmal eine Codebasis übernommen und festgestellt, dass Sie mit der Art, wie der Code geschrieben oder organisiert ist, nicht zufrieden sind? Das kommt häufig vor, kann aber eine Menge Kopfschmerzen verursachen. Technische Schulden können zu einem Schneeballsystem werden, das es exponentiell schwieriger macht, den Code zu verstehen und neue Funktionen hinzuzufügen.

In dieser dreiteiligen Serie gehe ich auf einige der wichtigsten Dinge ein, die Sie tun sollten, um mit Ihrem glänzenden (alten) Projekt zufriedener zu werden. Anhand einiger konkreter Beispiele werde ich erläutern, wie ich das Open-Source Vonage Python SDKeine Bibliothek, die HTTP-Aufrufe zu Vonage-APIs macht, aber die Prinzipien gelten für jede Art von Softwareprojekt.

Die Beispiele in diesem Beitrag werden in Python geschrieben, aber diese Prinzipien gelten für Projekte in jeder Sprache. Außerdem gibt es eine praktische Checkliste, die Sie befolgen können wenn Sie speziell versuchen, ein Python-Projekt zu reparieren.

Die Serie, in Abschnitten

1. Teil Eins: Verstehen einer Codebasis

2. Zweiter Teil: Änderungen vornehmen (dieser Artikel)

3. Dritter Teil: Erweiterungen der nächsten Stufe

Was wird im zweiten Teil behandelt?

Im zweiten Teil werden wir darüber sprechen:

• Selbstvertrauen in die Durchführung von Änderungen und die Behebung technischer Mängel

• Vertrauen bei Ihrem Chef, Ihrem Team und Ihren Nutzern aufbauen

Am Ende dieses Artikels werden Sie bereit sein, die Dinge in Ihrem Projekt zum Besseren zu wenden und gleichzeitig die betroffenen Personen zufrieden zu stellen.

Fangen wir an!

Fixierung der Struktur

Wenn Sie gefolgt sind Teil eins dieser Serie verfolgt haben, haben Sie bereits ein gutes Verständnis für das Projekt, das Sie jetzt besitzen, und wissen, wie die Codebasis (und die Tests, wenn Sie das Glück haben, sie zu haben) strukturiert ist und welchem Zweck diese Struktur dient. Jetzt ist ein guter Zeitpunkt, um über die Gesamtarchitektur nachzudenken und damit zu beginnen, das Projekt logischer zu strukturieren, wenn Sie denken, dass es verbessert werden könnte.

Ein konkretes Beispiel

Das Projekt, das ich als Beispiel verwende, ist das Vonage Python SDKdas es einem Benutzer ermöglicht, viele verschiedene Vonage-APIs aufzurufen. In meinem Fall sah die Makrostruktur meines Projekts wie folgt aus:

Aus der obigen Abbildung können Sie ersehen, dass der Code in sechs Hauptmodule (einzelne Dateien, ja, Python ist sehr kompakt!) aufgeteilt wurde:

• Ein __init__ Modul, in der Regel eine Minimaldatei, die für die Verpackung des Codes verwendet wird

• Ein _internal Modul, das interne Methoden enthält (und aus irgendeinem Grund auch eine der von uns unterstützten APIs)

• sms, voice und verify Module, die jeweils Code zum Aufrufen einer einzelnen API enthalten

• Ein errors Modul, das alle benutzerdefinierten Fehler enthält

Meine erste Frage, als ich mir das ansah, war: Wo sind die anderen APIs? Als ich zu Vonage kam, unterstützte das SDK 12 verschiedene APIs (seitdem haben wir weitere hinzugefügt!), aber es gab nur 3 Module, die sich auf diese APIs bezogen.

Es stellte sich heraus, dass sich etwa 90 % des Codes in der Datei __init__.py Datei befand, einschließlich der Implementierungen vieler APIs, veralteter Methoden, der Logik für Aufgaben wie die JWT-Generierung, der Basis-API-Anforderungen und anderer optionaler Einstellungen... viel zu viel für eine Datei, die sehr minimal sein sollte. Ich beschloss, die Datei zu refaktorisieren, indem ich eine Client Klasse zu erstellen, die sich mit der Kernlogik befasst, und dann Klassen, die nach APIs benannt sind (mit einer kleinen Menge logischer Gruppierung).

Am Ende hatten wir eine Struktur, die wie folgt aussah:

Dies selbst zu tun

Betrachten Sie die Struktur Ihres Projekts. Fragen Sie sich: Kann ich das besser machen? Gruppieren Sie ähnliche Funktionen in Module, die klein genug sind, um sie leicht zu verstehen, aber nicht kleiner - Sie wollen immer noch in der Lage sein, das Gesamtbild dessen zu sehen, was das Projekt tut.

Ich würde auch empfehlen, Klassen zu erstellen, die ähnliche Methoden enthalten, sowie benutzerdefinierte Fehler für jede Klasse, um sich selbst und Ihren Benutzern mehr Einblick zu geben, was falsch ist, wenn etwas nicht funktioniert.

Zweigstellen

Wenn Sie ein neues Projekt beginnen, wird es wahrscheinlich nicht in einem "abgeschlossenen" Zustand belassen worden sein. Software-Projekte sind immer in Arbeit, und die ständigen iterativen Verbesserungen sind ein wichtiger Grund, warum wir Versionskontrolle verwenden. In dieser Situation werden Sie vielleicht feststellen, dass es in Ihrem Versionskontrollsystem Zweige gibt, die Funktionen, Verbesserungen oder Fehlerbehebungen enthalten.

Die ideale Situation sieht in vielen Fällen so aus: ein einziger Hauptzweig, mit Funktionen, die auf sekundären Funktionszweigen entwickelt werden und dann wieder in den Hauptzweig zusammengeführt werden.

Bei einigen Projekten kann es sinnvoll sein, einen länger laufenden Beta-Zweig zu haben, wenn es eine Beta-Funktion gibt, die Sie testen und von Ihrer Haupt-Codebasis getrennt halten wollen. Im Vonage Python SDK haben wir derzeit einen Beta-Zweig mit Code, der unsere Vonage Video API aufruft, die sich in der Beta-Phase befindet. Wir wollen diesen Zweig nicht zusammenführen, da die API, die er aufruft, noch nicht offiziell freigegeben ist. In diesem Fall könnte Ihre Zweigstruktur eher wie folgt aussehen:

Wenn Sie Funktionen separat entwickeln müssen, kann es sinnvoll sein, den Beta-Zweig regelmäßig zu rebasen, um die Änderungen aus dem Hauptzweig zu übernehmen - so mache ich es mit dem Vonage Python SDK.

Das sind die "guten" Fälle. Aber wenn Sie ein Projekt haben, könnte es eher so aussehen:

D.h. viel zu viele Zweige und ein Mangel an Konsistenz. Normalerweise enden die Dinge so, wenn mehrere Entwickler gleichzeitig an vielen Funktionen gearbeitet haben, obwohl es auch der Fall sein könnte, dass ein früherer Ingenieur neue Zweige benutzt hat, um verschiedene Aufgaben zu planen und neue Dinge auszuprobieren, aber nie dazu gekommen ist, sie zu beenden.

In dieser Situation können diese Zweige einen guten Einblick in die Art und Weise geben, wie der vorherige Projekteigentümer das Projekt gehandhabt hat, sowie eine Quelle der Inspiration sein - einige der Funktionen oder Korrekturen könnten gut genug sein, um sie selbst zu implementieren. Sobald Sie jedoch verstehen, was ein zusätzlicher Zweig enthält, ist es in der Regel eine gute Idee, ihn zu schließen - das Ziel ist es, sich selbst so viel Freiraum wie möglich zu verschaffen, um Ihre Ideen umzusetzen.

Chestertons Zaun - Verstehen Sie, was Sie beseitigen!

Jetzt scheint ein guter Zeitpunkt zu sein, um alle (mich eingeschlossen) zu erinnern an Chesterton's Zaun - den Aphorismus, der besagt, dass man nichts entfernen sollte, ohne zu verstehen, warum es überhaupt dort platziert wurde. Bemühen Sie sich, den Zweck eines Zweigs oder eines Teils des Codes zu verstehen, bevor Sie ihn entfernen! Das Wichtigste: Entfernen Sie nicht etwas, nur weil Sie nicht wissen, warum es da ist, sondern versuchen Sie zuerst zu verstehen.

Die Auswahl der richtigen Abhängigkeiten

Fast jedes Softwareprojekt hängt vom Code anderer Leute ab. Das Schöne an Open Source ist, dass viele Probleme und Herausforderungen bereits gelöst wurden, bevor Ihr Code aufkam, und zwar von sehr klugen Leuten, die bereit sind, ihre Arbeit mit Ihnen zu teilen. Es ist jedoch wichtig, die Abhängigkeiten Ihres Codes zu verstehen, wofür sie verwendet werden und ob sie die besten Werkzeuge für die Aufgabe sind.

Eine Abhängigkeit, die in der Vergangenheit geeignet war, kann im Laufe der Zeit auch weniger geeignet werden, was uns zu der Frage führt:

Was macht eine gute Abhängigkeit aus?

Wenn Sie sich entscheiden, eine Abhängigkeit beizubehalten (oder zu ersetzen), soll Ihnen dieser Abschnitt dabei helfen, zu beurteilen, ob es sich lohnt, eine Abhängigkeit zu verwenden.

Beachten Sie zunächst die Lizenz. Stellen Sie sicher, dass Sie die Abhängigkeit für Ihr Projekt verwenden dürfen. Wenn Sie das nicht dürfen, ist das ein Nein. Wenn Sie nicht sicher sind, wovon ich spreche, wenn ich das sage, dieser Artikel von Snyk erklären, worauf Sie bei der Bewertung der Lizenz einer Abhängigkeit achten sollten.

Wird die Abhängigkeit aktiv gepflegt? Sie können die Commit-Historie von Open-Source-Projekten einsehen. Einige sind so einfach, dass sie nur sehr wenig Wartung benötigen, und das ist auch gut so. Komplexere Projekte sollten aktiv gewartet werden, d.h. es sollte häufige Commits geben, und Issues und PRs sollten nicht für lange Zeit ignoriert werden. Das ist wichtig, da Sie möchten, dass die Abhängigkeit neue Sprachversionen unterstützt und mit neuen Funktionen und anderen Abhängigkeiten, die Sie verwenden, gut zusammenspielt.

Es lohnt sich, die Popularität der Abhängigkeit zu berücksichtigen. Alle Abhängigkeiten können Sicherheitslücken aufweisen, und bei einer weit verbreiteten Abhängigkeit ist es wahrscheinlicher, dass diese Schwachstellen von automatisierten Tools, Sicherheitsforschern und anderen Benutzern erkannt werden. Die Wahl einer weit verbreiteten Option bedeutet auch, dass eine größere Anzahl von Personen in der Lage sein wird, Fragen zu beantworten, wenn Sie nicht weiterkommen!

Schließlich sollten Sie auch die unterstützenden Elemente berücksichtigen - ist die Dokumentation klar? Gibt es zuverlässige Beispiele im Internet, die diese Abhängigkeit verwenden? Diese Dinge können Ihnen helfen, schnell mit der Arbeit zu beginnen oder Probleme zu beheben, sie sind also eine Überlegung wert.

Sie haben also den perfekten Satz von Abhängigkeiten gefunden? Gute Nachrichten... vorerst. Eine gut gewartete Bibliothek, die Ihren Bedürfnissen entspricht, bleibt vielleicht nicht so - die Betreuer könnten das Projekt aufgeben oder Ihre Anforderungen könnten sich ändern, so dass sie nicht mehr geeignet ist. Der beste Ratschlag, den ich hier habe, ist: Qualifizieren Sie Ihre Abhängigkeiten im Laufe der Zeit weiter! Stellen Sie sicher, dass sie immer noch Ihren Anforderungen entsprechen. Und man kann nie wissen, ob nicht eine neue Bibliothek auftaucht, die in Zukunft noch besser zu Ihren Bedürfnissen passt.

Testen von Code, den Sie nicht besitzen

Wenn Ihr Projekt mit anderem Code kommunizieren muss, stellt sich das heikle Problem, wie Sie die Funktionalität Ihres Codes testen können. In unserem Beispiel besteht die Hauptaufgabe des Python-SDK von Vonage darin, viele verschiedene APIs aufzurufen. Wir haben keine Kontrolle über die APIs selbst oder darüber, wie sie sich verhalten.

Ein Beispiel hierfür ist die Verwendung des SDK zum Aufrufen der SMS API von Vonage aufrufen. Hier kann vieles passieren, je nach Ihren genauen Bedürfnissen, aber ich werde ein konkretes Beispiel nennen. Das Senden einer SMS mit dem Python-SDK ist ein recht einfacher Vorgang:

import vonage

client = vonage.Client(key="API_KEY", secret="API_SECRET")
client.sms.send_message(
    {
        "from": "SENDER_NAME"
        "to": "RECIPIENT_PHONE_NUMBER",
        "text": "A text message sent using the Vonage SMS API",
    }
)

Aber nachdem Sie diesen Code ausgeführt haben, passieren eine Menge Dinge. Hier ist eine (sehr) vereinfachte Version:

1. Das SDK sendet eine Anfrage an einen Vonage-Server

2. Der Server analysiert die Anfrage und sendet eine Antwort an das SDK zurück.

3. Wenn die Anfrage OK war, sendet der Server eine SMS an die Telefonnummer des Empfängers

4. Statusinformationen (z.B. Empfangsbestätigung) werden an den Vonage Server zurückgesendet

5. Optional werden diese Informationen von einem Vonage-Server an einen vom Benutzer angegebenen Webhook gesendet, so dass der Benutzer sehen kann, ob die SMS erfolgreich zugestellt wurde.

In dieser Situation führt die Ausführung unseres Codes dazu, dass eine ganze Menge anderer Code ausgeführt wird. Wir können diesen anderen Code nicht über das SDK testen, also müssen wir beim Schreiben unserer Tests eine Annahme treffen: Wenn wir die richtigen Informationen senden, werden die richtigen Dinge passieren und wir erhalten die richtigen Antworten zurück.

In unserem Beispiel ist der einzige Teil des Codes, den wir testen können, dieser:

Die einzigen Fragen, nach denen unser Code bewertet werden kann, sind also: 1. Sind die von uns gesendeten Anfragen wohlgeformt, und 2. werden die Antworten angemessen behandelt?

Zusammenfassend lässt sich sagen, dass Sie Ihre Tests darauf beschränken sollten, zu testen, wie Ihr Code Daten sendet und empfängt, und davon ausgehen sollten, dass die andere Software ihre Aufgabe korrekt erfüllt und Erfolgs- und Fehlerantworten sendet, die Ihr Code verarbeiten kann. Ziehen Sie beim Testen in Betracht, API-Anforderungen zu erfassen und gespielte Antworten in der richtigen Form für die Anforderung zurückzugeben, damit Ihr Code diese gespielten Daten bei der Ausführung Ihrer Tests nutzen und verarbeiten kann, ohne die externen Dienste, die Sie nicht kontrollieren können, tatsächlich aufzurufen.

Denken Sie daran, dass Ihre Tests beweisen, dass Ihr Code den Spezifikationen Ihrer Testsuite entspricht, nicht unbedingt dem tatsächlichen API-Verhalten. Wenn Sie eine neue Funktion hinzufügen, ist es eine gute Idee, eine Demo-Anwendung zu erstellen, die Ihren Code tatsächlich für Live-Anfragen verwendet und nicht nur Ihre Tests ausführt (auf diese Weise erhalten Sie auch eine großartige Antwort, die Sie für zukünftige Tests zwischenspeichern können).

Erstellen Ihrer ersten Veröffentlichung

Sie haben also die Codebasis aufgeräumt, einige Umstrukturierungen vorgenommen, Ihre Tests verbessert und vielleicht sogar neue Funktionen zu Ihrem Projekt hinzugefügt. Zeit für eine neue Version!

Bei diesem Prozess geht es vor allem darum, Vertrauen aufzubauen - Ihre Benutzer und Ihr Team sollen wissen, dass Sie wissen, was Sie tun. Ziel ist es, Ihren Nutzern zu zeigen, dass sie Ihren Änderungen vertrauen können und dass die Aktualisierung keine Teile ihres Arbeitsablaufs ohne ihr Wissen verändern wird. Transparenz ist hier das A und O - Sie wollen Ihren Nutzern keine versteckten Überraschungen bieten.

Semantische Versionierung verwenden

Die wichtigste Empfehlung wäre folgende: Verwenden Sie semantische Versionierung! Bei der semantischen Versionierung folgen Sie einer x.y.z-Struktur für Ihre Numbers, wobei:

• x ist die Hauptversion, die Sie erhöhen sollten, wenn Sie wichtige Änderungen vornehmen,

• y ist die Minor-Version, die Sie erhöhen sollten, wenn Sie abwärtskompatible Funktionen hinzufügen, und

• z ist die Patch-Version, die Sie erhöhen sollten, wenn Sie eine Fehlerbehebung, eine Aktualisierung der Abhängigkeiten usw. vornehmen, und zwar in einer rückwärtskompatiblen Weise.

Um ein praktisches Beispiel zu geben: Beim Hinzufügen der Unterstützung für die Vonage Messages API hinzuzufügen (aber nichts zu ändern, was die neue Version abwärtskompatibel machen würde), habe ich eine kleinere Version von v2.7.0 -> v2.8.0. Als ich einige veraltete Methoden entfernen und die Art und Weise, wie Objekte im SDK instanziiert werden, ändern wollte, war mir klar, dass dies zu einem Bruch mit der bestehenden Funktionalität führen würde, also habe ich eine Hauptversion erstellt, v2.8.0 -> v3.0.0. Als ich einen Fehler im neuen Code fand, habe ich ihn behoben und das SDK mit einer Patch-Version aktualisiert, v3.0.0 -> v3.0.1. Wenn man diese Regeln befolgt, weiß der Benutzer genau, was er zu erwarten hat, wenn er auf die neueste Version aktualisiert. Wenn Sie eine Hauptversion herausgeben, wissen sie, dass sie eine bahnbrechende Änderung erwarten können!

Ergänzende Materialien aktualisieren

Bei jeder neuen Version sollten Sie das Änderungsprotokoll aktualisieren, damit die Benutzer wissen, was sie erwartet. Es ist oft der erste Ort, an dem ein Benutzer nachschaut, da es typischerweise alle Unterschiede in der neuen Version aufführt und ihm bei der Entscheidung helfen kann, ob er aktualisieren sollte. Wenn Sie das Änderungsprotokoll nicht aktualisieren, wissen die Benutzer nicht, was sie von einer neuen Version zu erwarten haben, und werden folglich sehr viel misstrauischer sein.

Wenn Sie eine neue Version veröffentlichen, sollten Sie auch die Dokumentation, die READMEs und die Codebeispiele auf dem neuesten Stand halten. Wenn Sie dies nicht tun, werden Ihre Benutzer nicht unbedingt wissen, wie sie all Ihre großartigen neuen Funktionen nutzen können, und wenn Sie eine bahnbrechende Änderung vorgenommen haben, funktionieren Ihre Dokumente und Codebeispiele möglicherweise nicht mehr.

Denken Sie daran, dass Transparenz der Schlüssel ist - seien Sie vorhersehbar, damit die langjährigen Nutzer des Projekts darauf vertrauen können, dass der Code, auf den sie sich verlassen, in sicheren Händen ist, und neue Nutzer lernen können, wie sie Ihre Software nutzen können.

Lockerung der Abschreibungsregeln

Wenn Sie anfangen, Code zu ändern, werden Sie wahrscheinlich einen Großteil davon umstrukturieren/refaktorieren wollen. Solange sich dadurch nicht ändert, wie ein Benutzer den Code aufruft, können Sie dies nach Herzenslust tun. Wenn Sie jedoch die Art und Weise, wie etwas aufgerufen wird, ändern wollen, müssen Sie die alte Methode verwerfen und die neue in einer kleineren Version hinzufügen, und die alte in einer späteren Hauptversion entfernen.

Ich werde hier ein konkretes Beispiel nennen. Im Vonage Python SDK wollte ich ändern, wie die get_standard_number_insight Methode von einem Benutzer aufgerufen wurde. Ursprünglich war dies eine Methode, die mit der Client Klasse. Ich wollte die Struktur ändern, indem ich eine NumberInsight Klasse, die diese Methode enthielt, die von der Client Klasse instanziiert und verwendet. Auf diese Weise würde der Aufruf der Number Insight API auf die gleiche Art und Weise aufzurufen, wie ein Benutzer SMS-Nachrichten senden oder Sprachanrufe tätigen würde.

Zuerst habe ich eine NumberInsight Klasse und fügte ihr eine Version der get_standard_number_insight Methode hinzu.

Als nächstes habe ich die Methode in der Client Klasse. In Python kann dies durch Hinzufügen eines Dekorators geschehen, der dem Benutzer eine Warnung über die Verwerfung ausgibt, wenn er die Methode verwendet.

Danach habe ich die Codeschnipsel und Dokumente aktualisiert, um die Änderung zu berücksichtigen.

Jetzt war ich in der Lage, eine kleinere Version zu veröffentlichen. Nach einer Veröffentlichung, bei der Funktionen veraltet sind, ist es eine gute Praxis, die veralteten Teile für eine Weile in Ruhe zu lassen, bevor man sie entfernt, um den Leuten genügend Zeit zu geben, sich umzustellen. Ich würde vorschlagen, die veraltete Funktionalität für mindestens eine Version oder einen Monat - je nachdem was länger ist - zu belassen. Auch hier geht es darum, Vertrauen zu schaffen.

Ich habe diesen alten Code einige Monate lang beibehalten und dann eine größere Version herausgebracht, in der ich die alten Aufrufmethoden entfernt habe. Da ich methodisch vorging und meine Absichten transparent darlegte, wussten meine Benutzer, was sie zu erwarten hatten, wenn sie auf die neueste Version aktualisierten.

Gleichgewicht zwischen Verbesserungen und neuen Arbeiten

Der letzte Punkt, den Sie bedenken sollten, wenn Sie mit der Arbeit an einer alten Codebasis beginnen, ist, dass Sie wahrscheinlich nicht unendlich viel Zeit haben werden, um den Code so zu polieren, wie Sie ihn mögen, bevor Sie neue Funktionen hinzufügen, Fehler beheben usw. müssen. Sie werden wahrscheinlich mit anderen Prioritäten jonglieren müssen, z. B. mit Fristen für die Hinzufügung neuer Funktionen, während Sie gleichzeitig versuchen, große Änderungen am alten Code vorzunehmen.

In diesem Fall müssen Sie in der Lage sein, für sich und Ihre Arbeit einzustehen. Machen Sie deutlich, dass Sie einen Teil Ihrer Zeit für die Verbesserung der bestehenden Codebasis aufwenden müssen, was bedeutet, dass Sie nicht so schnell neue Funktionen entwickeln werden, wie Ihr Chef es vielleicht gerne hätte. Betonen Sie, dass die Zeit, die Sie jetzt für das Refactoring aufwenden, Ihnen helfen wird, die Codebasis zu verstehen, und sich später auszahlen wird, da sie viel einfacher zu warten sein wird.

Letztendlich sollte Ihre Arbeit an einem Legacy-Projekt das Benutzererlebnis und die langfristige Benutzerfreundlichkeit und Wartungsfreundlichkeit verbessern. Sie werden vielleicht nicht sofort für den Umgang mit technischen Schulden gelobt, da die Arbeit für Ihre Benutzer oder Ihr Team nicht sofort sichtbar ist, aber die Verwaltung technischer Schulden kann verhindern, dass die Dinge später für alle viel schlimmer werden - diese Arbeit ist es wirklich wert!

Was mir bei diesem Prozess sehr geholfen hat, war die Erstellung von Arbeitstickets für Entdeckungen und Lernen, um zu zeigen, dass ich in die zukünftige Effizienz investiere. Ich habe auch Tickets für technische Schulden erstellt, um meinem Team neben den Tickets für die Entwicklung neuer Funktionen einen Einblick in meine Arbeit zu geben. Dieser Ansatz half mir, in meinem Unternehmen Vertrauen aufzubauen und den Leuten zu zeigen, wie ich meine Zeit verbringe, und ich kann ihn nicht genug empfehlen.

Was kommt als Nächstes?

Wenn Sie die Vorschläge in diesem Artikel befolgt haben, wird Ihr Projekt schon viel besser aussehen! Die Veröffentlichungen, die Sie vornehmen, legen den Grundstein für all die großartigen Dinge, die Sie mit Ihrem Projekt erreichen wollen.

Klicken Sie hier, um Teil 3 der Serie zu lesenin dem ich erkläre, wie Sie Ihr Projekt auf die nächste Stufe heben können. Wir werden über Verbesserungen sprechen, die Ihren Benutzern zugute kommen, sowie über Dinge, die die Arbeit mit der Codebasis erleichtern. Zum Schluss werden wir die besten Praktiken für die Übergabe eines Projekts erklären.

Haben Sie eine Frage oder möchten Sie uns Ihre Gedanken mitteilen? Sie können sich mit uns auf unserem Vonage Community Slack oder senden Sie uns eine Nachricht auf Twitter.