Guten Morgen,
ich möchte hier ja keinesfalls nerven, habe aber das Bedürfnis, mir
meinen Frust von der Seele zu reden: Gerade angefangen in einer Firma
als Embedded Entwickler gefällt es mir im großen und ganzen recht gut
und die Kollegen und Chefs sind entgegenkommend und nett. Einzig und
alleine komme ich jedoch mit dem hier gängigen Codierungsstil nicht
zurecht. Es geht um ein recht großes Projekt; typische C Funktionen
haben um die 3000 Zeilen Code, es gibt sogar einzelne Funktionen, die es
auf 10000 Zeilen und mehr bringen. Da passiert in einer Funktion ALLES,
keine Trennung in Funktionsgruppen, oder Module, Seitenweise if-else
(teilweise verschachtelt bis zu 10 Stufen), tonnenweise verschachtelte
switch statements, fast ausschließlich globale Variablen, unzählige Male
der gleiche Code an verschiedenen Stellen mit copy/paste verteilt...: Es
ist purer Spaghetticode!!! Nicht einmal Übergabeparameter werden
verwendet, da sowieso alles global definiert ist. Und wenn man dann
etwas sagt, dann heißt es, dies wäre in der Embedded Welt üblich, und
unter Assembler haben wir das auch so gemacht...Wenn ich an einer Stelle
etwas ändern möchte, habe ich meistens keine Chance, dies ohne den
Ersteller der Funktion zu tun, da es dann an unzähligen anderen Stellen
zu Problemen kommt ;-) Ich werde nun angehalten, ebenso zu
programmieren, jedoch sträubt sich in mir alles dagegen, dies so
hinzunehmen. Im Gegensatz zu meinen derzeitigen Kollegen waren meine
Funktionen selten länger als 100 Zeilen, und ich legte immer großen Wert
auf Trennung voneinander unabhängiger Komponenten.
Ich habe die Befürchtung, hier in eine berufliche Sackgasse zu geraten
und denke bereits darüber nach, mir etwas anderes zu suchen... Kann mir
jemand raten, wie ich hier vorgehen sollte? Auf diese Weise macht mir
die Tätigkeit des Programmierens (eigentlich) keinen Spaß...Oder bin ich
etwa "falsch gepolt" und man tut dies wirklich so?
Danke !
Bei Projekten in der Größe ist C das falsche Tool. Hier nimmt man C++ u
d macht das mit OOP.
Du kannst das in der Firma einführen und wirst zum Helden. :-)
Wenn ich die Zeilen von Dir lese, kann ich Dir nur zustimmen.
Alleine schon die Worte globale Variablen, keine Kapselung, hohe
Verschachtelungstiefe usw. usw. geht auch in der Embedded Welt GARNICHT
:-)
Ich kann Dir nur den Tipp geben einen Chef oder ähnliches auf Deine
Seite zu bekommen und Coding-Richtlinien einzuführen.
Man kann ja noch viel unterteilen wann was zwingend eingehalten werden
muss und wann gewisse Dinge lockerer gesehen werden können oder sogar
begründet ganz vernachtlässigt werden können.
Aber einen gewissen Rahmen sollte es schon geben.
Das Ganze kann dann auch soweit getrieben werden, dass Code erst
garnicht mehr eingechecked werden kann wenn man sich nicht an gegebene
Richtlinien hält ;-)
Es ist fast aussichtslos, hier C++ einzuführen:
* Erstens habe ich nichts zu sagen
* Zweitens wird über C++ abwertend geredet und niemand weiß auch nur
annähernd, was überhaupt eine Klasse ist. Wir haben das nie gebraucht
und werden es nie brauchen...
Davon abgesehen, glaube ich, dass man auch unter C strukturiert
entwickeln kann, wenn man gewisse Regeln beachtet.
Aber was nützt das, ich jammere nur ...
Wie alt sind die Kollegen, die in dieser Firma so arbeiten?
Wie auch immer: Du musst mit ihnen arbeiten, nicht gegen sie. Den Chef
dazu zu bringen, Codierungsrichtlinien einzuführen, ist keine gute Idee,
denn damit wirst Du die erfahrenen Mitarbeiter gegen Dich aufbringen.
Auch wenn deren Codierungsstil schrecklich ist, er wird bei
ausreichender Erfahrung seitens des Nutzers auch funktionieren. Die
Firma wird es schon eine Weile geben, und ihre Produkte werden einen
gewissen Erfolg haben, sonst gäbe es den Laden nicht.
Bei solchen tiefgreifenden Änderungen an Grundstrukturen muss man
vorsichtig und langsam vorgehen; wer zwanzig oder dreißig Jahre lang
Spaghetticode geschrieben hat, kann das, und findet sich darin auch
zurecht, aber der wird erhebliche Zeit brauchen, seinen etablierten
Programmierstil umzustellen. Und nicht nur Zeit, sondern auch
Verständnis, denn der bisherige Stil war ja aus seiner Sicht auch
erfolgreich, weil er zum Ziel geführt hat.
Auf was für Systemen wird in dieser Firma gearbeitet? Eine µC-Familie,
oder deren mehrere, werden Betriebssysteme verwendet, oder ist das alles
"bare metal"?
Ja, es scheint alles zu funktionieren, jedoch sind da Typen am Werk, die
seit 20 Jahren das gleiche machen und mit Assembler angefangen haben.
Fällt einer aus, so kann der Laden zusperren (das meine ich nun nicht
nur sarkastisch, sondern ernst).
ist auch alles bare-metall, da man Betriebssystemen nicht über den Weg
traut.
Statt auf ein ordentliches RTOS zu setzen, wurden haarsträubende
Kunststücke eingeführt, die zur weiteren Unlesbarkeit des Codes
beitragen.
verwirrter schrieb:> Ja, es scheint alles zu funktionieren, jedoch sind da Typen am Werk, die> seit 20 Jahren das gleiche machen und mit Assembler angefangen haben.> Fällt einer aus, so kann der Laden zusperren (das meine ich nun nicht> nur sarkastisch, sondern ernst).
zwei möglichkeite:
- hau da ab und sag ihnen zum abschied das sie ihren scheiß code selbst
pflegen sollen.
- lerne den unwartbaren code kennen und mach dich damit zu einem
wichtigen mitarbeiter den man nicht leicht kündigen kann.
Love it, change it or leave it. Mehr Möglichkeiten hast Du nicht.
Gibt es vielleicht ein kleineres (neues) Projekt, das Du alleine
übernehmen kannst? Dort könntest Du demonstrieren, wie sauberer Code
aussehen kann und welche Vorteile er hat. Du musst auf jeden Fall Leute
auf Deine Seite bringen, die auch etwas ändern wollen. Mindestens einer
davon muss auch etwas zu sagen haben (Guru, Projektleiter,
Vorgesetzter). Das ganze wird in jedem Fall Jahre dauern, aber wenn Du
gut bist und Glück hast, bist Du danach der Held.
Wenn das nicht fruchtet und Du bei allen auf Ablehnung stößt, musst Du
entscheiden: Jahrelang weiter Dienst nach Vorschrift ohne Begeisterung
machen, d.h. ebenfalls Murks produzieren. Oder aufraffen und etwas
anderes suchen.
Ein Unternehmen, bei dem Du mit allen Code-Richtlinien einverstanden
bist, jeder Entwickler hochkompetent ist und jeder darauf bedacht ist,
perfekt wiederverwendbaren und lesbaren Code zu schreiben, wirst Du
allerdings nicht finden. Und wenn, dann ist es wahrscheinlich
wirtschaftlich nicht erfolgreich. Kommerzielle Softwareentwicklung ist
nun mal leider nicht nur Idealismus, sondern funktionierende Lösungen im
vorgesehenen Zeit- und Kostenrahmen zu produzieren.
So wie Du die Zustände beschreibst, ist es aber weit mehr als hier und
da ein pragmatischer Hack, sondern gänzlich unwartbare Software. Das ist
längerfristig auch nicht wirtschaftlich sinnvoll, da im Vergleich zu
vernünftig strukturierter Software jede Änderung mit hohem Aufwand und
dem Risiko, etwas kaputt zu machen, verbunden ist. Ich würde so auf
Dauer nicht arbeiten wollen.
Ich habe mal als externer Entwickler etwas für so eine Bude gemacht
(Hardware mit Firmware, bare metal), weil die unter Zeitdruck standen
und schnell eine Lösung brauchten.
Eigentlich sollte mein Code auf deren Code aufbauen, es seien "nur ein
paar kleine Anpassungen nötig". Nachdem ich gesehen hatte, was die da
machen, bin ich vom Hocker gefallen. Das waren auch ehemalige
Assembler-Programmierer, die ständig mittendrin aus irgendwelchen
Schleifen rausgesprungen sind oder diverse Sachen schon im Quellcode
"ge-inlined" haben.
Ich habe dann mit dem Projektleiter (eigentlich studierter Ing., aber
eher Manager, keinerlei Einblick in die technischen Details) eine Weile
gesprochen und ihm vorsichtig erklärt, dass seine Jungs
- erfolgreich mit ihrer Methode arbeiten und das auch ok ist
- diese Methode nicht mehr dem aktuellen Standard entspricht
- ich nicht mehr gelernt habe, nach dieser Methode zu arbeiten
- die "neue Methode" aber auch für ältere Semester leicht zu lesen und
anzuwenden ist
- ich schneller zum Ziel komme, wenn ich die Software für meine Hardware
selbst schreibe, anstatt vorhandenen Code zu verwenden
- dass es für die Zukunft nur von Vorteil sein kann, wenn die
Grundfunktionalität (RTOS + Treiber für die Peripherie) in einer zweiten
Variante, erstellt nach der "neuen Methode", zur Verfügung steht.
Dafür bekam ich dann grünes Licht. Natürlich war das nicht die komplette
Wahrheit, aber es ermöglichte mir erstmal, innerhalb des vereinbarten
Zeitraums ein Ergebnis abzuliefern. Wie ich aufgrund eines weiteren
Auftrages ein Jahr später herausgefunden habe, benutzen sie mittlerweile
mein Grundgerüst, schreiben allerdings die Applikation obendrauf
weiterhin nach ihrer alten Methode.
Das sieht man an solchen Variablennamen:
"usart_schleife_innen_zaehler1"
Guter oder Schlechter Coding-Style hin oder her, das ist eine
Firmeninterne Sache, Punkt.
Außerdem müsst ihr mal drüber nachdenken was eine umstellung des Codes
bedeutet... Stichwort: SQS!
Bei uns würde das heißen, das Code, der super Funktioniert, getestet
wurde und sich bewährt hat, ein zweites mal getestet werden muss.
Bei uns würde das bedeuten, pro code-projekt: mind. 2 Monate Testaufwand
+ Entwicklungszeit, mind. 1-2 Leute von SQS und 2-3 Entwickler. Bei ca.
50 Projekten...also gut 1 Jahr keine neuentwicklungen.
Kann sich die Firma das leisten? Also wir können es nicht...
Das ist halt so mit Projekten die wachsen. Leb damit oder mach dich
selbstständig, wo du dann deinen Perfekten Code produzieren kannst, wie
es dir beliebt.
Das Leben ist halt kein Wunschkonzert.
verwirrter schrieb:> Einzig und> alleine komme ich jedoch mit dem hier gängigen Codierungsstil nicht> zurecht. Es geht um ein recht großes Projekt; typische C Funktionen> haben um die 3000 Zeilen Code, es gibt sogar einzelne Funktionen, die es> auf 10000 Zeilen und mehr bringen.
Wilkommen in der wirklichen Welt...
Du beschwerst dich über C-Code? Wir haben Shell-Scripte die mehr als
2000 Zeilen haben... Kannst dir aussuchen was dir lieber ist: 10k Zeilen
C-Code oder 2k Zeilen Shell-Script.
Wenn du mal (meiner Meinung nach) schlechten Code sehen willst, schau
dir mal Log4Cxx an... C++- Klassen/vererbungs/Template gedingse vom
Feinsten... und dann mitten im Code Magic-Numbers. BAAM! DAS ist meiner
Meinung nach scheiße!
verwirrter schrieb:> Davon abgesehen, glaube ich, dass man auch unter C strukturiert> entwickeln kann, wenn man gewisse Regeln beachtet.>> Aber was nützt das, ich jammere nur ...
Strukturiert aber nicht OOP!
Große Projekte in C ist wie mit einer Cessna nach Übersee fliegen. Es
geht, ist aber eher was für Abenteurer oder andere Extremsportlet. :-)
@ verwirrter (Gast)
>zurecht. Es geht um ein recht großes Projekt; typische C Funktionen>haben um die 3000 Zeilen Code, es gibt sogar einzelne Funktionen, die es>auf 10000 Zeilen und mehr bringen. Da passiert in einer Funktion ALLES,>keine Trennung in Funktionsgruppen, oder Module, Seitenweise if-else>(teilweise verschachtelt bis zu 10 Stufen), tonnenweise verschachtelte>switch statements, fast ausschließlich globale Variablen, unzählige Male>der gleiche Code an verschiedenen Stellen mit copy/paste verteilt...: Es>ist purer Spaghetticode!!!
Aua!!!
> Nicht einmal Übergabeparameter werden>verwendet, da sowieso alles global definiert ist.
Aua^2!
> Und wenn man dann>etwas sagt, dann heißt es, dies wäre in der Embedded Welt üblich, und>unter Assembler haben wir das auch so gemacht...
Das ewige "Argument" alter Leute, die den Anschluss verpasst haben.
>Wenn ich an einer Stelle>etwas ändern möchte, habe ich meistens keine Chance, dies ohne den>Ersteller der Funktion zu tun, da es dann an unzähligen anderen Stellen>zu Problemen kommt ;-)
Logisch.
> Ich werde nun angehalten, ebenso zu>programmieren, jedoch sträubt sich in mir alles dagegen,
Würde mir genau so gehen.
>dies so>hinzunehmen. Im Gegensatz zu meinen derzeitigen Kollegen waren meine>Funktionen selten länger als 100 Zeilen,
Naja, darüber kann man streiten. Aber über die Grundlagen von
Fiunktionsparameter, Kapselung etc. nicht.
> und ich legte immer großen Wert>auf Trennung voneinander unabhängiger Komponenten.
Was nur normal ist.
>Ich habe die Befürchtung, hier in eine berufliche Sackgasse zu geraten
Das ist auch so. Verblödung per Befehl. Nein Danke!
>und denke bereits darüber nach, mir etwas anderes zu suchen...
Kann man ja unverbindlich nebenbei machen.
> Kann mir>jemand raten, wie ich hier vorgehen sollte? Auf diese Weise macht mir>die Tätigkeit des Programmierens (eigentlich) keinen Spaß...
Es giht hier weniger um Spaß als um Verblödung und Verbiegung. Damit
wirst du AKTIV untauglich für dein späteres berufsleben. Das will
keiner.
>Oder bin ich>etwa "falsch gepolt" und man tut dies wirklich so?
Nein! Klar gibt es Ausnahmen, und bei KLEINEREN Projekten ist das in
Grenzen OK. Hatte ich mal bei einem kleinen MSP430. Aber das waren
gerade mal 16kB Flash! Aber sobald es ETWAS größer wird, ist dieser
Ansatz sinnlos und kontraproduktiv. Und in vielen Projekten ist es
unkritisch, ob man eine handvoll kB Flash mehr oder weniger braucht.
Wenn deine Firma so weiter wursten will, bitte, es ist ihr gutes Recht.
Aber ebenso ist es deins, deine Fähigkeiten von den ewig Gestrigen nicht
degenerieren zu lassen.
@ Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
>Wie auch immer: Du musst mit ihnen arbeiten, nicht gegen sie. Den Chef>dazu zu bringen, Codierungsrichtlinien einzuführen, ist keine gute Idee,>denn damit wirst Du die erfahrenen Mitarbeiter gegen Dich aufbringen.
Stimmt. Das ist in 1. Linie es stategisch-psychiologisches Problem.
Denn selbst wenn das Greenhorn 10mal Recht hat, es wird nicht recht
bekommen, denn dann ständen ja alle Etablierten dumm da.
>Auch wenn deren Codierungsstil schrecklich ist, er wird bei>ausreichender Erfahrung seitens des Nutzers auch funktionieren. Die>Firma wird es schon eine Weile geben, und ihre Produkte werden einen>gewissen Erfolg haben, sonst gäbe es den Laden nicht.
Sicher, nichts ist so langlebig wie ein Provisorium ;-)
>vorsichtig und langsam vorgehen; wer zwanzig oder dreißig Jahre lang>Spaghetticode geschrieben hat, kann das, und findet sich darin auch>zurecht, aber der wird erhebliche Zeit brauchen, seinen etablierten>Programmierstil umzustellen. Und nicht nur Zeit, sondern auch>Verständnis, denn der bisherige Stil war ja aus seiner Sicht auch>erfolgreich, weil er zum Ziel geführt hat.
Stimmt. Aber warum soll man sich von solchen Holzköpfen in die Suppe
spucken lassen? Sollen sie ihren Stiefel machen. Ich mach meinen.
Man muss nicht seine Energie und zeit verschwenden, ignorante Leute
schlau zu machen.
Falk Brunner schrieb:> Man muss nicht seine Energie und zeit verschwenden, ignorante Leute> schlau zu machen.
Möchte man mit ihnen zusammen in einer Firma beschäftigt werden und
bleiben, ist das aber hilfreich.
Eines der Stichworte lautet hier "Teamfähigkeit".
Teamfähigkeit ist gut und richtig, aber ich sehe das hier wie Falk: Man
sollte sich selbst nicht verbiegen. Der Chef hat ihn wegen seiner
Fähigkeiten eingestellt und erhofft sich einen Produktivitätsgewinn
durch ihn. Ein guter Mitarbeiter generiert mehr Benefit, als er kostet.
Und wenn "verwirrter" nicht ohne fremdhilfe an Programmen arbeiten kann,
ist er nicht produktiv und so auch nicht profitabel. Das wird früher
oder später in einem Personalgespräch enden. Die einzigen zwei
Möglichkeiten sind mmn. Frühzeitig die obigen Punkte anzusprechen, oder
einen Schlussstrich zu ziehen.
verwirrter schrieb:> Davon abgesehen, glaube ich, dass man auch unter C strukturiert> entwickeln kann
Natürlich kann man das. Genau dafür wurde C entwickelt. Nämlich als
Makroassembler, der die Asm-Details vor dem Programmierer versteckt und
in einer strukturierten Syntax präsentiert. Viel mehr ist C allerdings
auch nicht. Der minimale Vorteil gegenüber Asm wird überdies mit
unsäglich perversen Syntax-Blähungen erkauft, die (vor allem bei
mißbräuchlicher Verwendung) den Quelltext sogar weniger lesbar machen
können als es ein adäquater Asm-Quelltext wäre.
Das hat allerdings überhaupt nichts mit dem Unterschied zwischen C und
C++ zu schaffen, der wirklich evident ist. Strukturiert programmieren
kann (und sollte) man in beiden Sprachen. C++ bietet aber darüber hinaus
die syntaktische Unterstützung für die Kapselung von Daten und
Zugriffsmethoden darauf, also von Objekten. Das geht notdürftig
allerdings auch mit diesem unsäglichen C (mit expliziter Übergabe von
[immerhin typisierbaren] Instanzenzeigern).
Was aber in C nicht mehr wirklich nachvollziehbar realisierbar ist, sind
die eigentlichen Goodies von OOP: Vererbung und Polymorphie. Genau
deswegen ist C++ wirklich eine nützliche Hochsprache (wenn auch mit
C-artig gräßlicher Syntax-Erblast), während C auf ewig nur ein unnützer
Macroassembler mit fürchterlich aufgeblähter Syntax bleiben wird.
Oh Mann, das wird jetzt sicher wieder von den C-Apologeten gelöscht, die
hier Moderator spielen und diese Macht regelmäßig mißbräuchlich zur
Unterdrückung abweichender Meinungen (insbesondere zum Thema C)
benutzen.
D'rauf geschissen. Zumindest ein paar Leute werden wahrscheinlich die
Wahrheit lesen, bevor sie unterdrückt wird. Nicht viel Wirkung, aber
immer noch besser als gar keine.
Kaj schrieb:> Das ist halt so mit Projekten die wachsen.
Nein, so ist es überhaupt nicht. So ist es mit Projekten, wo sich die
Leute keine zwei Stunden Zeit zu nehmen, um eine vernünftige
Grundarchitektur zu planen. Und wo man sich als hemdsärmelige Macher
sieht, wo man ja nicht etwas aus der akademischen Welt (nämlich diverse
gute Programmierkonzepte) benutzen will, denn das sind ja böse
Theoretiker, die keine Ahnung von der richtigen Welt haben...
hero schrieb:> Große Projekte in C ist wie mit einer Cessna nach Übersee fliegen. Es> geht, ist aber eher was für Abenteurer oder andere Extremsportlet. :-)
Es geht sehr wohl. Wenn man gut strukturiert und plant, so geht es sogar
in Assembler.
@ Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
>> Man muss nicht seine Energie und zeit verschwenden, ignorante Leute>> schlau zu machen.>Möchte man mit ihnen zusammen in einer Firma beschäftigt werden und>bleiben, ist das aber hilfreich.
DAS ist eben die Frage! Möchte bzw. KANN man das?
>Eines der Stichworte lautet hier "Teamfähigkeit".
Sicher, aber das ist keine Einbahnstraße und auch keine Gehirnwäsche.
Klar muss man Kompromisse eingehen, als Neuling umso mehr. Aber alles
hat seine Grenzen. Mit betonköpfigen Menschen hatte ich schon zu tun.
Ich wollte sie auch mal schlau machen. Bis ich selber schlau geworden
bin, und sie NICHT mehr schlau machen wollte. ;-)
Man kann durch ein Schlagloch fahren oder drum herum.
Falk Brunner schrieb:> DAS ist eben die Frage! Möchte bzw. KANN man das?
Die Fragestellung des Threaderstellers ließ mich das annehmen.
Wenn man die wirtschaftliche Unabhängigkeit hat, die es einem
ermöglicht, einen neuen Job wegen derlei Anpassungsproblemen gleich
wieder hinzuwerfen, dann kann man das ja tun.
Kaj schrieb:> Wilkommen in der wirklichen Welt...
Nein, diese Pfuscher sind es, die in einer Scheinwelt leben! Diesen
Pfusch kann man sich nämlich einzig und alleine in der Software-Welt
erlauben, weil nie ein Kunde/Benutzer den Code sieht. In jedem anderen
"Handwerk" würde man für so eine Arbeitsweise schon am allerersten Tag
gehörig was auf die Ohren bekommen.
Selbst der windigste Gipser oder Autohändler weiss, dass sein Pfusch
nicht ok ist und er irgendwann auffliegen könnte, mit bösen
Konsequenzen. Aber Programmierer verteidigen diesen Stil noch als gute
(oder zumindest annehmbare) Arbeitsweise.
Klar, man mag jetzt argumentieren, der Code sei halt so gewachsen und
man könne sich keine Restrukturierung leisten. Auch so eine Denkweise,
die es nur in der Softwarebranche gibt. In jeder anderen Branche ist es
völlig normal, dass bei wachsenden Strukturen irgendwann eine neue
Grundstruktur her muss. Ein Haus kann man nicht beliebig erhöhen.
Restrukturiert man nie und bläst lieber die alte Software immer weiter
auf, so kann man zwar günstiger anbieten. Man muss sich aber auch im
klaren darüber sein, dass man eigentlich Pfusch betreibt. Wenn der Kram
dann irgendwann definitiv um die Ohren fliegt, dann haben es diese
Firmen auch nicht anders verdient.
P. M. schrieb:> Auch so eine Denkweise, die es nur in der Softwarebranche gibt.
In der Embedded-Branche vielleicht, wenn der Code einmal dahingerotzt,
geflasht und vergessen wird.
Bei richtiger Softwareentwicklung (die nicht von ETechnikern sondern von
Informatikern betrieben wird) ist eine saubere und gut geplante
Softwarearchitektur von größter Wichtigkeit, der viel Zeit & Geld
gewidment wird - was sich dann bei späteren Änderungswünschen auszahlt.
Das ist eine Wissenschaft für sich.
Auf "richtigen" Computern hat man ja typischerweise noch ganz andere
Größenordnungen an Programmgrößen & komplexität als bei Embedded...
Und viel Software wird auf Auftrag & Kundenwunsch entwickelt, wo der
Kunde sehr wohl den Sourcecode sieht und anmeckert.
Rufus Τ. Firefly schrieb:> Falk Brunner schrieb:>> DAS ist eben die Frage! Möchte bzw. KANN man das?>> Die Fragestellung des Threaderstellers ließ mich das annehmen.>> Wenn man die wirtschaftliche Unabhängigkeit hat, die es einem> ermöglicht, einen neuen Job wegen derlei Anpassungsproblemen gleich> wieder hinzuwerfen, dann kann man das ja tun.
das ist doch nicht nur ein anpassungsproblem. da geht es um viel mehr.
strukturiertes vorgehen, welches man sich angeeignet hat, aufgeben und
sich dafür lieber "anpassen". immer mit dem wissen zu arbeiten, dass was
ich hier tue ist doch scheiße, ist ja auch keine lösung.
dann wäre da noch ein wichtiger punkt von Marcus W. :
>Teamfähigkeit ist gut und richtig, aber ich sehe das hier wie Falk: Man>sollte sich selbst nicht verbiegen. Der Chef hat ihn wegen seiner>Fähigkeiten eingestellt und erhofft sich einen Produktivitätsgewinn>durch ihn. Ein guter Mitarbeiter generiert mehr Benefit, als er kostet.>Und wenn "verwirrter" nicht ohne fremdhilfe an Programmen arbeiten kann,>ist er nicht produktiv und so auch nicht profitabel. Das wird früher>oder später in einem Personalgespräch enden. Die einzigen zwei>Möglichkeiten sind mmn. Frühzeitig die obigen Punkte anzusprechen, oder>einen Schlussstrich zu ziehen.
Dr. Sommer schrieb:> P. M. schrieb:>> Auch so eine Denkweise, die es nur in der Softwarebranche gibt.> In der Embedded-Branche vielleicht, wenn der Code einmal dahingerotzt,> geflasht und vergessen wird.> Bei richtiger Softwareentwicklung (die nicht von ETechnikern sondern von> Informatikern betrieben wird) ist eine saubere und gut geplante> Softwarearchitektur von größter Wichtigkeit, der viel Zeit & Geld> gewidment wird - was sich dann bei späteren Änderungswünschen auszahlt.> Das ist eine Wissenschaft für sich.> Auf "richtigen" Computern hat man ja typischerweise noch ganz andere> Größenordnungen an Programmgrößen & komplexität als bei Embedded...>> Und viel Software wird auf Auftrag & Kundenwunsch entwickelt, wo der> Kunde sehr wohl den Sourcecode sieht und anmeckert.
ist auch häufig in der automatisierungstechnik so (wo software von
Etechniker entwickelt wird ;) ). da muss man coderichtlinien von kunden
usw. einhalten damit ihr personal dementsprechend sich in der software
zurecht findet.
Ein solches System funktioniert nur solange ein fester Stamm an
Programmierern vorhanden ist der den ganzen Code kennt.
Ein Personal Ausfall ist tödlich und eine Erweiterung der Programmierer
mit gewaltigem Aufwand verbunden.
Bis ein neuer Programmierer diesen Code in dem Detail kennt um eine
Änderung beurteilen zu können vergehen Monate bis Jahre, je nachdem wie
groß das ganze ist.
Ist die Software in kleine einzelne Komponenten mit definierten
Schnittstellen aufgeteilt wird das viel einfacher.
Hier muss ein neuer erst mal nur eine Funktion oder einen Bereich
kennenlernen um mit effektiver Arbeit beginnen zu können.
Des weiteren ist eine solche Programmierweise einfach tödlich für den
Testaufwand.
Jede Änderung bedingt einen Test der vollständigen Software da keine
klar abteilbaren Grenzen bestehen.
Eine solche Software in einem Bereich der unter "funktionale Sicherheit"
fällt wird nicht mehr möglich sein. ZB ISO 26262 im Automobilbereich
Der Testaufwand sprengt in einem solchen Fall jede Vorstellung.
Ich arbeite in diesem Automobilbereich, weiß daher was im Embedded
Bereich nach ISO mittlerweile abgeht. Vielleicht ist das etwas
überzogen, aber es hat schon seine Gründe.
Unsere Steuergeräte enthalten mittlerweile rund 1 MByte an Hexcode der
zu 99,9% in C geschrieben ist. Der Rest in Assembler.
Alles unterteile in kleinst mögliche Funktionen mit definierten
Schnittstellen.
Diese wiederum gekapselt in Funktionsblöcke die definierte interne und
externe Schnittstellen besitzen.
Diese Funktionsblöcke dann ebenfalls wieder gekapselt in Systemblöcke
wie zb RTOS, IO ,....... mit definierten interne und externe
Schnittstellen.
Datenübergabe von einem Funktionsblock in einen anderen nur über
Schnittstellen und niemals über direkten Variablenzugriff. Nicht mal
lesend und schon gar nicht schreibend.
Kommt hier jetzt eine neuer Mitarbeiter hinzu muss er(sie) sich nur in
einen kleine Bereich einarbeiten um effektiv arbeiten zu können. ==>
kurze Zeitspanne
Dieser Arbeitsbereich wird sich dann im Lauf der Zeit erweitern.
Der Vorteil kommt dann extrem beim Testen und Dokumentieren zum Tragen.
Wird zb. eine Pinzuordnung am µC geändert muss nur der IO Bereich
angepasst, getestet und dokumentiert werden.
Das ist dann der Punkt ab dem eine strukturierte und gekapselte
Programmierung wirklich Sinn macht.
Und JA eine bestehenden Software umstrukturieren oder manchmal besser
Neu zu schreiben ist ein gewaltiger und teurer Aufwand.
Aber es wird sich bald amortisieren.
Und JA die Widerstände bei den eingesessen Programmierern und Managern
wird gewaltig sein.
Hier hilft nur den Managern vorzurechnen was ihrer alte Variante auf
Dauer kostet und was die strukturierte Variante auf Dauer einsparen
kann.
DAS ist der einzig mögliche Weg.
==> Es geht NUR übers GELD wenn etwas geändert werden soll.
Unterm Strich wird dir nicht viel übrigbleiben.
Aber das wurde ja schon geschrieben.
Hans Dampf schrieb:> Love it, change it or leave it. Mehr Möglichkeiten hast Du nicht.
Dem kann man nur Zustimmen.
Und als Anfänger in der Firma wird "change it" nahezu unmöglich sein.
Such dir etwas neues.
Du wirst da nichts ändern können. Wer nach 20 Jahren immer noch den
gleichen Code schreibt, der wird das in den nächsten 10 Jahren immer
noch tun.
In der Mehrzahl der Firmen ist das nicht der Fall. Da wird ab einem
gewissen Level C++ und OOP eingesetzt. Auch bei Bare-Metal ohne OS.
Der Markt ist nicht so schlecht, man findet auch andere Jobs. Und die
Lebenszeit ist zu kostbar, als dass man sie mit Betonköpfen verbringt.
Ich denke auch, du solltest zumindest versuchen was zu ändern.
Klar lässt sich ein "Alteingessener" nicht gerne von "Jungspunden"
erzählen, dass hier akuter Handlungsbedarf besteht. Ein gewichtiger
Gegner wird sein, dass die Leute durch ihr Wissen mehr oder weniger
unabkömmlich sind - solch eine komfortable Situation gibt man nicht
gerne auf. Sozusagen ein nicht aktenkundiger Kündigungsschutz.
Mach aber nicht den Fehler und versuch beim Chef zu punkten und die
anderen Mitarbeiter zu überfahren, dass wird nicht funktionieren. Und du
kennst wahrscheinlich nicht die privaten Verquickungen (es kann dir
passieren, dass die Leute schon Bescheid wissen, ehe du den Weg vom Chef
an der Kaffeküche vorbei zu deinem Arbeitsplatz gefunden hast)
Dein Ansatz ist richtig, und auf Dauer wird es auch in dieser Firma so
werden oder sie geht pleite. D.h. eigentlich ist es eine grosse Chance,
wenn du fundiertes Wissen und Kreativität hast.
Kannst du nichts ändern, verlass den Laden. Denn du wirst einige der
Arbeitsweisen automatisch übernehmen (das können wir doch schnell hier
rein flicken...)
6 Monate wären für mich ein realistischer Zeithorizont, um zu erkennen,
ob was änderbar ist oder nicht.
verwirrter schrieb:> typische C Funktionen> haben um die 3000 Zeilen Code, es gibt sogar einzelne Funktionen, die es> auf 10000 Zeilen und mehr bringen. Da passiert in einer Funktion ALLES,> keine Trennung in Funktionsgruppen, oder Module, Seitenweise if-else> (teilweise verschachtelt bis zu 10 Stufen), tonnenweise verschachtelte> switch statements, fast ausschließlich globale Variablen, unzählige Male> der gleiche Code an verschiedenen Stellen mit copy/paste verteilt...: Es> ist purer Spaghetticode!!! Nicht einmal Übergabeparameter werden> verwendet, da sowieso alles global definiert ist. Und wenn man dann> etwas sagt, dann heißt es, dies wäre in der Embedded Welt üblich,
Das ist so leider ziemlich häufig. Eine Katastrophe, aber sogar üblicher
als ordentliche SW-Entwicklung. Mit dem Alter der Entwickler hat das
(wenn überhaupt) nur sehr lose zu tun.
Die übelste gehörte Entgegnung solcher Pfuscher war die Aufforderung
"den C-Muskel zu trainieren", um bei der Programmierung mithalten zu
können.
Kopfschüttel
S.
Mr.T schrieb im Beitrag #3399709:
> hero schrieb:>> Bei Projekten in der Größe ist C das falsche Tool. Hier nimmt man C++ u>> d macht das mit OOP.
Nicht zwangsweise. Oder wie erklärst du Phänomene wie den Linux-Kern,
SQLite oder die EFL? Ist nur eine Frage der Organisation, nicht des
Paradigmas.
Vergiss mal das ewige "mit C++ wäre das nicht passiert" Rumgetrolle. Ich
garantiere dir, der miese Code ist kein Problem der Programmiersprache.
Ansonsten ist fast alles gesagt. Einzig ein kleiner Workaround, wenn man
denn bleiben will und mitmachen muss.
Es kann (muss aber nicht) helfen sich ein paar eigene Funktionen zu
schreiben, über die man die gegenseitig voneinander abhängende globalen
Variablen ändert. Dazu muss man einmal verstehen wie die Abhängigkeiten
sind. Das implementiert man in den Hilfsfunktionen und ruft im eigenen
neuen Code konsequent nur die Hilfsfunktionen auf. Den eigenen neuen
Code strukturiert man vernünftig.
Eine echte Lösung ist das nicht, aber so behält man einen Teil seiner
eigenen mentalen Gesundheit. Eventuell meckern die Spaghetti-Coder. Dann
hast du noch die Ausrede, dass du die Strukturierung brauchst weil du
noch nicht so gut bist wie sie. (hö, hö, hö ...).
Der Rächer der Transistormorde schrieb:> Das schöne an C++ ist doch das es im embedded Bereich so gut wie keine> Compiler gibt und die Diskussion sich somit von selbst erledigt.
Das ist ja wohl der allergrößte Schwachsinn den ich je gehört habe...
Wer sich mal in meinen Augen guten C++ -Code im embedded Bereich ansehen
will, sollte sich mal die Quellen von mbed runter laden.
Man kann auch ein C++ Projekt komplett verhauen selbst, oder gerade,
wenn man sich akribisch an die Lehrbücher hält. Immer und alles zu
Kapseln ist genauso Schwachsinnig wie nichts zu kapseln. Ausser man will
sich sowas wie COM von MS auch auf einem 8-bitter "gönnen".
Der Rächer der Transistormorde schrieb:> Das schöne an C++ ist doch das es im embedded Bereich so gut wie keine> Compiler gibt
Wenn man Microsoft als einzigen C++-Compiler akzeptiert, mag das
stimmen.
Wenn man übern Tellerrand guckt, gibt es sogar recht viele davon,
wie dir ja gesagt worden ist.
Aber ich denke, über eine Einführung von C++ braucht sich der OP da
ganz gewiss noch keine Gedanken machen.
Jörg Wunsch schrieb:> Wenn man übern Tellerrand guckt, gibt es sogar recht viele davon,> wie dir ja gesagt worden ist.
Da bedanken ich mich für die Lehrstunde mal ganz nett.
Was ist da mir Codesize und Geschwindigkeit (vom Zielsystem, nicht vom
Compiler)?
Der Rächer der Transistormorde schrieb:> Was ist da mir Codesize und Geschwindigkeit (vom Zielsystem, nicht vom> Compiler)?
So wie vom Code vorgegeben. Bestimmte Konstrukte lassen sich effizienter
als in C umsetzen, das meiste ist kürzer, eleganter, wartbarer, gleich
effizient wie C.
