#baby $BABY
竹竹 blickt gerade auf die Architektur von Babylon Genesis: Epoching, Checkpointing, BTC Staking und Finality sind jeweils als eigenständige Module organisiert. Diese Aufteilung findet竹竹 erstaunlich clever—jedes Modul kümmert sich nur um seinen eigenen Bereich. Wenn etwas schiefgeht, muss nicht das gesamte System als Ganzes mit untergehen, und das Eingrenzen von Problemen geht viel schneller.
Vor ein paar Tagen ist ihr jedoch plötzlich ein Blickwinkel eingefallen, den sie vorher nicht genauer betrachtet hatte: Wenn man Module immer weiter aufsplittert, heißt das dann, dass die „Beziehungen“ zwischen den Modulen zu neuen, versteckten Kosten werden?
Das fühlt sich ein bisschen an wie ein Team mit sehr feiner Arbeitsteilung: Jede Person ist für einen Teil zuständig, die Effizienz ist tatsächlich hoch. Aber sobald jemand seine Arbeitsweise ändern muss, müssen sich die anderen mehr oder weniger mit anpassen, sonst stimmt die Abstimmung nicht mehr. Eine monolithische Architektur ist wie „alles in einer Hand“: Es ist zwar anstrengend, aber man muss sich zumindest keine Sorgen machen, ob die Schnittstellen mit anderen richtig zusammenpassen. Die Modularisierung nimmt diese Mühe zwar weg, bringt aber eine andere Art von Kosten mit sich—eine Art Koordinationsaufwand, der schwieriger zu erkennen ist, aber dauerhaft existiert.
竹竹 meint, dass sich diese Art von Kosten in der Anfangsphase von Absprachen kaum bemerkbar macht: Es gibt nur wenige Module, Updates sind nicht häufig, und wenn man sich kurz abstimmt, passt es meistens. Wenn das System aber lange genug läuft und sich die Funktionen ständig stapeln, entwickeln sich die Module jeweils in unterschiedliche Versionen weiter. Dass trotzdem alles reibungslos miteinander kommunizieren kann, kann sich selbst im Verborgenen in gewisser Weise als Technik-Schulden ausdrücken. Das ist kein Problem der Code-Qualität, sondern die Komplexität, die nötig ist, um die Abstimmung zwischen Modulen aufrechtzuerhalten—sie baut sich mit der Zeit Stück für Stück auf. Viele große Systeme scheitern am Ende nicht daran, dass „irgendein Modul kaputt“ ist, sondern daran, dass diese Versionen irgendwann nicht mehr zusammenpassen.
Diese Einschätzung kann竹竹 bisher nicht vollständig verifizieren, denn Babylon ist noch relativ jung, und es gibt noch nicht genügend reale Fälle von Modul-Upgrades. Aber竹竹 glaubt, dass das ein Signal ist, auf das man schon jetzt achten sollte—nicht darauf, welche neuen Funktionen gerade herausgebracht werden, sondern darauf, wie lange es bei jedem gemeinsamen Upgrade der Module dauert und wie viele Teams davon betroffen sind. Wenn diese Zeit immer länger wird, könnte das bedeuten, dass die Technik-Schulden gerade erst langsam sichtbar werden.
@BabylonLabs_io
竹竹 hat eine kleine interaktive Frage: Sollten wir Technik-Schulden jetzt schon im Blick haben?
竹竹 blickt gerade auf die Architektur von Babylon Genesis: Epoching, Checkpointing, BTC Staking und Finality sind jeweils als eigenständige Module organisiert. Diese Aufteilung findet竹竹 erstaunlich clever—jedes Modul kümmert sich nur um seinen eigenen Bereich. Wenn etwas schiefgeht, muss nicht das gesamte System als Ganzes mit untergehen, und das Eingrenzen von Problemen geht viel schneller.
Vor ein paar Tagen ist ihr jedoch plötzlich ein Blickwinkel eingefallen, den sie vorher nicht genauer betrachtet hatte: Wenn man Module immer weiter aufsplittert, heißt das dann, dass die „Beziehungen“ zwischen den Modulen zu neuen, versteckten Kosten werden?
Das fühlt sich ein bisschen an wie ein Team mit sehr feiner Arbeitsteilung: Jede Person ist für einen Teil zuständig, die Effizienz ist tatsächlich hoch. Aber sobald jemand seine Arbeitsweise ändern muss, müssen sich die anderen mehr oder weniger mit anpassen, sonst stimmt die Abstimmung nicht mehr. Eine monolithische Architektur ist wie „alles in einer Hand“: Es ist zwar anstrengend, aber man muss sich zumindest keine Sorgen machen, ob die Schnittstellen mit anderen richtig zusammenpassen. Die Modularisierung nimmt diese Mühe zwar weg, bringt aber eine andere Art von Kosten mit sich—eine Art Koordinationsaufwand, der schwieriger zu erkennen ist, aber dauerhaft existiert.
竹竹 meint, dass sich diese Art von Kosten in der Anfangsphase von Absprachen kaum bemerkbar macht: Es gibt nur wenige Module, Updates sind nicht häufig, und wenn man sich kurz abstimmt, passt es meistens. Wenn das System aber lange genug läuft und sich die Funktionen ständig stapeln, entwickeln sich die Module jeweils in unterschiedliche Versionen weiter. Dass trotzdem alles reibungslos miteinander kommunizieren kann, kann sich selbst im Verborgenen in gewisser Weise als Technik-Schulden ausdrücken. Das ist kein Problem der Code-Qualität, sondern die Komplexität, die nötig ist, um die Abstimmung zwischen Modulen aufrechtzuerhalten—sie baut sich mit der Zeit Stück für Stück auf. Viele große Systeme scheitern am Ende nicht daran, dass „irgendein Modul kaputt“ ist, sondern daran, dass diese Versionen irgendwann nicht mehr zusammenpassen.
Diese Einschätzung kann竹竹 bisher nicht vollständig verifizieren, denn Babylon ist noch relativ jung, und es gibt noch nicht genügend reale Fälle von Modul-Upgrades. Aber竹竹 glaubt, dass das ein Signal ist, auf das man schon jetzt achten sollte—nicht darauf, welche neuen Funktionen gerade herausgebracht werden, sondern darauf, wie lange es bei jedem gemeinsamen Upgrade der Module dauert und wie viele Teams davon betroffen sind. Wenn diese Zeit immer länger wird, könnte das bedeuten, dass die Technik-Schulden gerade erst langsam sichtbar werden.
@BabylonLabs_io
竹竹 hat eine kleine interaktive Frage: Sollten wir Technik-Schulden jetzt schon im Blick haben?
A. 該
B. 不用
C. 之後再說
1 Tage(n) übrig