Hallo zusammen, ich freue mich auf eure Ideen und Anregungen. Es ist eine Firmware (Embedded C) gegeben, an der schon etwas länger entwickelt wird. Das Target ist eine MCU ARM Cortex-M3. Die Firmware beinhaltet derweil ca. 90 Komponenten und setzt auf ein proprietäres OS auf. Wobei ich das nicht als OS bezeichnen würde, sondern vielmehr ein Prinzip welches durch nachgeführte Funktionalitäten (Queues, Mailbox etc.) aufgepimpt wurde. Diese Firmware oder auch Software Architektur ist nun sehr anfällig bei Erweiterungen. Probleme wie nicht offensichtliche Abhängigkeiten, schwere Lesbarkeit tun ihr übriges. Ich würde gerne die gegebene Software Architektur umstrukturieren bzw. umbauen (refactorn). Mir ist bewusst, das sowas nicht über Nacht erreicht werden kann. Jedoch frage ich mich, wie ihr Anfangen würdet etwas Struktur reinzubringen bzw. ob es nicht Sinn macht eine neue Architektur aufzusetzen und den größten Teil neu zu entwickeln? Es fehlt an: Coding - Richtlinien Nicht alle Requirements sind vorhanden Dokumentation Wie würdet ihr dabei vorgehen? Ich bin gespannt auf euren Input. Viele Grüße
> Es fehlt an: > Nicht alle Requirements sind vorhanden > Wie würdet ihr dabei vorgehen? Also es wurde Software erstellt, ohne das klar ist was diese machen soll? Dann sollte man mal Schadensersatzansprüchen gegenüber Programmierer und Projektmanager prüfen. Ansonsten das übliche Vorgehen; erst festhalten was das Ding tun soll (Requirements), diese dann freigeben und dann an die Implementierung gehen. Was bisher hingecodet wurde kann man vielleicht in Teilen als "proof of concept" ansehen, ansonsten ist es für die Tonne. Ach ja, hier braucht es sicher neue, gut kehrende Besen ...
No N. schrieb: > Ich würde gerne die gegebene Software Architektur umstrukturieren bzw. > umbauen Bist du auch derjenige, der dafür das Budget und die benötigten Ressourcen genehmigt? Wenn nicht, vergiss es. Da bleibt dann nur das Prinzip Hoffnung, daß der ganze Schxx nicht komplett hochgeht, bevor du eine neue Stelle gefunden/die Rente erreicht hast. Oliver
Von Vorn anfangen. Und zwar mit nem richtigen RTOS. Dann kannst Du auf ne Grundlage bauen, die Profis gelegt haben. Wenn dann Fehler auftreten, warst Du es und nicht das RTOS. :-P Ich würd kein C nehmen, sonder EC++, also embedded C++, auch wenn du keine dynamischen Objekte benutzt ist C++ durch seine festere Typensicherheit, Überlagerungsmöglichkeit von Funktionen, Inline u.s.w. die bessere Wahl. mfg
Lotta . schrieb: > Von Vorn anfangen. > Und zwar mit nem richtigen RTOS Und da wir die Anforderungen nicht kennen, in die Begrenzungen des RTOS laufen, was zu neuem Gefriggel und halbgaren Lösungen führt, bei denen dann nach weiteren endlosen Monaten die Frage gestellt wird ob man mit einem proprietären 'OS' nicht besser fahren würde. Ein Fall für einen SW Architekten, nicht für den Code Monkey und auch nicht für das mc.net Forum. Nach einer soliden Zeit und Kostenrechnung wünsche ich dem der das dem Chef vorschlägt robuste Nerven. 'Wir haben all Dein Geld verbrannt, haben uns im Dickicht verloren und möchten nun mit neuem Geld nochmal das gleiche tun' findet der bestimmt ganz toll.
Michael schrieb: > 'Wir haben all Dein Geld verbrannt, haben uns im Dickicht verloren und > möchten nun mit neuem Geld nochmal das gleiche tun' findet der bestimmt > ganz toll. Vor allem, weil so eine Neuentwicklung ja parallel zum laufenden Geschäft geschieht, und schnell mal ein paar Mannjahre verballert, bevor da überhaupt was einsatzfähiges zu Stande kommt. Bei der Art der Frage dazu dann noch ohne jede Garantie, daß es danach besser wartbar/schneller/billiger werden oder überhaupt irgendwie einen Vorteil haben wird, und nicht nur eine neue völlig verkorkste Bastelware dabei herauskommt, bei der dann zusätzlich noch die Lizenzkosten für das RTOS anfallen. Oliver
No N. schrieb: > Jedoch frage ich mich, wie ihr Anfangen würdet etwas Struktur > reinzubringen bzw. ob es nicht Sinn macht eine neue Architektur > aufzusetzen und den größten Teil neu zu entwickeln? Zuerst solltest du dafür sorgen, dass alle Funktionen dokumentiert sind und ein Testautomat (oder manuelle Testprozedur) bereit steht, der nach dem Umbau bestätigt, dass die neue Firmware immer noch alle Anforderungen erfüllt. Der Aufwand dafür ist meist viel größer, als die Arbeit am Quelltext.
:
Bearbeitet durch User
No N. schrieb: > Jedoch frage ich mich, wie ihr Anfangen würdet etwas Struktur > reinzubringen das jetzige und seine Randbedingungen verstehen > bzw. ob es nicht Sinn macht eine neue Architektur > aufzusetzen und den größten Teil neu zu entwickeln? Das ist immer der einfachere Ansatz. Zumindest als bezahlter Entwickler. > Es fehlt an: > Coding - Richtlinien Hier ist zu unterscheiden, ob keine erkennbar ist: Oft gibt es ein oder zwei "Handschriften", die relativ problemlos niedergeschrieben werden können. Manchmal auch eine "Leithandschrift" und nur einzelne Module mit anderer. Das einfachste ist nun, sich eine gute Codier-Richtlinie auszudenken und den Code dahin zu refakturieren. Widerstehe dem! > Nicht alle Requirements sind vorhanden > Dokumentation sind es nie. Die Vorstellung, dass zu irgendeiner erfolgreichen SW einer kleinen bis mittleren Firma explizite Requirements oder Doku existieren, aus denen ein SW-Team das neu entwickeln könnte, sind Fantasien. Ergänze und korrigiere, wo notwendig. Meist tust Du es nur für Dich! > Wie würdet ihr dabei vorgehen? Incrementell: Wenn Du in einer anderen Firma so eine FW schon eigenständig entwickelt und gewartet hättest, würdest Du hier nicht fragen. Daher nehme ich an, Du bist jung, motiviert und smart, aber auch unerfahren. Mach Dich mit gängigen Paradigmen eine FW vertraut und verstehe deren Vor und Nachteile. Dann vergleiche mit der FW vor Dir. Zu Anfang eher offensichtliche Abweichungen eliminieren (Beispiel: Wenn es eine gute Art gibt, ein Bit zu setzen, und davon grundlos 10x abgewichen wird, dann baue die 10 Stellen um). Widerstehe dem Versuch, dem Code stattdessen Deine Handschrift aufzudrücken. Oft wird der Job des Entwicklers von dem stümperhaften Code bezahlt, den sein Vor-Vorgänger oder der Firmenchef zusammenghackt haben. Wenn es vor einer SW-Entwicklung Requirements, Coderichtlinien etc. gab, dann weil es das Dritte Projekt ist und alle sowieso wissen, wie es geht. Die Vorstellung, dass Linux oder FB auch am Reisbrett hätten entstehen können mit Requirements und Doku vorweg und dann Umsetzung durch Programmierer, ist weltfremd.
:
Bearbeitet durch User
Geil, @Bruno! > Zu Anfang eher offensichtliche Abweichungen eliminieren (Beispiel: Wenn > es eine gute Art gibt, ein Bit zu setzen, und davon grundlos 10x > abgewichen wird, dann baue die 10 Stellen um). Deshalb muß die Bitsetzerei ja zum Beispiel auch in ne Inline-Funktion (also doch EC++ :-P) oder in ein Makro, das dann im gesamten Projekt benutzt wird. Aber, @bruno, wie würdest Du nun vorgehen, wenn schon das benutzte RTOS Frickelware ist? mfg
Lotta . schrieb: > Deshalb muß die Bitsetzerei ja ... ich kenne den Code nicht, würde daher auch keine konkreten Tips geben. > Aber, @bruno, wie würdest Du nun vorgehen, wenn schon > das benutzte RTOS Frickelware ist? Das RTOS ist "proprietär" und durch Queues und Mailboxen "aufgepimpt". Das ist für mich noch kein Indiz für Frickelware. Ich glaube zu jedem OS gibt es Firmen, die eigene Queues oder Mailboxen gebaut haben, weil irgendwas nicht passt. Angefangen bei der Definition des Speichers.
Da muß wohl oder übel auch die Handschrift verbessert werden.. :-O TO, Eure Möglichleit: Detailliertes Pflichtenheft verwenden, damit das nötige RTOS von Anfang an festgelegt werden kann. Firmenstandard(s) schaffen, wie wird der Quelltext formatiert? IDE für alle Progger einheitlich einrichten. Polnische Notation in allen Objekten, Variablen und Funktionen einführen. Wenn möglich mit Namespaces arbeiten. Jedes Objekt, Modul oder Funktion bekommt ein eigenes CPP / H - Dateipaar. KOMMENTIEREN!! Wenn keine Objekte / Klasen verwendet werden, dateiprivate Funktionen statisch anlegen, in den Header gehört nur die Schnittstelle. Jede Funktion bekommt ein Review und wird danach in ne Bibliothek compiliert. Weil ja alles "getestet" ist (naja... ;-P) braucht man sich dann nun testmäßig "nur" um die Hauptschleife zu kümmern. :-)))) Achja: Wenn mehere Projekte mit dem gleichen Prozzi anstehen, ist das richtige RTOS plus deine wachsende Bibliothek ne Goldgrube! Ich danke meinen Ellis, Philippe Kahn und nicht zuletzt unserer geilen Weide für die Vorarbeit, das ich so einem geilen Hobby frönen kann! mfg
Hatte mehrere verkorkste Projekte redesigned. Da musst du zuerst mal einen Haufen Arbeit reinstecken, den dir niemand bezahlt. Zuerst alle Anforderungen rekonstruieren. Vor allen die Anforderungen, die sich nicht realisieren lassen. Musst rumlaufen, alle Leute fragen. Denn musst du dich in ein Dutzend Architekturen einarbeiten und die besten Ideen kombinieren. Ein überzeugendes Konzept ausarbeiten ist langweilige Bürokratie - tagelang überprüfen, ob eine Idee alle Anforderungen erfüllt. Wegwerfen und die nächste Idee überprüfen. Wenn du nach Wochen meinst, so ist es ideal - ein kompaktes Schaubild der Architektur zusammenstellen. Und eine Liste, mit der du zeigst, wie einfach sich die Anforderungen in der neuen Architektur realisieren lassen. Damit überzeugt du dann 2-3 Entwickler. Erst danach könnt ihr ein Budget für das Redesign beantragen.
P.S. Seit Scrum ist Architekturen ausarbeiten eine Sisyphos Arbeit. Bringt keinen Spaß mehr. Kommen ja dauernd neue Anforderungen rein. Eigentlich müsstest du da jedes mal überprüfen, ob die Architektur noch zu den Anforderungen passt, ob größere Umstrukturierungen erforderlich sind. Statt dessen wird in einem Sprint der erstbeste Schnellschuss dran gefrickelt und nach 2 Jahren ist deine mühsam ausgearbeitete Architektur genau so geschreddert wie euer heutiges Programm.
> Die Vorstellung, dass Linux oder FB auch am Reisbrett hätten entstehen > können mit Requirements und Doku vorweg und dann Umsetzung durch > Programmierer, ist weltfremd. Linux ist aber quasi am Reißbrett nach exakten Vorgaben entstanden. Die API-Schnittstellen wurden exakt nach den AT&T Vorgaben im POSIX-Standard geschrieben und nicht zuletzt "bediente" sich Linus heftig an Minix, ein Open Source Operatingssystem aus dem Universitären Bereich. Und Linux bringt Bücherweise Dokumantation und Styleguides mit, wenn die auch von manchen Codieräffchen ignoriert werden. https://linux-kernel-labs.github.io/refs/heads/master/lectures/intro.html Wenn man nach Beispielen für hingefrickelte OS ohne fundierte Vorüberlegungen sucht, wird man höchstens in der Müllhalde der bei Version 0.1 prealpha abgestorbenen Versuche "fündig".
Morty S. schrieb: > Linux ist aber quasi am Reißbrett nach exakten Vorgaben entstanden. > Die API-Schnittstellen wurden exakt nach den AT&T Vorgaben im > POSIX-Standard geschrieben Sich an Standards zu halten ist immer gut. Deine Aspekte sind das, was ich auch geschrieben habe: Bruno V. schrieb: > Wenn es vor einer SW-Entwicklung Requirements, Coderichtlinien etc. gab, > dann weil es das Dritte Projekt ist und alle sowieso wissen, wie es > geht. Heute vergessen wir, das Linux 2 Eltern hatte, die Unix "frei" machten. Neben Linus noch Richard, der alle Vorarbeit geleistet hat und der den Kernel am Reißbrett festlegen wollte. Und den deshalb heute keiner mehr kennt. (Anmerkung: Falls der TO das Budget zur Neuentwicklung bekommt, führt diesmal am Reißbrett natürlich kein Weg vorbei. Die Chance auf Erfolg von Budget UND Ergebnis ist aber gering)
:
Bearbeitet durch User
> (Anmerkung: Falls der TO das Budget zur Neuentwicklung bekommt, führt > diesmal am Reißbrett natürlich kein Weg vorbei. Die Chance auf Erfolg > von Budget UND Ergebnis ist aber gering) Nope, es ist sehr wahrscheinlich das man, falls man mit sauberen Konzept startet, etliches an Qualität (Stabilität) gewinnt und einiges an Ressourcen (Budget) einspart. Denn, "Eine Stunde programmieren spart 5 Minuten nachdenken". -- > Die Firmware beinhaltet derweil ca. 90 Komponenten > Diese Firmware oder auch Software Architektur ist nun sehr anfällig bei > Erweiterungen. Probleme wie nicht offensichtliche Abhängigkeiten, Naja, da gibt es drei einfache Prinzipien mit dennen man das bändigt, Datenkapselung, "Divide et impera" und EVA-Prinzip. Also schau dir anhand der Systembeschreibung/Requirement an, wo die Daten in das System hinEinfließen, wo hinAus und daraus ergibt sich wie die daten zwischen Ein- und Ausgabe Verarbeitet werden (müßen). Und damit man später nicht von einem Monolithen erschlagen wird, teilt man das in einzelne Subblöcke in denen man die (internen) Variablen kapselt (Keine globalen Variablen). Und diese Einteilung erreicht man durch Definition von Schnittstellen/Interface, die man möglichst innerhalb einer Funktionsgruppe standardisiert. Also gibt es beispielsweise ein Interface zum Sensor über die das Hauptprogramm kommuniziert (konfiguration, lesen) , ein Interface zum Aktor (Motor) (Start/Stop, Zustand abfragen, "konfigurieren"). Das sollte man IMHO erst ohne Blick in das (bereits implementierte) Code-Monster machen, um sich eine Vorstellung zu bilden, was die eigentliche Aufgabe der Software hier ist. Wenn das Konzept steht,(Systembeschreibung, Systempartionierung, Interface, interne Datenstrukturen) dann kann man in den Code schauen, was man dort vorfindet. Vielleicht muss man das Architekturkonzept geringfügig erweitern, aber die eigentliche Aufgabe ist es, den Code entsprechend des Konzeptes/Requirements zu schreiben und nicht umgekehrt.
Morty S. schrieb: > Also schau dir anhand der Systembeschreibung/Requirement an In akademischen Kreisen kann man vom Vorhandensein einer ausführlichen Systembeschreibung und ausführlich aufgelisteten Requirements ausgehen. In der harten Realität erbt man oft nur einen Haufen Dateien, die mit irgendeinem einem nicht unbedingt bekannten Entwicklungssystem genutzt wurden, um für ein Produkt, von dem man nur ein paar handgeschriebene Notizen findet, eine Firmware auszuwerfen. Die Fertigung, die selbst anständige Fertigungsunterlagen hat (sauber dokumentierter Schaltplan etc.), braucht jetzt eine neue/überarbeitete Firmware, weil der verwendete µC durch einen nicht binärkompatiblen ersetzt werden muss, und das vom alten Entwickler gelieferte Binary nicht mehr funktioniert. Der Entwickler, der den Kram bislang verbrochen hat, ist weg. Aus welchen Gründen auch immer.
Harald K. schrieb: > Der Entwickler, der den Kram bislang verbrochen hat, ist weg. Aus > welchen Gründen auch immer. Vielleicht, weil er den Chef zu sehr damit genervt hat, mehr Zeit für eine ordentliche Struktur und das Erstellen der fehlenden Dokumentation zu bekommen. Mir ging es jedenfalls in mehreren Firmen immer wieder so. Erst in der aktuellen Firma akzeptiert der Chef, dass Doku und Testen mehr kosten, als schnelles hin-sauen von Code.
:
Bearbeitet durch User
Der Thread zeigt wieder einmal, was unser Andy hier für kompetente Leute versammelt hat. Respekt! :-O Wie sollte der TO nun beginnen? Wenn ich mich in fremden Quelltexten umschaue, benutze ich ein UML- Programm oder ein altes Proggy von Siemens, "Easycode / Easycase", das aus Quelltexten Nassi-Shneiderman-Diagramme macht und umgekehrt. Was benutzen Profis heut so? C-Lion? mfg
> Wie sollte der TO nun beginnen? Kommt drauf an. Was ist das Ziel? Den Quelltext in eine lesbare Form bringen und danach wieder unkoordiniert Anforderungen dranfrickeln bis die heutigen Probleme wieder zurück kommen? Oder eine Vorgehensweise, mit der sich auch noch in ein paar Jahren Erweiterungswünsche umsetzen lassen? > Was benutzen Profis heut so? Üble Sache. Im Bauwesen gibt es unterschiedliche Arten von Profis. Die einen können Architekturen ausarbeiten. Die anderen können Statik berechnen. Noch andere können Bagger fahren... In der Softwareentwicklung gibt es nur mehr Profis für Codezeilen dranscrumeln. Gibt keine Profis für Anforderungslisten und Softwarearchitekturen.
Xanthippos schrieb: > >> Was benutzen Profis heut so? > > Üble Sache. Im Bauwesen gibt es unterschiedliche Arten von Profis. Die > einen können Architekturen ausarbeiten. Die anderen können Statik > berechnen. Noch andere können Bagger fahren... In der > Softwareentwicklung gibt es nur mehr Profis für Codezeilen dranscrumeln. > Gibt keine Profis für Anforderungslisten und Softwarearchitekturen. Ich ahnte es, auch Embarcadero fängt in seinem C++-Builder erst jetzt an auch an ein vernünftiges Testen und Refactoring zu denken. Und das auch noch mit Zuhilfenahme ner Fremdfirma, der "whole Tomato". Also alles von Vorn Neumachen? Da war doch UML mal "das Ding" in der Softwarearchitektur. Ist der Rausch inzwischen vorbei? mfg
> Da war doch UML mal "das Ding"
Das geht komplett am Problem vorbei.
Willst du eine erweiterbare Architektur ausarbeiten hast 2 große
Probleme.
Während Implementierung und Test kommen neue Anforderungen rein.
Eigentlich müsstest du die Änderungswünsche voraussehen und deine
Architektur für die unbekannten Anforderungen auslegen.
Bei dem Thema Firmware für MC gibt es schon 100 brauchbare Systeme.
Willst du etwas konkurrenzfähiges entwickeln, musst du erst mal die
guten Ideen und die Fehlentscheidungen aus den bestehenden Architekturen
rekonstruieren. Das bezahlt dir keiner, musst du in deiner Freizeit
machen.
Du musst zwar alte Anforderungen und Lösungsideen aus dem alten
Quelltext rekonstruieren. Aber damit findest du nicht mal 1/100 der
Anforderungen und Lösungen. Damit wird dein neues System auch nicht
besser als das alte.
Morty S. schrieb: > Nope, es ist sehr wahrscheinlich das man, falls man mit sauberen Konzept > startet, etliches an Qualität (Stabilität) gewinnt und einiges an > Ressourcen (Budget) einspart. Denn, "Eine Stunde programmieren spart 5 > Minuten nachdenken". Ich beziehe mich nur auf den TO. Die wenigen Informationen des TO (der sich ja schon verabschiedet hat), machen Szenarien wahrscheinlich, die eine Neuentwicklung schwierig machen. Mir scheint es, dass der TO wenig Erfahrung (<5 Jahre) als bezahlter SW-Entwickler hat und auch erst 1-2 Jahre dabei ist (weil er sonst konkreter geworden wäre). Wenn das Team klein ist, ist es oft auch das Budget und ein paar Mannjahre "zum schön machen" werden gar nicht erst bewilligt. Wenn das Team größer ist (>=3 Leute am Trunk und >=5 weitere Leute), dann wird er sein Blaues Wunder erleben: Ein paar der Altgedienten wissen auf einmal sehr genau, wie man es richtig macht. Nur einigen oder Verantwortung übernehmen, das werden sie nicht. (Das ist als "zweites System" bekannt)
Xanthippos schrieb: > Gibt keine Profis für Anforderungslisten und Softwarearchitekturen. Doch, die gibt es durchaus. Ich habe mut welchen arbeiten dürfen. Lotta . schrieb: > Da war doch UML mal "das Ding" in der Softwarearchitektur. > Ist der Rausch inzwischen vorbei? UML ist nur eine Sprache für Diagramme. Man kann gute Diagramme auch ohne UML erstellen. ML nimmt einem diese Arbeit nicht ab. Was mir gar nicht gefällt: Aus UML heraus Code zu generieren oder umgekehrt. Das macht alles nur unmötig umständlich. Dadurch gewinnt man zwar vollständige Diagramme, aber so vollständig sind sie schnell zu komplex, unverständlich, und dadurch nutzlos. Dann sind mir hand gemalte Bilder, welche die gerade relevanten Zusammenhänge darstellen (in UML oder nicht) dreimal lieber.
:
Bearbeitet durch User
Lotta . schrieb: > Wie sollte der TO nun beginnen? Sich andere Architekturen anschauen und deren Eigenschaften (Vor- und Nachteile) erforschen. Das Ziel von jeglicher Programmiersprache ist es, mit möglichst großer Ausdruckskraft Probleme zu lösen. Das gleiche gilt für die in dieser Sprache verwendete Architektur, Namenssystem, Funktionen etc. Jede Veränderung sollte die Ausdruckskraft steigern. Wenn Matlab/Simulink/Stateflow für Teilaspekte ausdrucksstärker ist, dann binde das ein. Wenn Codegeneratoren sinnvoll sind um Excel-Tabellen (die als Vorgabe reinkommen) in Code umzusetzen, dann mach das. Wenn die Variablen/Funktionen in der Programmiersprache auch der Fachsprache entsprechen können, dann nutze das (nichts ist schlimmer als unnötige Übersetzungen) > Wenn ich mich in fremden Quelltexten umschaue, benutze ich > ein UML- Programm oder ein altes Proggy von Siemens, > "Easycode / Easycase", das aus Quelltexten > Nassi-Shneiderman-Diagramme macht und umgekehrt. Honestly: die Sprache fließend lernen und geeignete IDEs benutzen. Zum lernen und als Darstellung für nicht-Programmierer mag das wirklich gut sein. Wenn Du eine Architektur maßgeblich ändern willst, musst Du Code flüssig lesen können, d.h. insbesondere überfliegen können. Wenn der Code nicht das tut, was er vorgibt, nützen dir kein Tool was. Dann geht es ans eingemachte (Profiling, Debugger, Lint, ... )
:
Bearbeitet durch User
No N. schrieb: > Diese Firmware oder auch Software Architektur ist nun sehr anfällig bei > Erweiterungen. Probleme wie nicht offensichtliche Abhängigkeiten, > schwere Lesbarkeit tun ihr übriges. Das klingt alles sehr ungut. Das alte Programmgerüst muß es vertragen, daß man neue Funktionen konfliktfrei hinzufügen kann. Geht das nicht, muß man es komplett wegschmeißen und neu von vorne anfangen. Man ist in einer Sackgasse gelandet und mindestens einer weiß es sogar.
Wow ich bin überwältigt! Danke bis hierhin. Bruno V. schrieb: > Ich beziehe mich nur auf den TO. Die wenigen Informationen des TO (der > sich ja schon verabschiedet hat), machen Szenarien wahrscheinlich, die > eine Neuentwicklung schwierig machen. Im Gegenteil. Ich verfolge die Diskussion zu jeder Zeit und denke dann erstmal nach. Ohne dir jetzt nahe treten zu wollen. Ich habe etwas länger wie fünf Jahre Softwareentwicklung auf dem Buckel, jedoch hatte ich es noch nie mit einem Refactoring dieser Größenordnung und solch vielfältigen Umständen gleichzeitig zu tun. Zum Thema Budget und Zeit: Beides ist genehmigt und man ist sich dessen bewusst, dass dies nicht auf einen Schlag funktionieren wird. Aktuell ist die Vorstellung das Refactoring inkrementell durchzuführen. Jedoch liegt hier mein Problem. Es soll gleichzeitig ein Refactoring und die Weiterentwicklung geschehen. Das Team nur für die Implementierung von Code umfasst ca. 15 Personen. Zum Thema Prozess: Auch dieser wird gerade im Unternehmen neu aufgestellt. Es ist Ziel in Zukunft nach dem Prinzip des V-Modells zu Entwickeln. Angefangen bei den Requirements - Architektur - Implementierung. Testing mit eingeschlossen. Dabei wird in Zukunft bei der Architektur die Software möglichst per UML geplant, dennoch nicht extrahiert. Hier soll der Entwickler seine Kreativität ausleben dürfen, sich jedoch an die Vorgaben halten. Meine Gedanken gerade: 1) Eine Handschrift ist zu lesen. Auch gibt es eine Trennung von Hardware-Modulen, zu Anwendungsmodulen. Ich sage explizit Anwendungsmodule, weil eine Applikationsebene ebenfalls besteht, in der sich jedoch eine Haupt-Statemachine befindet. Jedes Anwendungsmodul ebenfalls nochmal eine. Jedoch wüsste ich auf Anhieb nicht, zu welchem Typ ich die jetzige Architektur zuordnen würde. 2) Es gibt ein Anwendungsmodul welches über 6500 Zeilen Code beinhaltet. Ein klassischer Monolith. Mir erschließt sich noch nicht, wie ich das trimmen soll. Allein die Statemachine besteht hier aus 2500 Zeilen. Auch ist es vorgekommen, dass der Developer selbst, nicht mehr den eigenen Code versteht. 🚨🚨🚨 3) Der Code ist so aufgebaut, das sich verschiedene Varianten bauen lassen. Alles über #defines bzw. übers Makefile gesteuert. Man könnte anfangen, viele Funktionalitäten in Bibliotheken zu packen um daraus die Varianten zu bauen. Jedoch bedarf es auch hierfür zunächst einen riesen Umbau mit Anlehnung an eine neue Architektur-Idee. 4) Oft findet man jedoch Entourage anti-pattern im Code, welches das zertrennen einzelner Module fast unmöglich macht bzw. auch das Testing, welches so in seiner Form hinfällig ist, da nicht einzelne Module/Komponenten getestet werden können, sondern nur eine Abfolge von Modulen im ganzen. 5) Klassisches Beispiel bei der Fehlersuche: Man geht den Code durch in einem Gedankenexperiment angefangen bei Modul A, welches eine Funktion von Modul B aufruft. Nun wird eine statisch definierte Variable aus Modul B in dieser Funktion abgefragt, welche aber an gefühlt 100 weiteren Stellen benutzt / gesetzt wird. Es ist also de facto nun unmöglich das Gedankenexperiment weiter durchzuspielen, da mir der Zustand bzw. der Wert nicht bekannt ist. Ich müsste nun mit Mutmaßungen, weiterdenken. Kann man machen, jedoch ist das für mich ein Indiz dafür, das etwas gewaltig stinkt 💩 Lotta . schrieb: > Wenn ich mich in fremden Quelltexten umschaue, benutze ich > ein UML- Programm oder ein altes Proggy von Siemens, > "Easycode / Easycase", das aus Quelltexten > Nassi-Shneiderman-Diagramme macht und umgekehrt. Tatsächlich habe ich bereits mit entsprechenden Tools aufgerüstet, welche in der Lage sind die Architektur zu durchleuchten und auch grafisch darzustellen. Auch hier zeigt sich im Grunde genommen schon ein Teil der Problematik. Es ist primär ein Top-Down Ansatz zu sehen , gibt es dann oft circular dependencies bzw einen mix aus Top-Down und Bottom-Up. Bruno V. schrieb: > Das RTOS ist "proprietär" und durch Queues und Mailboxen "aufgepimpt". > Das ist für mich noch kein Indiz für Frickelware. Ich glaube zu jedem OS > gibt es Firmen, die eigene Queues oder Mailboxen gebaut haben, weil > irgendwas nicht passt. Angefangen bei der Definition des Speichers. Exakt. Jedoch war dieses proprietäre OS niemals für solche Anforderungen gedacht, wie sie heute umgesetzt werden oder wurden. Dies hat letzten endes auch zu diesen Monolithen geführt. Da ich ja den Code im Detail kenne, bin ich der Auffassung, das sich viel weg optimieren ließe, würde man z.B. ein FreeRtos nutzen, welches viele features anbietet und dadurch workarounds erspart blieben würden.
:
Bearbeitet durch User
Vielen Dank für die Rückmeldung. Das klingt alles sehr vernünftig! No N. schrieb: > Es gibt ein Anwendungsmodul welches über 6500 Zeilen Code beinhaltet. > Ein klassischer Monolith. Mir erschließt sich noch nicht, wie ich das > trimmen soll. Allein die Statemachine besteht hier aus 2500 Zeilen. Auch > ist es vorgekommen, dass der Developer selbst, nicht mehr den eigenen > Code versteht. 🚨🚨🚨 Wenn das nur eines der 90 Module ist, dann sorge Dich nicht. Das wäre eine normale "Verteilung" bei Anwendungen mit mehreren 100 kLoC. Bei 15 Programmieren findest Du Dreizeiler, wo der der Developer nicht weiß, was da passiert. No N. schrieb: > Der Code ist so aufgebaut, das sich verschiedene Varianten bauen lassen. > Alles über #defines bzw. übers Makefile gesteuert. Varianten im Sinne von USE_MODUL_A? Oder bestimmen #defines, ob in Modul A Sensor7 oder 8 verwendet wird oder Methode 4 statt 7. Das erste kann man schnell umbauen, dass zweite klingt nach C und größeren Problemen. (Falls es C ist, solltest Du die Sprache nicht nennen :-) No N. schrieb: > da nicht einzelne Module/Komponenten getestet werden können, > sondern nur eine Abfolge von Modulen im ganzen. Das kann Nachlässigkeit sein, oder (in autonomen Embedded Systemen) manchmal dem globalen Kontext (der physikalischen Welt) geschuldet sein. No N. schrieb: > Da ich ja den Code im Detail > kenne, bin ich der Auffassung, das sich viel weg optimieren ließe, würde > man z.B. ein FreeRtos nutzen, welches viele features anbietet und > dadurch workarounds erspart blieben würden. Kapsel die Workarounds so, wie Du es mit einem "richtigen" RTOS machen würdest. Dann steht dem Wechsel später nichts im Wege. Wenn Du ein Ziel hast oder erkennen kannst, Nutze Wrapper, die so funktionieren als wäre das Ziel schon erreicht.
Bruno V. schrieb: > solltest Du die Sprache nicht nennen :-) Wurde schon in der Überschrift genannt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.