Vor einiger Zeit habe ich eine Verzerrung der angewandten Techniken in der Softwareproduktion beobachtet. Nachdem ich mich mit Einzelheiten (der Verwendung von DDD) befasst hatte, wollte ich den Leser darauf hinweisen, dass man auf Anraten des Eulenmanagements seine Pflicht als Ingenieur nicht erfüllen kann.

In einem kürzlich erschienenen hochkarätigen Artikel über die nackten Könige der Branche wurde mir klar, dass ich immer noch - mein Verständnis davon, was für ein Programmierer ich sein möchte und was ich um mich herum sehen möchte - Ingenieure ausdrücken möchte, die den Kontext ihrer Arbeit, ihre Rolle und die dabei anzuwendenden Methoden verstehen . Unter dem Strich lade ich den Leser ein, mit mir darüber nachzudenken, was wir im Großen und Ganzen tun und was dies den Entwicklern in ihren Aktivitäten Grenzen setzt.

Über die Ursache des Widerspruchs

Ich werde aus der Ferne beginnen - aus dem 18. Jahrhundert. Die Entwicklung und Sozialisierung der Produktion in Verbindung mit dem Wettbewerb treiben die Produzenten immer wieder dazu, die Produktion zu modernisieren und zu automatisieren. Dampfmaschinen, Jacquardwebmaschine, Förderer, Produktionslinien und Roboter - all diese Verbesserungen spielen ihre wirtschaftliche Rolle - verschaffen einen Wettbewerbsvorteil als Voraussetzung für eine noch stärkere Sozialisierung der Arbeit, nämlich die Vereinheitlichung der Produktionsketten. Infolgedessen wächst die Produktion, sie können ihre Entwicklung und Automatisierung planen, um noch größere Gewinne zu erzielen.

Natürlich hat jedes Unternehmen immer eine Alternative zu Gewinnmethoden. Stellen Sie zum Beispiel billigere Arbeitskräfte ein, effektive Manager, die in der Lage sind, drei Häute von diesen Arbeitern zu senken. Wenn Sie jedoch wie ich der Meinung sind, dass die Menschheit nicht stehen bleiben, sondern auf dem Weg zum Fortschritt sein sollte, werden Sie mir zustimmen, dass dies keine Option ist, die zu uns passt. Ja, all diese Läden ohne Verkäufer haben große Angst, denn Drohnen liefern zunehmend Waren, die AI ist bereit, Treiber zu ersetzen, und so weiter. Wirtschaftswissenschaftler haben Angst vor dem Erscheinen von Industrien mit ungefähr Null Kosten. Ingenieure, Designer, Erfinder, Architekten und nur Wissenschaftler müssen ihre Arbeit noch erledigen - um die Produktionskosten durch Qualitätsverbesserung zu senken - das ist unsere sozioökonomische Aufgabe.

Um nicht über zu hohe Angelegenheiten zu sprechen, schlage ich vor, auf unsere unmittelbaren Aktivitäten zurückzukommen. Für Unternehmen gibt es immer die Möglichkeit, 10 Personen in 10 Einheiten einzusetzen, um einfache Arbeiten auszuführen, oder 4 Personen in 25 Einheiten werden diese Arbeit automatisieren und dann bedienen. Und Ihr klares Verständnis der Komplexität der geschäftlichen Anforderungen und der technischen Anforderungen kann dazu beitragen, diese Entscheidung für einen intensiven Entwicklungspfad zu treffen. Und was bedeutet es für den Kunden, einen solchen Weg zu wählen?

Ein Teil des Tages arbeiten wir für uns selbst und ein Teil des Tages für den Arbeitgeber oder Kunden. Ich werde mir erlauben, dies mit der folgenden Kostenformel auszudrücken:

wo

c ist festes Kapital , d.h. Organisationstools, die es ihm ermöglichen, seine Aktivitäten auszuführen (Computer, Software usw.).
v - Gehälter der Angestellten.
m ist der fiktive Gewinn derjenigen, die die Produktion besitzen.

