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.
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.
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.
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.
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.
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.