1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Softwareentwicklung:…

Modularer-Aufbau

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. Modularer-Aufbau

    Autor: /mecki78 03.04.21 - 23:15

    Das Problem ergibt sich nicht, wenn man Software von Anfang an modular gestaltet. Weil dann gibt es keine Feature Flags, dann gibt es Module, die man wahlweise hinzufügt oder eben auch nicht bzw. zwischen denen man dann wählen kann. Und jedes Modul kann unabhängig vom Gesamtsystem entwickelt und getestete werden, so das jede Kombination immer funktionieren wird, außer Module widersprechen sich, dann aber muss so ein System das erkennen und dann kann man eben nur eins davon aktivieren. Die App selber besteht dann nur aus der Core Funktionalität, die man immer braucht und eben die Anbindung der Module und deren Management.

    /Mecki

  2. Re: Modularer-Aufbau

    Autor: ubuntu_user 03.04.21 - 23:18

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Das Problem ergibt sich nicht, wenn man Software von Anfang an modular
    > gestaltet. Weil dann gibt es keine Feature Flags, dann gibt es Module, die
    > man wahlweise hinzufügt oder eben auch nicht bzw. zwischen denen man dann
    > wählen kann. Und jedes Modul kann unabhängig vom Gesamtsystem entwickelt
    > und getestete werden, so das jede Kombination immer funktionieren wird,
    > außer Module widersprechen sich, dann aber muss so ein System das erkennen
    > und dann kann man eben nur eins davon aktivieren. Die App selber besteht
    > dann nur aus der Core Funktionalität, die man immer braucht und eben die
    > Anbindung der Module und deren Management.

    haha genau mein reden.

  3. Re: Modularer-Aufbau

    Autor: frostbitten king 04.04.21 - 00:27

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Das Problem ergibt sich nicht, wenn man Software von Anfang an modular
    > gestaltet. Weil dann gibt es keine Feature Flags, dann gibt es Module, die
    > man wahlweise hinzufügt oder eben auch nicht bzw. zwischen denen man dann
    > wählen kann. Und jedes Modul kann unabhängig vom Gesamtsystem entwickelt
    > und getestete werden, so das jede Kombination immer funktionieren wird,
    > außer Module widersprechen sich, dann aber muss so ein System das erkennen
    > und dann kann man eben nur eins davon aktivieren. Die App selber besteht
    > dann nur aus der Core Funktionalität, die man immer braucht und eben die
    > Anbindung der Module und deren Management.
    Naja. Hab schon Projekte mit ca 100 Modulen gesehen. Sry aber das ist dann kognitiver Clusterfuck.
    Bei uns haben die feature toggles den Vorteil wir können deployen bevor es vom Fachbereich /qa abgenommen ist, weil deaktiviert. Dann kommt qa bzw Fachbereich. Wenn die ok sagen is es schon auf prod und muß nur aktiviert werden. Finde das is a schon ein Vorteil.
    Das mit den vergessenen flags is was das muß ma eben Prozesstechnisch lösen. Ich Bau da in paar Monaten an was wie wir das automatisch handeln können dass sobald ein Feature abgenommen wurde und aktiviert wurde dass im build Prozess das gecheckt wird und eine Meldung ausspuckt ala hallo feature is aktiviert, entfernt beim nächsten commit den feature toggle. Alles nur eine Frage des managings.
    Vor allem sind wir damit das Problem der langlebigen Feature branches los geworden die dann irgendwann zu richtig komplexen merge conflicts führen. Und ja historisch bedingt kann man bei uns nicht gerade von modularität sprechen.

  4. Re: Modularer-Aufbau

    Autor: me2 04.04.21 - 14:46

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Das Problem ergibt sich nicht, wenn man Software von Anfang an modular
    > gestaltet. Weil dann gibt es keine Feature Flags, dann gibt es Module, die
    > man wahlweise hinzufügt oder eben auch nicht bzw. zwischen denen man dann
    > wählen kann.
    Wie wählst du das Modul denn aus? Egal wie die Antwort lautet, ist das deine Repräsentation der Feature Flags. Die Modulauswahl steuert deine Features.

    Ein modularer Aufbau hilft sehr dabei das Thema zu vermeiden und zu verwalten, aber es löst sicherlich nicht alle Probleme dabei.

    > Und jedes Modul kann unabhängig vom Gesamtsystem entwickelt
    > und getestete werden, so das jede Kombination immer funktionieren wird, [...]
    Das stimmt nicht immer! Nur weil alle Einzelkomponenten funktionieren muss das Gesamtgebilde nicht zwangläufig auch funktionieren. Du kannst einen PS-starken Motor problemlos mit einem schwachem Getriebe zusammenbauen und Reifen, die Leistung nicht auf die Straße bringen. Der Motor macht das Getriebe kaputt, und die Reifen drehen nur durch und steuern das Auto in die Wand weil das ESP Modul fehlt. Klar könntest du den Anschluss kodieren, so dass du einen 500 PS Motor nur mit einem Getriebe zusammenbauen kannst, dass mindestens 500 PS verträgt. Aber je mehr Modulvarianten du hast, desto mehr Details brauchst du um die Kompatibilität noch beschreiben zu können. Das pflegt dir keiner, vor allem nicht zwischen neuen Modulen und solchen die seit Jahren eigentlich ausgemustert sind.

    Ein anderes schönes Beispiel ist diese eine Rakete, die abgestürzt ist. Das eine perfekt zu 100% getestete Modul wollte eine Höhenangabe in Metern, und das andere perfekt zu 100% getestete Modul lieferte eine Höhenangabe in Fuß. Beide Einzelkomponenten haben für sich genommen funktioniert. Die Kombination hat aber nicht funktioniert.

  5. Re: Modularer-Aufbau

    Autor: ernstl 04.04.21 - 21:19

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Das Problem ergibt sich nicht, wenn man Software von Anfang an modular
    > gestaltet. Weil dann gibt es keine Feature Flags, dann gibt es Module, die
    > man wahlweise hinzufügt oder eben auch nicht bzw. zwischen denen man dann
    > wählen kann. Und jedes Modul kann unabhängig vom Gesamtsystem entwickelt
    > und getestete werden, so das jede Kombination immer funktionieren wird,
    > außer Module widersprechen sich, dann aber muss so ein System das erkennen
    > und dann kann man eben nur eins davon aktivieren. Die App selber besteht
    > dann nur aus der Core Funktionalität, die man immer braucht und eben die
    > Anbindung der Module und deren Management.

    Hey, wie ist die Aussicht da oben im Elfenbeinturm? Hier unten, wo neben der Qualität auch Zeit und Kosten eine Rolle spielen, sieht die Welt nicht so toll aus. Fachlichkeiten, die fast nur aus Ausnahmen von der Regel bestehen und jegliche generische Lösungsansätze im Keim ersticken; Terminvorgaben, die schon bei grober Betrachtung fernab jeder Realität sind; Entwickler, bei denen selbst ein "Hello World" fünf mal durchs Codereview fällt und nicht zuletzt Entwickler/Architekten, die jeweils ihren eigenen Style mit reinbringen wollen.

    Na gut, es gibt verschiedene Software. Du sprichts von "Apps", keine Ahnung, ob Du damit wirklich im näheren Sinne Handy/Desktopanwendungen meinst. Bei größeren Unternehmensanwendungen habe ich noch nie ansatzweise eine Modularität erlebt, wie Du sie beschreibts (obwohl es natürlich erstrebenswert wäre). Das, was dem am nächsten kommen würde und häufig zu finden ist, sind Microservices (bis vor Kurzem ja noch die Lösung für alles - bevor Cloud die Lösung für alles wurde), allerdings oft in der Variante "die kleinste inkompatible Änderung eines Services killt das gesamte Konstrukt".

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT Operations Engineer / Cloud Ops Engineer (w/m/d)
    ING Deutschland, Frankfurt am Main
  2. Senior Automation Engineer (m/w/d)
    Vesuvius GmbH, Borken
  3. System Engineer Contact Center (w/m/d)
    IT-Systemhaus der Bundesagentur für Arbeit, Nürnberg
  4. DevOps Engineer mit Schwerpunkt Operations (w/m/d)
    Landeshauptstadt München, München

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 99,99€ (statt 137,98€)
  2. 179,90€ (günstig wie nie, UVP 309€)
  3. (u. a. Kingston Fury DDR5-5600 16GB für 96,90€, Cooler Master Gaming-Tastatur für 69,90€)
  4. (u. a. Gigabyte RTX 3060 Ti für 499€, ASRock RX 6800 für 579€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


IAA Transportation: Akku schlägt Brennstoffzelle
IAA Transportation
Akku schlägt Brennstoffzelle

Auf der IAA Transportation in Hannover wird deutlich: Wasserstoff und Brennstoffzelle spielen eine untergeordnete Rolle beim Gütertransport.
Ein Bericht von Dirk Kunde

  1. Zero DSR/X im Test Die andere Art der großen Tour
  2. Elektroautos Tesla erhöht Supercharger-Preise massiv
  3. Elektromobilität Reichweite und Nachhaltigkeit zählen bei Elektroautos

Microsoft Dev Box: Eine eigene Maschine für jeden Entwickler
Microsoft Dev Box
Eine eigene Maschine für jeden Entwickler

Entwicklermaschinen on demand wie Microsofts Dev Box können für ein besseres Miteinander von Admins und Entwicklern sorgen. Wir zeigen, wie man startet und welche Vor- und Nachteile die Dev Box hat.
Eine Anleitung von Holger Voges

  1. Activision Blizzard Britische Kartellbehörde besorgt um Spielemarkt
  2. Open Source Microsoft stellt seine 1.500 Emojis quelloffen
  3. Rechenzentren Microsoft tauscht Server künftig nur alle sechs Jahre aus

Spieleentwicklung: Editorial trifft Engine bei Ubisoft
Spieleentwicklung
Editorial trifft Engine bei Ubisoft

Newsletter Engines Der oberste Game Designer von Ubisoft hat mit Golem.de über Engines gesprochen. Und: aktuelle Engine-News.
Von Peter Steinlechner