Bei der Softwareentwicklung gibt es einige Nuancen: Wenn Software ein Serviceteil eines Unternehmens ist, das sich ständig weiterentwickelt, müssen Sie einige Arbeiten direkt ausführen, die nicht mit der Lösung eines Geschäftsproblems zusammenhängen. Fühle den Unterschied - was für ein paar weniger geschickte Leute ausgegeben werden könnte, wird " für die Arbeit im Interesse der zukünftigen Arbeit " ausgegeben. Wenn wir dies auf die Formel übertragen, bedeutet dies, dass wir uns für ein konstantes Kapital einsetzen. C , wir müssen Geld aus den Gehältern von jemandem ausgeben, aus dem Gewinn m oder aus den Kosten von Waren W. Sollte genauer betrachtet werden.

Wenn Sie zum Beispiel vorhaben, die Architektur Ihres Monolithen zu erarbeiten und in Microservices zu zerlegen, Ihr Kunde dies jedoch nicht direkt benötigt, was kostet ihn die technische Raffinesse?

• m - Der Kunde kann seinen Gewinn aufgeben. Der Name dieser Investition, d.h. kontrolliertes Risiko eines höheren Gewinns. In diesem Fall muss das Risiko erkannt werden. Wenn Sie lernen möchten, wie Sie riesige Komplexe für das Geld anderer Leute erstellen, ist dies ein unkontrolliertes Risiko. Eine andere Sache, zum Beispiel im Rahmen einer Retrospektive, ist die Durchführung eines kleinen Experiments, die Auswertung der Ergebnisse und die Weiterentwicklung.

  
  

• W - Der Kunde kann den Preis seiner Produkte und Dienstleistungen erhöhen. Monopole können es sich durchaus leisten, die Kosten zu erhöhen, und dies ist am wahrscheinlichsten. Am wahrscheinlichsten ist der Kunde jedoch immer von den Marktbedingungen erschüttert.

  
  

• v - Sie können das Gehalt einer anderen Person aufgeben, und es gibt Optionen.
  1) Du wirst deins opfern. Sie werden ein Open Source-Projekt bearbeiten oder erstellen, das Ihnen bei der Arbeit hilft.
  2) Sie automatisieren die Arbeit eines anderen, so dass weniger Personen sie verwenden können.

  
  

  Naive Leute wie ich wählen leider Option 1. Aber wenn Sie in 2 erfolgreich sind, ändern Sie die Produktionskette qualitativ: Er benötigt weniger als nur arbeitende Hände und immer mehr Fachleute, die Prozesse erstellen und korrekt modifizieren können.

  
  

Das Problem mit dem Team ist, dass es nicht entscheidet, was zu tun ist. Aber es kann zu Auseinandersetzungen führen und das Geschäft wird von nichts anderem als materiellen berührt - der Schönheit des Codes, dem neuen Rahmen, der modischen Technik - es geht nicht um Geld. Investitionen in technologische Komplexität und Geschäftsanforderungen sind verbunden. Man sollte dem zweiten entsprechen.

Antagonismus der Anforderungen

Software ist eine komplexe Lösung, die das Gleichgewicht zwischen zwei dialektischen Widersprüchen darstellt: Geschäftsanforderungen und Architektur. Bei der Beurteilung der Komplexität des Entwurfs eines Systems kann es äußerst einfach sein, die Argumente der Parteien zu übersehen, die sich ihrer Natur nach widersetzen. Es ist wichtig, den Kontext zu verstehen, vor welcher Art von Aufgabe Sie stehen, unabhängig von Ihrer Rolle im Projekt: Product Owner oder Team .

• Die Geschäftsseite (PO, SH) möchte gerne so arbeiten, dass möglichst wenig Ressourcen dafür aufgewendet werden. Leider ist die Darstellung dieser Position sehr einfach, da sie nicht nur in unser Leben, sondern auch in die IT-Folklore eingedrungen ist - eine Eule ist ein effektiver Manager, das auffälligste Beispiel.
• Executors (Team) müssen eine solche Reihe von Arbeiten ausführen, um die Lösung der wichtigsten Aspekte der Architektur für die Lösung eines Geschäftsproblems sicherzustellen, ohne im Idealfall technische Schulden und Werkzeuge für eine schnellere Problemlösung anzusammeln. Das Geschäftsteam ist die Lieferung von Software, und die Architektur ist das konstante Kapital, das ihr zur Verfügung steht.

