In diesem Artikel werde ich auf die Frage der Schwelle für die Eingabe eines Projekts mit einer etablierten Architektur eingehen und verschiedene Optionen für die Beantwortung einer sehr häufig gestellten Frage angeben: Warum ist es so schwierig?
Diese Frage stellt sich häufig bei Neulingen, die an dem Projekt teilnehmen. Oder es gibt Situationen, in denen das Projekt in neuen Händen in die Unterstützung und Entwicklung geht, und der neue Entwickler hat auch diese Frage. Und selten versucht einer von ihnen, die wahren Gründe herauszufinden, warum es hier so ist und nicht anders. Dies kann zu traurigen Konsequenzen für das Unternehmen führen. Beispielsweise kann ein neuer Entwickler darauf bestehen, die gesamte Anwendung von Grund auf neu zu schreiben.
Um solche Risiken zu minimieren, anstatt zu fragen, warum es so schwierig ist? stelle solche Fragen:
- Welche Anforderungen an den Entwicklungsprozess hat der Architekt gestellt?
- Was ist das Ergebnis des Entwicklungsprozesses, der am Ausgang erforderlich ist?
Anforderungen an den Entwicklungsprozess
Zunächst muss der Entwickler in das System des Entwicklungsprozesses eintauchen und die folgende Frage stellen:
- Auf welchem System ist der Prozess aufgebaut?
In der kundenspezifischen Entwicklung kommt häufig ein Projekt mit eindeutigen Anforderungen und einem festen Funktionsumfang zum Einsatz. Wie gut sie entwickelt sein können - das ist das Thema eines anderen Artikels. Und der Entwicklungsprozess in solchen Projekten wird meistens nach einem Wasserfall-System aufgebaut, da es sich um eine direkte Rückmeldung der Benutzer des Produkts handelt - nach der Entwicklung der gesamten Funktionalität des Produkts , während bei einem iterativen Modell die Rückmeldung nach der ersten Iteration erhalten werden kann. Für solche Projekte verfügt der Architekt in der Regel bereits über eine etablierte Architektur, die bestimmte Anforderungen für diesen Prozess erfüllt. Was sind die Anforderungen, die der Architekt an einen solchen Entwicklungsprozess stellt?
1) Der Pipeline- Entwicklungsprozess sollte für den Entwickler so komplex wie möglich sein . Und die Ablehnung des Codes, der in das Projektarchiv eingegeben wird, sollte maximal automatisch und, wenn möglich, ohne die Beteiligung des Architekten selbst erfolgen.
Das heißt Dabei muss eine bestimmte Pipeline konfiguriert werden. Der Code, der diese gesamte Pipeline durchlief, wird als zufriedenstellend angesehen. Das ist sehr wichtig, weil Ein guter Architekt muss seine Entwickler vor den Kopfschmerzen und der Verantwortung für nicht funktionierende Assemblys bewahren, nachdem der Code in das Repository gelangt ist. Wenn es keine solche Pipeline gibt , leiden Ihre Entwickler unter ständigem Stress. Wenn der Code in das Repository gelangt ist und die Pipeline ihn akzeptiert hat und dieser Code die Assembly beschädigt oder die bereits funktionierende Funktionalität beschädigt hat, liegt dies bereits an der Pipeline selbst.
Daher müssen Sie in einer solchen Pipeline Folgendes verwenden:
- Viele statische Code-Analysatoren
- Automatisierte Tests und Pyramiden- Compliance- Tests
- Automatische Berechnung der Codeabdeckung durch Tests
- Das Tor zur Codequalität (Quality Gates). Für alle Arten von Metriken: Prozentsatz der Codeabdeckung mit Tests, Prozentsatz der Codeduplizierung, Codegerüche, Sicherheit, Fehler usw.
- Cross-Code-Überprüfung
- usw
Alle diese Punkte zusammen führen zu der Frage des Entwicklers: Warum ist es so schwierig?
Versuchen Sie beispielsweise, Tests für diesen Code zu schreiben:
class SomeService( private val restApi: SomeApi
Sie müssen solche Tests auf einem echten Android-Gerät oder einem Emulator ausführen. Und dies wird sofort zu einer erheblichen Verschlechterung der zweiten Anforderung für den Entwicklungsprozess führen:
2) Automatisierte Pipeline- Elemente und der Entwicklungsprozess sollten so schnell wie möglich ausgeführt werden
Wenn Ihre Entwickler lange auf den Abschluss der Tests warten müssen - das ist das Problem Ihrer Pipeline, und wenn die Architektur diesen Prozess nicht beschleunigen kann - das ist das Problem Ihrer Architektur
Lassen Sie uns das Beispiel umschreiben:
interface SomeApi { fun loadSomething(): Single<NetworkResult> } class NetworkSomeApi : SomeApi { override fun loadSomething(): Single<NetworkResult> { } } class SomeService( private val restApi: SomeApi
Wir sehen, dass die Komplexität des Codes zugenommen hat, aber aus Sicht des Entwicklungsprozesses - wir haben die Architektur flexibler gemacht, jetzt müssen wir keine Geschäftslogiktests für den map im Emulator oder auf dem Gerät ausführen, sondern führen sie nur in Schnelltests aus. Dadurch wird die Anzahl der Integrationstests verringert, die in einer langsamen Umgebung ausgeführt werden müssen.
Das vom Architekten gewählte Entwurfsmuster kann die Anzahl der teuren Integrationstests verringern. Seien Sie nicht faul und beschäftigen Sie sich mit den Mustern, die heute populär sind: MVP , MVVM , MVI .
Lassen Sie uns ein wenig mehr über die Navigation in der App sprechen. Wir möchten auch in der Lage sein, es zu testen und in Schnelltests zu testen. Auch hier kommt es zu einer "Komplikation" der Architektur, da wir das Navigationssystem in der Anwendung hinter der Abstraktion verstecken müssen.
Und wir möchten auch in der Lage sein, die Komponenten unseres Systems mit DI zu verbinden, Abhängigkeitsgraphen zu erstellen und ihre Richtigkeit nicht zur Laufzeit, sondern bereits bei der Projektkompilierung zu überprüfen. Dann erscheinen Dolch 2 und seine monströsen Komponenten und Unterkomponenten mit Modulen auf der Bühne, die den armen Anfänger schon am Ende verwirren.
Und solche nicht offensichtlichen Momente der "Komplikation" der Architektur für Anfänger häufen sich sehr. Ohne die Entwicklungsprozesse und die Anforderungen für diese Prozesse zu verstehen, haben sie natürlich die gleiche Frage: Warum ist es so schwierig?
Ergebnis des Entwicklungsprozesses
Um den Erfolg des integrierten Entwicklungsprozesses und indirekt die Architektur des Projekts zu bewerten, muss das Ergebnis analysiert werden. Das Ergebnis ist in der Regel ein Produkt (eine Anwendung, wenn es sich um mobile Entwicklung handelt). Und die Metriken für den Produkterfolg sind für alle unterschiedlich: Der Kunde hat die gleichen Metriken, der Entwickler hat seine eigenen Metriken, der Produktbenutzer hat seine eigenen.
Zumindest sollten Sie als Architekt, der die Pipeline für den Entwicklungsprozess erstellt, berücksichtigen, wenn Sie die Effektivität des Entwicklungsprozesses für die Metriken und Geschäftsmetriken Ihres Unternehmens bewerten.
Dies ist ein fortlaufender Prozess: Entwicklung -> Sammeln von Metriken -> Analyse des Ergebnisses -> Vornehmen der erforderlichen Änderungen am Entwicklungsprozess.
Das Ergebnis beeinflusst somit die Entstehung des Entwicklungsprozesses und der Entwicklungsprozess beeinflusst bereits die Änderung der Architektur des Projekts. Das heißt Die wichtige Idee, die ich vermitteln möchte, ist, dass Architektur zweitrangig ist, das primäre Ergebnis und der Entwicklungsprozess .
Fazit
Lassen Sie uns abschließend noch einmal sagen:
- Ohne die Entwicklungsprozesse und die Anforderungen für diese Prozesse zu verstehen, schafft der Entwickler ein Gefühl für die komplizierte Architektur des Projekts.
- Architektur ist sekundärer, primärer Ergebnis- und Entwicklungsprozess;
Ohne ein Verständnis dieser Dinge möchte ein Entwickler möglicherweise alles von Grund auf neu schreiben. Dies ist meiner Meinung nach nur dann gerechtfertigt, wenn der Entwicklungsprozess und das Ergebnis den Kunden dieser Entwicklung nicht vollständig befriedigen.
Für Anfänger empfehle ich Ihnen, ein Projekt mit einer verfeinerten Entwicklungspipeline zu beginnen. Die Eintrittsschwelle für solche Projekte ist hoch. Wenn Sie diese jedoch überschreiten, werden Sie ernsthaft verstehen, wie Entwicklungsprozesse aufgebaut sind.