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.
P. M. schrieb: > Es geht sehr wohl. Wenn man gut strukturiert und plant, so geht es sogar > in Assembler. Oder ich schreibe gleich ein hex file. :-P
@ 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.
:
Bearbeitet durch User
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ö ...).
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.
Der Rächer der Transistormorde schrieb: > Das schöne an C++ ist doch das es im embedded Bereich so gut wie keine > Compiler gibt Nicht? Was ist mit gcc?
Rufus Τ. Firefly schrieb: > Der Rächer der Transistormorde schrieb: >> Das schöne an C++ ist doch das es im embedded Bereich so gut wie keine >> Compiler gibt > > Nicht? Was ist mit gcc? Und mit Keil/Tasking, IAR, MPLAB, Green Hills, Wind River Systems, ...
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.
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.