Um einen gemeinsamen Nenner zu finden, schlage ich vor, dem Kunden vor jedem neuen Projekt die folgenden Fragen zu stellen:

• Was genau tun wir für den Kunden, was ist der erwartete Nutzen?
• Die Häufigkeit der Anwendbarkeit dieser Lösung.
• Die Wahrscheinlichkeit von Änderungen / Erweiterungsanforderungen.
• Besteht eine Verbindung zu anderen Systemen / Diensten / Kontexten?

Die Anzahl der Anforderungen von Unternehmen und Architektur muss verhältnismäßig sein, sonst ist die Klasse der gestellten und gelösten Aufgabe nicht proportional, und wenn die Anforderungen von der einen oder anderen Seite wachsen, kann die Lösung verzögert oder umstrukturiert werden. Mit anderen Worten, damit der Kunde seine Probleme besser lösen kann, müssen wir auch die geeigneten Mittel haben, um Entwicklungsprobleme zu lösen. Das heißt Gasschweißen und ein Vorschlaghammer, niemand wird eine Rakete für Astronauten bauen.

Wenn die Aufgabe also klein ist und der Kunde sie mit einem Minimum an Ressourcen lösen muss, wenn die Aufgabe nicht wiederholt wird, nicht mit großen Systemen verbunden ist, sind die TransactionSript-Lösung, ein Smart Client und alle Anti-Patterns akzeptabel. Seien wir realistisch - es gibt solche Probleme, und sie müssen gleich gelöst werden, manchmal sehr schnell (aber wir vergessen nicht, dies mit einer technischen Schuld zu kennzeichnen). Aber nur in diesem Fall lassen Sie sich nicht von anämischen Modellen in Pipelins und anderen halben Sachen täuschen.

Die mit vorhandenen Systemen verbundenen Aufgaben können auf der Grundlage des vorhandenen Systems gelöst werden, wobei eine minimale Analyse der internen Prozesse vorgenommen wird. Wenn die Aufgabe nicht erweitert oder Änderungen der Anforderungen nicht erwartet werden, ist die Lösung TableModule, Shared Database usw. akzeptabel.

Signifikante Geschäftsanforderungen können erhebliche Anforderungen an die Architektur stellen (z. B. erhöhte Verfügbarkeit, Autorisierung, Fehlertoleranz, Leistung). Architektur kann wiederum Möglichkeiten zur Lösung neuer Probleme eröffnen (was in erster Linie mit dem Übergang zu einer komplexeren Architekturvorlage und der Vermeidung bestimmter Szenarien verbunden ist).

Sehr oft fragen Entwickler bei Konferenzen und Besprechungen die Referenten: Wie können sie unsere Arbeitgeber davon überzeugen, dass sie Zeit für etwas aufwenden müssen (Tests, Architektur, Dokumentation usw.)? Für High-End-Aufgaben gibt es wahrscheinlich keine Alternative. Der Grund dafür ist der Lebenszyklus von Produkten, Dienstleistungen und Organisationen.

Der technologische Zyklus bestimmt (gleichzeitig Grenzen) die Entwicklung - um in die nächste Entwicklungsstufe einzutreten, ist es notwendig, die Grenzen des aktuellen technologischen Prozesses zu überschreiten. Das heißt Erweitern Sie Ihre Übungen, probieren Sie etwas Neues aus und stellen Sie kontrollierte Experimente auf.

Allmählich, wenn die Anzahl der komplexen Plattformlösungen einen bestimmten Wert überschreitet, wird dies zu einem qualitativen Wachstum führen. Negative Kosten für technische Schulden, Architektur kann eine Investition in komplexere Aufgaben werden, die den ursprünglichen Zweck verweigern .

