Software Architektur in C

Gast #5528798
Lesenswert?

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
Gast #5528902
Lesenswert?

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...
#5528994
Lesenswert?

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.
#5529032
Lesenswert?

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.
#5532616
Lesenswert?

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.
Gast #5532742
Lesenswert?

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.
#5532869
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren