Hallo zusammen, Ich bin 22 Jahre alt und arbeite als Programmierer im Bereich Mikrocontroller. Ich kann sehr gut C programmieren und die module eines Mikrocontrollers auch optimal einsetzen. Was ich mehr lernen sollte ist wie man eine geeignete Architektur der Software baut und auch in die Richtung Optimierung der Software. Hat dazu jemand ein gutes Buch oder einen Kurs? :-) Lg Christof
https://de.wikipedia.org/wiki/Clean_Code Gibt zwar wenig Architektur-Hinweise, dafür hilft es aber enorm, "sauberen" Code zu schreiben (Das Buch von Robert C. Martin) kann ich auch nur empfehlen. merciless
Hallo Christof, was das Buch von Robert "Uncle Bob" Martin angeht, kann ich Dirk nur beipflichten - das sollte meines Erachtens nach jeder professionelle Programmierer einmal gelesen und zumindest zur Kenntnis genommen haben. In diesem Buch lernst du die Grundtugenden für einen sauberen Feinentwurf und eine ordentliche Implementierung*. Das ist natürlich nicht das Ende der Fahnenstange, denn falls du einmal an größeren Systemen arbeitest merkst du schnell: Stimmt die Architektur im Groben nicht (und hapert's womöglich noch im Team), kannst du noch so ein guter Programmierer sein, den Karren bekommst du so nicht mehr aus dem Dreck ;-) Für die Programmierung im Kleinen reicht's aber allemal. Robert C. Martin schreibt aus der Perspektive eines Java-Programmierers, also aus einer objektorientierten Sichtweise (mit Klassen, Paketen, relativem Ressourcenreichtum, Garbage Collection etc.). Vieles lässt sich aber grundsätzlich auch auf die C-Programmierung übertragen. Für konkretere Hinweise, bzw. für Ergänzungen bezüglich ressourcenlimitierter Systeme lohnt sich eine Suche nach Büchern über "Embedded Architecture". Viele Grüße Lucas * eigentlich sollte man die ja bereits in der Ausbildung / im Studium lernen. Die Realität in Deutschland sieht leider vielerorts anders aus...
Dirk K. schrieb: > https://de.wikipedia.org/wiki/Clean_Code > > Gibt zwar wenig Architektur-Hinweise, > dafür hilft es aber enorm, "sauberen" > Code zu schreiben (Das Buch von Robert > C. Martin) kann ich auch nur empfehlen. > > merciless Stimme voll zu. Ich würde sogar die ganze Buchreihe von Uncle Bob zu diesem Thema empfehlen.
:
Bearbeitet durch User
Ansonsten sind die MISRA C/C++ auch einen Blick wert. Mancherorts muss man die Firmware explizit nach diesen Kriterien prüfen lassen. Die neusten Versionen finde ich gerade nicht (könnten auch kostenpflichtig sein), aber die ist immer noch gut. http://caxapa.ru/thumbs/468328/misra-c-2004.pdf Ausserdem sind Kommentare und File-Strukuren/Gruppen mit Doxygen auch sehr nützlich. Da sieht man gleich was zusammengehört und man hat die Arbeit nur einmal.
Das Thema war "SW-Architektur" und nicht Coding, Coding-Guidelines, statische Code-Analyse o.ä.
sgg schrieb: > Das Thema war "SW-Architektur" und nicht Coding, Coding-Guidelines, > statische Code-Analyse o.ä. Sehe ich auch so. Wer bei dem Thema MISRA und Co ins Spiel bringt, hat gar nicht verstanden worum es geht.
sgg schrieb: > Das Thema war "SW-Architektur" und nicht Coding, Coding-Guidelines, > statische Code-Analyse o.ä. Entschuldigung, für mich gehört ein sauberes Source-File auch ein wenig zur Architektur. Und speziell zu C kann ich nicht mehr viel sagen als das was ein "guter" Programmierer schon können sollte (private/public, Schnittstellen, Interface, CallBack, in sinnvolle Files auftrennen, ISO-OSI Modell, HALL, Blocking/non-Blocking Funktionen, FSM...). Ich bin seit längerem in der OOP-Welt unterwegs und da sind ganz andere Architektur-Ansätze als das halt mit C möglich ist.
:
Bearbeitet durch User
Ich denke, dass man ohne mehrjährige Erfahrung in unterschiedlichen Projekten nicht Softwarearchitekt werden kann. So etwas lernt man nicht aus einem Buch oder Video.
Patrick B. schrieb: > Ich bin seit längerem in der OOP-Welt unterwegs und da sind ganz andere > Architektur-Ansätze als das halt mit C möglich ist. Es gibt aber keinen Grund, keine vernünftige SW-Architektur zu erstellen, auch wenn in C implementiert wird.
Patrick B. schrieb: > Ich bin seit längerem in der OOP-Welt unterwegs und da sind ganz andere > Architektur-Ansätze als das halt mit C möglich ist. Einige OOP-Ansätze kann man auch in reinem C fahren.
Dirk K. schrieb: > Gibt zwar wenig Architektur-Hinweise, > dafür hilft es aber enorm, "sauberen" > Code zu schreiben (Das Buch von Robert > C. Martin) kann ich auch nur empfehlen. Von Martin gibt es auch das Werk "Clean Architecture", was hier vielleicht besser passt als "Clean Code". Dort gibt es kaum Code zu sehen, und die angesprochenen Programmierparadigmen und Designprinzipien sind universell anwendbar. Stichwörter: structured, object-oriented, functional programming single responsibility principle open-closed principle Liskov substitution principle interface segregation principle dependency inversion principle component cohesion, coupling separation of concerns layers and boundaries und vieles mehr. Der Herr schreibt auch Blogs wie http://blog.cleancoder.com/uncle-bob/2014/01/27/TheChickenOrTheRoad.html, in dem z.B. das Stichwort "Event Driven" fällt, das ja recht gut zu interaktiven und timer-getriggerten µC-Anwendungen paßt.
:
Bearbeitet durch User
Markus L. schrieb: > structured, object-oriented, functional programming > single responsibility principle > open-closed principle > Liskov substitution principle > interface segregation principle > dependency inversion principle > component cohesion, coupling > separation of concerns > layers and boundaries > und vieles mehr. Meist setzt das OOP-sprachen voraus und beschreibt nicht die Umsetzung in plain C. > Der Herr schreibt auch Blogs wie > http://blog.cleancoder.com/uncle-bob/2014/01/27/TheChickenOrTheRoad.html, > in dem z.B. das Stichwort "Event Driven" fällt, das ja recht gut zu > interaktiven und timer-getriggerten µC-Anwendungen paßt. Wenn Event driven fällt, dann ist es sehr wichtig, das Gegenkonzept (SPS-Loop) zu kennen und zu wissen, wann was besser ist.
Architekur war und ist schon immer hochgradig vom Zeitgeist abhängig. Duck und weg :-)
Achim S. schrieb: > Meist setzt das OOP-sprachen voraus und beschreibt nicht die Umsetzung > in plain C. Wie kommst Du darauf? Sag bloß, man kann in C nicht strukturiert programmieren. Objektorient geht auch, siehe X Toolkit, muß man sich aber nicht unbedingt antun. Funktionales Programmieren in C fängt damit an, nicht ständig void-Funktionen zu schreiben. Das Single Responsibility Principle setzt man in C z.B. mit klar voneinander abgegrenzten Modulen um. Dito Open-Closed Principle: sinnvoller Schnitt der Module. Geht auch mit Directories, wenn es mehr als ein Modul ist. Liskov Substitution Principle: ok, dort geht es um Vererbung, was auch in C geht, aber nur mit entsprechendem Zusatzaufwand. Beim Interface Segregation Principle geht es um unnötige Abhängigkeiten, die man auch in C auflösen kann. Funktionszeiger existieren. Das Dependency Inversion Principle ist nicht sprachabhängig, dito Component Cohesion and Coupling, Separation of Concerns und Layers and Boundaries. Hat nicht jeder schon mal Schichtenarchitekur in C betrieben? Oder modular programmiert? Oder hat sich mal verfranst und alles umstruktiert und dabei über die Abhängigkeiten der jeweiligen Funktionen und Module zueinander und deren tatsächlichen Aufgabengebiete nachgedacht? Nicht alle sind Spaghettiprogrammnierer. Schichtenarchitektur vs. Onion Architecture z.B. hat etwas mit dem Dependency Inversion Principle zu tun. Abstraktion funktioniert auch in C, jeder Device Driver konkretisiert ein abstraktes Interface.
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.