The First Ideal: Locality and Simplicity

Hi,

Ich habe mal ein Backend zu zweit entwickelt. Es war das Backend von Sunrise Village .

Bereits in der Pre-production schloss ich mich dem Team an. Gemeinsam mit meinem damaligen Kollegen. Über drei Jahre war das unser Backendteam.

Die anderen Teams waren größer. Wir hatten bis zu 8 Frontendentwickler, ähnlich viele Artists, zwei Gamedesigner, Productowner, Productmanager und 2 Testautomatisierer.

Und selbst, dass wir nur zu zweit waren, war eigentlich zu viel. Wir waren es zur Risikominimierung - falls einer ausfällt.

Warum waren wir so effektiv?

Der Grund war, dass wir alles mit so wenig Abhängigkeiten und so einfach wie nur möglich designed haben.

Wenn man das Projekt ausgechecked hat, dann gab es nur zwei Anweisungen zum starten des Backend in der readme.md:

1. Run `docker-compose up`
2. Start VillageApplication.java

Alles was zum starten des Backend notwendig war, hatten wir vorkonfiguriert. Alle Abhängigkeiten wurden in Docker gestartet. Abhängigkeiten zu internen Services wurden mit “general purpose” accounts vorkonfiguriert.

Und wenn wir Änderungen am System vornahmen, dann brauchten wir uns mit niemanden darüber abstimmen. Solange die API kompatibel blieb konnten wir releasen wann wir wollten. Unserer Versionierung folgte einem klaren Muster. Es war zwar kein semantic versioning (aus politischen Gründen - aber das ist eine andere Geschichte), aber es war deutlich wenn es einen breaking-change gab.

Und der größte Faktor: Wir “klauten” die gesamte Businesslogik beim Frontendteam. Sie schrieben ihren code in C# und hielten die Businesslogik frei von Framework-Dependencies. Diesen Code nahmen wir und betrieben einen ASP.net Service damit.

Das Backend war einfach.

“Locality and Simplicity” ist das erste Ideal der Softwareentwicklung, dass Gene Kim in seinem Buch The Unicorn Project beschreibt.

We need to design things so that we have locality in our systems and the organizations that build them. We need simplicity in everything we do. This ideal relates to the degree to which a development team can make local code changes in a single location without impacting various teams. The last place we want complexity is internally, whether it’s in our code, in our organization, or in our processes.

Es ist etwas magisches wenn man das schafft. Alles fühlt sich so leicht an.

Wo kannst du Komplexität verringern? Tu es!

Rule the Backend,

~ Marcus