Sicherlich waren Sie alle in verschiedenen Phasen Ihrer Karriere mit einem solchen Problem konfrontiert: Sie haben die Aufgabe gesehen, sie scheint einfach zu sein und die Anforderungen sind klar, und dann stellt sich heraus, dass es notwendig war, sie anders umzusetzen. Die Zeit für die Implementierung wurde aufgewendet, und die Frist läuft bereits ab, und die Aufgabe ist tatsächlich noch nicht fertig. Wir müssen im laufenden Betrieb umschreiben, wahrscheinlich unter Verstoß gegen die Frist. Arbeitsstunden gehen verloren und kosten Geld. Wenn dieses Problem nicht für einen Entwickler, sondern für das gesamte Unternehmen auftritt, steigen die überfälligen Aufgaben, die Entwicklungskosten, das Unternehmen kann die Strategie nicht umsetzen und das Unternehmen erleidet Verluste.
Was ist das Problem?
Dieses Problem entsteht durch unzureichendes Eintauchen in die Aufgabe. Es kann viele Gründe geben, hier einige davon:
- Mangel an aktueller Dokumentation;
- Missverständnis des Geschäftsprozesses;
- Die Ausarbeitung der Anforderungen ist nicht vollständig.
- der menschliche Faktor (die Wissensquelle und der Darsteller sprechen über dasselbe, aber sie verstehen es anders);
- persönliche Nachlässigkeit von Darstellern und Kunden;
- und andere (jeder trat auf seine Weise auf den Rechen).
Aufgrund des unzureichenden Eintauchens in die Aufgabe tun die Entwickler das Falsche oder nicht in vollem Umfang, die Tester tun das Falsche, die Entwickler tun das Falsche und der SRE überwacht die falschen Parameter.
Wie kann das behoben werden?
In früheren Arbeitsbereichen habe ich den folgenden Arbeitsalgorithmus gesehen:
- Sammlung von Informationen und Bildung von Anforderungen;
- Das Team pflegt und denkt über eine gemeinsame Lösung nach.
- Es wird ein Testamentsvollstrecker ernannt, der die Aufgabe ausführt.
- Code-Review;
- behebt;
- testen;
- mehr Korrekturen;
...
- mehr Korrekturen;
- lang erwartete Fertigstellung der Aufgabe.
, , ?
, , , , . 
Die Beschreibung der technischen Lösung erfolgt bereits vor Beginn der Entwicklung und wird dann vom gesamten Team überprüft. Zur Klarheit und Verbesserung der Wahrnehmung haben wir beschlossen, den Text mit grafischen Schemata zu verdünnen. Der Zweck dieser Aktion besteht darin, Fallstricke zu identifizieren, die richtigen Tools auszuwählen, korrekt mit anderen Knoten im System zu interagieren und das gesamte Team in die Lösung einzutauchen. Das Ergebnis, das wir erwartet hatten, war eine Verringerung der Arbeitskosten und Fehler in den Geschäftsprozessen (mit Blick auf die Zukunft werde ich sagen, dass Fehler in der Geschäftslogik praktisch verschwunden sind, viele technische Fehler vermieden wurden, Korrekturen reduziert wurden und die durchschnittliche Zeit für die Ausführung der Aufgabe recht gut gesunken ist). Es stellte sich auch heraus, dass es viel einfacher und schneller ist, Änderungen an einer Textbeschreibung oder einem Diagramm vorzunehmen als an bereits geschriebenem Code.
Dann lautet der Arbeitsalgorithmus wie folgt:
- Sammlung von Informationen und Bildung einer Anforderung;
- Das Team pflegt und denkt über eine Lösung nach.
- ein verantwortlicher Entwickler wird ernannt;
- Der Entwickler beschreibt die technische Lösung .
- Anschließend wird diese technische Lösung vom Team und anderen im Themenbereich tätigen Personen überprüft .
- und erst nachdem die Lösung vereinbart wurde, schreibt der Entwickler den Code ;
- Code-Review;
- testen.
Warum ist es so wichtig, die technische Lösung vor der Implementierung selbst zu beschreiben:
- Die Logik der Lösung wird überprüft, Fehler werden in der Entwurfsphase korrigiert.
- Der Entwickler taucht vor der Implementierung tiefer in die Domäne ein, wodurch die Architektur im Voraus überlegt werden kann.
- benachbarte Abteilungen können sofort verstehen, wie die API aussehen wird, und sind bereit, mit der parallelen Entwicklung zu beginnen.
- klärt die Bedürfnisse von Kollegen in Abhängigkeit von Ihrer Implementierung;
- ( , , ).
Exness?
Nachdem ich zu Exness gekommen war, wollte ich mich schnell an das Team gewöhnen, die Infrastruktur studieren und Kampfmissionen lösen. Bei der ersten umfangreichen Aufgabe habe ich mich entschlossen, die gesammelten Erfahrungen zu nutzen und das Risiko einer falschen Lösung des Problems zu minimieren. Um die Interaktion von Diensten zu beschreiben, entschied ich mich für Sequenzdiagramme, ein Blockdiagramm zur Beschreibung der Funktionsweise von Algorithmen und ER-Diagramme zur Beschreibung des Datenbankschemas.
Beim Zeichnen des Diagramms habe ich von meinen Kollegen erfahren, welche Dienste zur Lösung meines Problems erforderlich sein könnten, die Anforderungen an sie und die Daten in der Datenbank überprüft, sodass ich bereits verstanden habe, was und wie es funktioniert. Die Entwicklung des Diagramms dauerte nicht lange, und während ich das Diagramm überprüfte, erhielt ich nützliches Feedback:
- Der Front-End-Entwickler wollte wissen, in welchen Fällen, welche Daten und Status er vom Back-End erhalten würde.
- Die Qualitätssicherung muss verstehen, woher die Daten im Service stammen, um so viele Fälle wie möglich abzudecken.
In der Abbildung habe ich die Ausnahmen und deren Entstehung sowie die verwendeten Datenquellen detailliert beschrieben. Dies ermöglichte es, Kollegen visuell zu zeigen, wie die Funktionalität funktioniert und was von ihnen zu erwarten ist. Kollegen konnten mit der Implementierung ihrer Teile beginnen, ohne auf meine Implementierung zu warten. Der Front-End-Entwickler wusste, wie der Service reagieren würde, und konnte mit dem Schreiben von Integrationen beginnen. Die Qualitätssicherung verfügte über Informationen darüber, wie der Service auf verschiedene Situationen reagiert und wie diese Situationen reproduziert werden können. Infolgedessen erwies sich die Entwicklung und das Eintauchen in die Aufgabe als recht schnell, und das gezeichnete Diagramm ergänzte die Dokumentation des zu entwickelnden Dienstes.
Beispiel
Das unten beschriebene Beispiel setzt sich aus verschiedenen Situationen zusammen.
Der neue Entwickler erhielt eine Aufgabe mit der Aufschrift " Schreiben Sie einen neuen Microservice, um überfällige Anträge abzulehnen. Benachrichtigen Sie Kunden über die Statusänderung. "
Nachdem Sie die technischen Details geklärt haben, können Sie das Problem folgendermaßen verstehen:
- Erstellen Sie einen Mikroservice und erstellen Sie einen POST darin - eine API-Methode mit dem Namen reverse_old_requests.
- Bei dieser API-Methode müssen Sie Daten aus der Datenbank abrufen und Filter nach Benutzer, Status und Datum in der Anforderung angeben.
- Ändern Sie für jede Anforderung den Status in dem Dienst, der Anforderungen verwaltet.
- Senden Sie dann eine Anfrage an den Benachrichtigungsdienst, um Benutzer über die Änderung des Status der Anwendung zu benachrichtigen.
Das Sequenzdiagramm für diese Aufgabe könnte folgendermaßen aussehen:
und auf welche Fehler könnten Sie stoßen:
- Unter dem neuen Microservice könnte der Analyst die übliche API-Methode im Microservice für die Arbeit mit Anforderungen bedeuten, aber es ist schwierig, ein solches Szenario zu erkennen (in meiner Praxis gab es einen Fall, in dem der Analyst die übliche API-Methode als Microservice verstand, soweit ich weiß, dass sich der Analyst nicht an die richtige Terminologie angepasst hat).
- Möglicherweise enthält die Anwendung Unteranwendungen oder verwandte Anwendungen, deren Existenz der neue Entwickler möglicherweise nicht kennt, und der Analyst vergisst möglicherweise, Bericht zu erstatten, und hofft, dass der Entwickler selbst die Informationen erhält.
- Vielleicht wird es viele Anträge geben, und ihre Ablehnung beim Verkauf wird lange dauern. In diesem Fall wäre es besser, sich hinzulegen und es möglich zu machen, im Hintergrund abzulehnen;
- — , . , .
Insgesamt stellt sich heraus, dass eine solche Lösung von Grund auf neu geschrieben werden muss, da das Vorhandensein solcher Fehler die Implementierung unrentabel machen kann.
Wenn Sie vor der Entwicklung eine technische Lösung schreiben und aus Gründen der Übersichtlichkeit ein Sequenzdiagramm verwenden, können während der Überprüfung mehr Kollegen im Themenbereich Fehler erkennen und darauf hinweisen. Und wahrscheinlich kann der Entwickler selbst einige Probleme erkennen und beheben, bevor er überprüft wird.
Ich versichere Ihnen, nur die Lösung eines Problems zu sprechen, bedeutet nicht, das Problem richtig zu lösen. Einer wird es nicht richtig ausdrücken und der andere wird es nicht richtig verstehen und die Aufgabe wird nicht richtig implementiert. Das Sequenzdiagramm ist kein Wundermittel, aber in vielen Fällen hilft es, einige Details zu klären.
Wie das Diagramm nach den Korrekturen aussehen würde:
Was ist die Verwendung von Diagrammen?
Nicht jeder kann einen Gedanken gut auf Papier übertragen, daher ist es manchmal besser, den Text mit einer grafischen Beschreibung zu verdünnen. Eine klarere Beschreibung der Aufgabe ist nicht nur für Entwickler, sondern auch für Tester hilfreich, da sie mit demselben Immersionsproblem wie Entwickler konfrontiert sind. Tester müssen nicht nur positive Ergebnisse überprüfen, sondern auch sicherstellen, dass das System in jeder Situation korrekt und vorhersehbar reagiert. Um solche Fälle zu emulieren, muss man gut verstehen, was sich im System geändert hat. Für das gesamte Team ist es möglicherweise bequemer, die Dokumentation in Form von Diagrammen oder verschiedenen Schemata zu speichern, da sie lakonisch sind und bei großen Änderungen weniger Zeit zum Bearbeiten benötigen als eine Textbeschreibung. Bei einem umfassenden Refactoring sind Diagramme unverzichtbar, da Sie schnell verstehen können, wer und wie mit einem bestimmten Knoten im System arbeitet.Für Teamleiter ist dies insofern nützlich, als Sie Ihre Zeit und die Zeit der Nachwuchskollegen für das Eintauchen reduzieren und dementsprechend Aufgaben genauer planen können. Beim Übertragen von Fällen von einem Entwickler auf einen anderen werden die Zeitkosten reduziert bzw. die Situation mit dem Busfaktor verbessert.
Welche Schlussfolgerungen können gezogen werden?
Sequenzdiagramme sind ein sehr leistungsfähiges und nützliches Werkzeug, das Ihnen und Ihren Kollegen Zeit spart. Eine visuelle Beschreibung erleichtert das Verständnis und ermöglicht es Ihnen, sich auf die Lösung selbst zu konzentrieren, ohne tief in die technische Implementierung einzusteigen. Aber sagen Sie auf keinen Fall, dass eine solche visuelle Beschreibung eine Rettung von allen Problemen ist, aber es wird helfen, einen wesentlichen Teil davon zu lösen.
Diagramme helfen auf jeden Fall bei:
- die Qualität und Geschwindigkeit des Eintauchens in das Projekt / die Aufgabe;
- die Situation mit dem Busfaktor verbessern;
- Reduzierung der Arbeitskosten für die Pflege der technischen Dokumentation;
- Vereinfachung der Übertragung von Fällen zwischen Kollegen;
- Reduzieren Sie die Arbeitskosten für Implementierung, Test und Codeüberprüfung, da die Logik zur Lösung des Problems bereits vor Beginn der Implementierung überprüft wird. So vermeiden Sie viele Fehler.
Persönlich waren und sind Diagramme in meiner Praxis ein unverzichtbares Werkzeug.
Ich möchte auch, dass Sie Tools finden, die Ihre Arbeit optimieren. Vielen Dank für das Lesen bis zum Ende.
PS Schreiben Sie in die Kommentare, wenn Sie diese Praxis verwenden, welche Tools verwenden Sie?