Agile, CI, DDD usw. Ermöglichen es Ihnen, die Grenzen des Prozesses zu verschieben. Diese Wissensbereiche und Methoden, mit denen die Komplexität von Aufgaben auf vielfältige Weise bewertet werden kann, bilden die Grundlage für die Teamarbeit. Nehmen Sie diese Dinge richtig als ganzheitlich wahr, als Gelegenheit für viele, viel beizutragen, um genau das Ergebnis zu erzielen, das Sie brauchen!

Vom Bedarfsgleichgewicht zum Arbeitsgleichgewicht

Wenn es um den Software-Lebenszyklus geht, werden sich modische Trainer und agile Trainer nicht an das berühmte Diagramm von I. Adizes erinnern.

Alles darin ist schön und schön, aber es ist einseitig. Die Subjektivität des Modells spiegelt also nicht den internen Organisationsprozess wider. Viele Teams sind sich einig, wie viel Zeit sie für technische Schulden und verschiedene Aspekte der Architektur aufwenden werden. Ich biete Ihnen meine Gedanken zu diesem Thema an - der Achse des technologischen Zyklus (OTC).

Die Abszissenachse wird als die Komplexität von Geschäftsmerkmalen angesehen. Die Ordinatenachse ist die Komplexität der architektonischen Arbeit. Mit Komplexität meine ich blöde Handlungspunkte. Wenn Sie die Leistung der Funktionen in diesem Diagramm verzögern, können Sie feststellen, wie anpassungsfähig Sie für die Software sind, die Sie für spätere Änderungen freigeben.

• Je genauer der letzte Punkt des Diagramms in Bezug auf OTC ist , desto früher ist das Produkt nützlich und desto schwieriger wird es, es für komplexe Aufgaben zu entwickeln.
• Je links vom letzten Punkt des Diagramms in Bezug auf OTC , desto mehr werden Sie von der Plattform hinreißen lassen, und Sie riskieren, keine funktionierende Software innerhalb der Frist bereitzustellen.
• Dementsprechend lohnt es sich, an einer gleichmäßigen Entwicklung festzuhalten, d.h. Bewegung entlang der Achse.

In der Abbildung oben habe ich eine Vorstellung davon, wie viel Zeit für die Implementierung von Business Opportunity X und Architektur Y aufgewendet wurde, wobei die Z- Achse den Nutzen des Produkts widerspiegelt.

Fazit

Wenn geschäftliche Aufgaben eine komplexe Architektur erfordern, kann die Architektur ein Treiber für die Lösung komplexer Probleme sein, die jedoch Voraussetzungen haben müssen - die Möglichkeit der Prozessoptimierung. Wenn der Kunde eine Reihe komplexer Aufgaben hat, die mit den derzeitigen Werkzeugen schwer zu lösen sind, ist es möglich, dass sie mit Hilfe einer qualitativen Änderung gelöst werden können. Um zu einer qualitativen Änderung zu gelangen, müssen bestimmte Änderungen nacheinander akkumuliert werden. Um beispielsweise auf Microservices umzusteigen, wird der Monolith häufig konsistent in begrenzte Kontexte und Aggregate unterteilt und CI wird konsistent erreicht. Und umgekehrt, wenn Sie dem Legacy-Code Funktionen hinzufügen müssen und dies durch sequentielles Refactoring geschieht.

Komplexe architektonische Arbeiten - Ihr Beitrag kann dazu beitragen, dass ein Unternehmen rentabler und wettbewerbsfähiger wird. Gleichzeitig wird es wichtig, Kompromisse und kompromisslose Ansätze bei der Konzeption und Implementierung zu vermeiden, um schnelle, kurzfristige Vorteile zu erzielen. Heute erhöhen Sie einen KPI, und morgen können Sie aufgrund von akkumulierten Produktproblemen keine neuen Funktionen rechtzeitig erstellen.

In einem Bericht von Cyril Skrygan Platform (IDE) wars empfehle ich, den Zusammenhang zwischen Tuning und Geschäft zu untersuchen .