Ich bin Softwareingenieur mit mehreren Jahre Beruferfahrung im Bereich Maschinenbau. Meine bisherige Erfahrung ist, dass selbst in nahmhaften Unternehmen dieser Branche komplexe (Hochsprachen-)Software auf abenteuerliche Art und Weise entsteht. Es gibt fast keinen Designprozess! Aus dem Studium und eigenen Projekten kenne ich viele Vorgehensmodelle, Strukturierungs- und Spezifizierungsprozesse, UML, Requirements-Engineering, Pflicht- und Lastenheft... nichtmal letzteres wird in der Realität konsequent gemacht, zumindest nicht für Software im Maschinenbau. Bei Microsoft, SAP und anderen Firmen des Nicht-Maschinenbau ist das zumindest besser. Man mag zu trockenen Planungsprozessen stehen wie man will, ganz ohne diese Planung bricht einem ab einer gewissen Komplexität das Dach übern Kopf zusammen. Seit über 25 Jahren sind diese Effekte bekannt! Und dennoch geht die Entwicklung seit Jahren dahin, dass Anforderungsmanagement durch Scrum ersetzt wird... hatte ich bisher einfach nur Pech mit den Firmen oder ist das "branchenüblich"?
Beitrag #6114824 wurde vom Autor gelöscht.
Ing schrieb: > hatte ich bisher einfach nur Pech mit den Firmen Oder mit der Berufswahl. > Aus dem Studium und eigenen Projekten kenne ich viele Vorgehensmodelle, > Strukturierungs- und Spezifizierungsprozesse, UML, > Requirements-Engineering, Pflicht- und Lastenheft... nichtmal letzteres > wird in der Realität konsequent gemacht, zumindest nicht für Software im > Maschinenbau. Du solltest es als Chance sehen: diese Strukturen müssen dort alle noch irgendwie implementiert werden. Sonst kann das ja niemals gutgehen! > Bei Microsoft, SAP und anderen Firmen des > Nicht-Maschinenbau ist das zumindest besser. Träum weiter. Dort kommen auf 1 Programmierer eben 3 Verwalter, die als Consulter die ganzen "Requirements" beim Kunden einsammeln, ausführlich doumentieren, dem Programmierer sagen wie sie die Anforderungen des Kunden verstanden haben und dann kurz vor Ende des Geldes irgendwas abliefern, das hinterher in 2 Jahren soweit zusammengeflickt wird, bis es annähernd das tut, was die bisherige Lösung auch schon konnte. Da kommt es dann schon mal vor, dass die firmeneigene IT als Ziel ausruft: "die Nachfolgelösung ist nicht schneller oder besser als die bisherige". Das möchte ich mal über eine meiner Maschinensteuerungen vor der ganzen Firma verkünden wollen...
:
Bearbeitet durch Moderator
Ing schrieb: > .. hatte ich bisher > einfach nur Pech mit den Firmen oder ist das "branchenüblich"? Letzteres. Btdt.
Lothar M. schrieb: > Träum weiter. Dort kommen auf 1 Programmierer eben 3 Verwalter, die als > Consulter die ganzen "Requirements" beim Kunden einsammeln, ausführlich > doumentieren, dem Programmierer sagen, wie sie den Kunden verstanden > haben und dann kurz vor Ende des Geldes irgendwas abliefern, das > hinterher in 2 Jahren soweit zusammengeflickt wird, bis es annähernd as > tut, was die bisherige Lösung auch schon konnte. :-) Mein persönliches Highlight war mal einer unserer "Berater" der mit einem Kunden vereinbart hatte dass wir (SW-Entwicklung) "mal was machen", der Kunde es sich dann ansieht und dann sagt wie er es gerne hätte. Zum Festpreis!
Ing schrieb: > Anforderungsmanagement durch Scrum ersetzt wird... hatte ich bisher > einfach nur Pech mit den Firmen oder ist das "branchenüblich"? Wohl eher branchenübergreifend. Welche Projekte waren denn das? Warst du als Interner dabei oder als Externer?
Ich war schon in einigen Firmen angestellt. Und alle mit ausufernder "Vorgehensmodelle, Strukturierungs- und Spezifizierungsprozesse, UML, Requirements-Engineering, Pflicht- und Lastenheft" kamen nicht inne Pötte und haben keine bessere Qualität abgeliefert. Weniger ist manchmal mehr. Aber gewiss ganz sollte man sowas nicht weglassen. Manche übertreiben es mit diesem Bla Bla jedoch ganz gewaltig.
Udo S. schrieb: > Mein persönliches Highlight war mal einer unserer "Berater" der mit > einem Kunden vereinbart hatte dass wir (SW-Entwicklung) "mal was > machen", der Kunde es sich dann ansieht und dann sagt wie er es gerne > hätte. Ein Traum! Da kann man sich mal ein nettes Projekt ausdenken fern von wirtschaftlichen Zwängen, sich ein paar neue Technologien aneignen und ausnahmsweise mal nicht Quick-and-Dirty coden. Dass der Kunde dann am Ende nichts damit anfangen kann ist sein Problem... Ing schrieb: > Und > dennoch geht die Entwicklung seit Jahren dahin, dass > Anforderungsmanagement durch Scrum ersetzt wird... Normal, weil es oft keine genauen Anforderungen gibt. Keiner weiß so genau was die Millionen potentielle Nutzer so genau wollen. Bei Facebook, WhatsApp & Co wird auch kein Lastenheft geschrieben - es werden diverse Dinge ausprobiert, und die die gut ankommen weiter ausgebaut. Dann muss man auch den Mut haben, wenig benutzte Features wieder einzustampfen, weil die letztlich nur Wartungsaufwand und damit Geld kosten.
Ing schrieb: > Ich bin Softwareingenieur mit mehreren Jahre Beruferfahrung im > Bereich > Maschinenbau. Meine bisherige Erfahrung ist, dass selbst in nahmhaften > Unternehmen dieser Branche komplexe (Hochsprachen-)Software auf > abenteuerliche Art und Weise entsteht. Es gibt fast keinen > Designprozess! Aus dem Studium und eigenen Projekten kenne ich viele > Vorgehensmodelle, Strukturierungs- und Spezifizierungsprozesse, UML, > Requirements-Engineering, Pflicht- und Lastenheft... nichtmal letzteres > wird in der Realität konsequent gemacht, zumindest nicht für Software im > Maschinenbau. Bei Microsoft, SAP und anderen Firmen des > Nicht-Maschinenbau ist das zumindest besser. Ist aussserhalb von Microsoft und SAP nicht nur im Maschinenbau so ! > Man mag zu trockenen Planungsprozessen stehen wie man will, ganz ohne > diese Planung bricht einem ab einer gewissen Komplexität das Dach übern > Kopf zusammen. So isses ! > Seit über 25 Jahren sind diese Effekte bekannt! Und > dennoch geht die Entwicklung seit Jahren dahin, dass > Anforderungsmanagement durch Scrum ersetzt wird... hatte ich bisher > einfach nur Pech mit den Firmen oder ist das "branchenüblich"? Scrum ist halt der heisse Scheiss. Da wird der Bock zum Gärtner gemacht, Kritik ist sektenartig nicht erwünscht. Meckern über Scheiss Anforderungen ist Vergangenheit, sieh zu wie du ohne klar kommst. Am Ende steigt der Druck auf die Entwickler noch mehr, und es wird gefrickelt bis der Arzt kommt. Verstehe nicht, wie mancher Entwickler das auch noch gut findet.
Das mit dem Designprozess ist toll. Ich hatte mal so ne UML Phase, wo ich 10 Jahre an mehreren UML Tools mitgearbeitet hab. Hab ich sehr viel bei gelernt. Kannst aber in der Praxis alles vergessen. Was ich jetzt erlebe ist, dass die GeschFü Morgens die Spezifikation umwirft und erwartet, dass paar Stunden später eine Version zum Testen bereitsteht. Da ist genau 0 Zeit, irgendwas zu dokumentieren o.ä. Neue Funktionen sollen im Stundentakt eingebaut werden. Zum Testen bleibt keinerlei Zeit.
FrustrierterComputerBastler schrieb: > Das mit dem Designprozess ist toll. Ich hatte mal so ne UML Phase, > wo ich 10 Jahre an mehreren UML Tools mitgearbeitet hab. Hab ich sehr > viel bei gelernt. > > Kannst aber in der Praxis alles vergessen. Was ich jetzt erlebe ist, > dass die GeschFü Morgens die Spezifikation umwirft und erwartet, dass > paar Stunden später eine Version zum Testen bereitsteht. Da ist genau 0 > Zeit, irgendwas zu dokumentieren o.ä. > > Neue Funktionen sollen im Stundentakt eingebaut werden. Zum Testen > bleibt keinerlei Zeit. Ja, aber Clean Coden und es soll auch noch ein vernünftiges OOP Design entstehen. Ist ohne Planung nicht möglich, Scrum ist die Pflicht zu Frickelei.
Ing schrieb: > kenne ich viele Vorgehensmodelle, Strukturierungs- und > Spezifizierungsprozesse, UML, Requirements-Engineering, Pflicht- und > Lastenheft... nichtmal letzteres wird in der Realität konsequent > gemacht, Das es so viele gibt, ist oft ein Zeichen, dass keine gut ist. Wenn Anforderungen bekannt, konstant und formulierbar sind, dann ist das alles ja ganz schön. Wird z b. bei Sicherheit oft gemacht. Oder wenn man Programmierer hat, was bei SAP & CO oft der Fall ist. Aber Innovation, Fortschritt geht so nicht. Und zusammenbrechen tut es nicht an fehlenden redundanten Dokumenten, sondern an schlechtem Design. Egal ob in UML oder Code, es gibt halt Leute mit genialen Lösungen und guter Auffassungsgabe und üble Frickler (hat mir keiner gesagt, dass ...) und alles dazwischen.
Motzkopp schrieb: > soll auch noch ein vernünftiges OOP Design entstehen. Ist ohne Planung > nicht möglich, Ein gutes Design ist erst möglich, wenn man einen Großteil der Anforderungen und Einsatzfälle kennt. Das ist aber bei neuen, innovativen Dingen erst im Projektverlauf. Wenn ich XY erfinde, baue, dann kann ich noch nicht wissen, was ich mit XY mache, brauche. Darum ist refakturieren, redesignen, Funktionen wegwerfen, andere verbessern wichtig. Das Design muss/kann quasi erst am Ende sauber sein. Der beste Plan ist wertlos beim ersten Feindkontakt. Oder: vergiss den Plan, Planung ist alles.
A. S. schrieb: > > > Wenn Anforderungen bekannt, konstant und formulierbar sind, dann ist das > alles ja ganz schön. Wird z b. bei Sicherheit oft gemacht. Oder wenn man > Programmierer hat, was bei SAP & CO oft der Fall ist. Die Herren aus dem Anforderungs und Produktmanagment usw waren schon immer bequem und denkfaul, durch Scrum und diesen Scheiss kriegen sie jetzt auch noch ne offizielle Legimitation dazu. Das sind die ersten, die der GF erzählen, wie toll das ist, sind ja schließlich damit raus aus der Verantwortung. > Aber Innovation, Fortschritt geht so nicht. Boa ej, hat man dich auch schon erfolgreich durch die Gehirnwäsche durch, oder was ist das fürn Managergeschwafel? > Und zusammenbrechen tut es nicht an fehlenden redundanten Dokumenten, > sondern an schlechtem Design. Egal ob in UML oder Code, es gibt halt > Leute mit genialen Lösungen und guter Auffassungsgabe und üble Frickler > (hat mir keiner gesagt, dass ...) und alles dazwischen. Dann zaubere mir mal ein schönes DB und OOP Klassendesign hin, wenn die Anforderungen tagesweise bekannt werden und wieder umgeworfen werden. Nein, man wird aber nicht zugeben, dass das systembedingt kaum möglich ist, Scrum ist nicht Schuld, das liegt an den Leuten !
A. S. schrieb: > Motzkopp schrieb: > soll auch noch ein vernünftiges OOP Design entstehen. Ist ohne Planung > nicht möglich, > > Ein gutes Design ist erst möglich, wenn man einen Großteil der > Anforderungen und Einsatzfälle kennt. Da sind wir uns einig ! Das ist aber bei neuen, > innovativen Dingen erst im Projektverlauf. Wenn ich XY erfinde, baue, > dann kann ich noch nicht wissen, was ich mit XY mache, brauche. > > Darum ist refakturieren, redesignen, Funktionen wegwerfen, andere > verbessern wichtig. Das Design muss/kann quasi erst am Ende sauber sein. Ja, dann kannst nach agil und CO ständig redisgnen oder neu machen, und das soll gut sein? Das ist nur teuer ! Und du glaubst ja wohl nicht, das eine funktionierende Frickelkei in der Praxis später noch redesigned wird. > Der beste Plan ist wertlos beim ersten Feindkontakt. Oder: vergiss den > Plan, Planung ist alles. Man sollte erstmal das Ziel haben den Plan so gut wie möglich zu machen und nicht mit dem Ansatz Pkan geht sowieso nicht, also lassen wir es gleich ganz.
Motzkopp schrieb: > Die Herren aus dem Anforderungs und Produktmanagment usw waren schon > immer bequem und denkfaul, Wer sollen denn diese Leute sein? Wie gesagt, Programmierer sind im Maschinenbaus selten. Eher Softwareentwickler / Ingenieure, die etwas neues entwickeln. Zum nachbauen haben wir Chinesen, für Änderungen Techniker, nachdem es erfolgreich ist und das Design glattgezogen ist. Nur erfolgreiche Produkte werden geändert!
A. S. schrieb: > Motzkopp schrieb: > Die Herren aus dem Anforderungs und Produktmanagment usw waren schon > immer bequem und denkfaul, > > Wer sollen denn diese Leute sein? > Wie gesagt, Programmierer sind im Maschinenbaus selten. Eher > Softwareentwickler / Ingenieure, die etwas neues entwickeln. Zum > nachbauen haben wir Chinesen, für Änderungen Techniker, nachdem es > erfolgreich ist und das Design glattgezogen ist. Nur erfolgreiche > Produkte werden geändert! Programmierer gibt es bei uns auch nicht und mein Bereich ist nicht Maschbau. Aber sonne Maschine wird selbst nicht nach Scrum konstruiert und gebaut, oder ? Warum nicht, ist doch so eine tolle Sache? Zu der Frage wer diese Leute sein sollen. Ich bin mir sicher, auch im Maschinenbau, obwohl nicht mein Bereich, gibt es Leute, die einem sagen, was das Ding am Ende können muss.
Motzkopp schrieb: > Aber sonne Maschine wird selbst nicht nach Scrum konstruiert und gebaut, > oder ? Warum nicht, ist doch so eine tolle Sache? Das Design einer Maschine ist z.B. dessen Zeichnung. Das Design einer Software ist z.B. dessen Quelltext. Der Unterschied zwischen Maschine und Quelltext ist, dass die Produktion eines Prototypen (Maschine, Maschinencode) im einen Fall hunderte Stunden dauert, im zweiten Fall nur Sekunden oder Minuten. Darum hat man beim Maschinenbau weniger Itterationen. Ob und wie Maschienenbauer ihr Design üblicherweise entwickeln, weiss ich nicht. Ich hoffe aber mal, dass sie auch Dinge ausprobieren, gemeinsam besprechen, Ideen im Projektfortschritt aufgreifen etc. Aber dass konkret Scrum jetzt nicht passt, ist offensichtlich (es gibt keine täglichen Prototypen, Funktionsmuster) > Zu der Frage wer diese Leute sein sollen. Ich bin mir sicher, auch im > Maschinenbau, obwohl nicht mein Bereich, gibt es Leute, die einem sagen, > was das Ding am Ende können muss. Ja, ähnlich Abstrakt wie Du einem Architekten sagst, wie Dein Haus auszusehen hat. Du sagst ihm, ob es Traufenständig sein soll, wie groß in etwa, was und welche Zimmer. Und dann macht er einen Entwurf, den Ihr verfeinert. Und ja, technische Abläufe der Maschine muss der SW-Ingenieur wirklich selber verstehen und dann Umsetzen. Und ja, wenn es um z.B. die SPS-SW eine Produktionsstraße geht, dann brauchst Du eher Programmierer. Aber eine SPS selber, Maschinen mit embeddedter Steuerung und GUI, Eine Druckmaschine oder Spinnmaschine, … da ist die SW Teil der Entwicklung.
A. S. schrieb: > Das Design einer Maschine ist z.B. dessen Zeichnung. > > Das Design einer Software ist z.B. dessen Quelltext. Hä? Der Quelltext IST die Software. Das Design sind Ablauf-, Klassen-, Zustands- etc. diagramme
c r schrieb: > Hä? Der Quelltext IST die Software. Das Design sind Ablauf-, Klassen-, > Zustands- etc. diagramme Wenn das so wäre, bräuchte man Programmierer, die die Diagramme in Quelltext "übersetzen". Wo das der Fall ist (bzw. von einem Tool gemacht wird), hast Du recht. Ein Matlab-Simulink-Stateflow-Diagramm ist das Design. Vielleicht meinst Du eher eine Art "Architektur", "übergeordnete Struktur" oder so. Das gibt es natürlich im Maschinenbau auch, dass es übergeordnete Zeichnungen, Erklärungen etc. gibt.
Nachtrag: Hier ein Papier dazu: http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf Ich fand das genauso bahnbrechend, wie seinerzeit die Ablösung von Nassi-Shneydermann und Co durch Hochsprachen.
Motzkopp schrieb: > Die Herren aus dem Anforderungs und Produktmanagment usw waren schon > immer bequem und denkfaul, durch Scrum und diesen Scheiss kriegen sie > jetzt auch noch ne offizielle Legimitation Aber wieso kommt man damit durch? Man stelle sich vor ein Haus zu beauftragen ohne Planung! "War halt noch nicht klar wo die Fenster und Türen rein sollen und wo der Schornstein stehen muss"? Bauteil fertigen ohne Zeichnungen/CAD? Das leuchtet jedem sofort ein, dass da etwas nicht stimmt. Bei Softwareprojekten ist das Bewusstsein offenbar auf dem Stand von 1980 verharrt?!
Ing schrieb: > Aber wieso kommt man damit durch? Weil es funktioniert. Die Branchengrößen machen es vor. Ing schrieb: > Man stelle sich vor ein Haus zu > beauftragen ohne Planung! Ein Haus ist keine Software. Da kann man nicht mit einem Klick auf den Stand von gestern zurückgehen. Ing schrieb: > Bei Softwareprojekten ist das Bewusstsein offenbar auf dem Stand > von 1980 verharrt?! Softwareprojekte sind so komplex, und arbeiten in einer so komplexen Umgebung, dass die Entwicklung unmöglich komplett planbar ist. Bei einem Haus oder einem Bauteil auf Basis bekannter Technologie ist das was ganz anderes. Komplett spezifizierte Anforderungen zu haben ist utopisch - viele Auftraggeber wissen nicht genau was sie brauchen, und was sich im Endkundenmarkt durchsetzt ist sowieso unvorhersehbar (klassisches Beispiel VHS vs Betamax). Man muss mit dem arbeiten was man hat, flexibel auf neue Erkenntnisse - die man vorher unmöglich haben konnte - reagieren und das Ziel ständig neu stecken. Scrum hilft dabei. Wenn man komplette Software-Projekte versucht durchzuplanen und alles nach dem ursprünglichen Plan entwickelt, d.h. zwischendurch dazugekommene Erkenntnisse und Technologien ignoriert, wird das Ergebnis veraltet sein sobald es auf den Markt kommt - daher der Grundsatz, oft kleine Versionssprünge zu veröffentlichen, um die Nutzer bei Laune zu halten. Auch bei Häusern ändern sich gelegentlich die Anforderungen zwischendurch, und Dinge werden mittendin umgeplant. Das manifestiert sich dann gelegentlich in kuriosen Konstruktionen. Man muss diese typische Ingenieurs-Denkweise ablegen, alles durchplanen und dann zusammenbauen zu können - das ist unrealistisch, unwirtschaftlich und lässt Möglichkeiten ungenutzt (erinnert an Planwirtschaft). Software ist lebending, ist nie fertig und kann jederzeit umgebaut werden. Autoren planen ihre Romane auch selten von A-Z durch um sie dann nur noch runterzuschreiben - es wird viel nachträglich korrigiert und vieles spontan entschieden. In beiden Fällen ist das natürlich ein zweischneidiges Schwert - es verleitet schnell zu unbeherrschbarem Wildwuchs. Daher gibt es Modelle wie Scrum, um das in den Griff zu bekommen, ohne auf eine starre Komplettplanung zurück zu fallen. Motzkopp schrieb: > Ja, dann kannst nach agil und CO ständig redisgnen oder neu machen, und > das soll gut sein? Das ist nur teuer ! Billiger als Projekte die nur für die Tonne entwickelt werden, weil man sich ändernde Marktsituationen/-Erkenntnisse ignoriert. > Und du glaubst ja wohl nicht, das > eine funktionierende Frickelkei in der Praxis später noch redesigned > wird. Selbstverständlich werden Proof-of-Concept-Ansätze bereinigt und ausgebaut, wenn sie gut ankommen.
Ing schrieb: > hatte ich bisher > einfach nur Pech mit den Firmen oder ist das "branchenüblich"? Ist nicht nur dort so. Wenn der Käufer der Produkte keinen Entwicklungsprozess zwingend in die Auftragsbücher diktiert, ist Wilder Westen angesagt.
Ing schrieb: > Aber wieso kommt man damit durch? Weil es einen Aspekt der Realität in der Entwicklung abdeckt, der von den klassischen Methoden nicht abgedeckt wird, nämlich dass sich Anforderungen ständig ändern. > Man stelle sich vor ein Haus zu > beauftragen ohne Planung! "War halt noch nicht klar wo die Fenster und > Türen rein sollen und wo der Schornstein stehen muss"? Bauteil fertigen > ohne Zeichnungen/CAD? Das leuchtet jedem sofort ein, dass da etwas nicht > stimmt. Schon mal ein Haus gebaut? Alle paar Tag fällt einem eine Änderung ein. Hier noch was ein bisschen anders, da noch was. Wenn man es sich leisten kann dann beauftragt man die Änderungen, was viel Geld kostet. Die Handwerker freut es und man wäre froh, wenn im Gesamtsystem mehr Flexibilität wäre. Bei großen Bauprojekten ist es noch schlimmer. Jeden Tag Besprechung in der man über Fehler in den Plänen diskutiert und mehr oder weniger guten Pfusch beschließt. Es ist übrigens ein Gerücht, dass bei Scrum keine Planung stattfindet und es keine Anforderungen gibt. Jeder Sprint wird voraus geplant und während eines Sprints wird sich an die Planung gehalten. Änderungen die während eines Sprints reinkommen werden frühstens im nächsten Sprint berücksichtigt. Damit das nicht zu lange dauert werden Sprints selber sehr kurz gehalten. Scrum bedeutet viel Disziplin. Das ist das eigentliche Problem. Wenn die Beteiligten undisziplinert sind, und die meisten sind es, dann kommt Mist raus. Der Product Owner schafft die Requirements nicht ran oder sie sind extrem wage. Der Scrum Master sichert nicht den Prozess. Die Sprints werden nicht sauber geplant. Mitten in den Sprints wird die Richtung geändert, jeder Programmierer macht was er will. > Bei Softwareprojekten ist das Bewusstsein offenbar auf dem Stand > von 1980 verharrt?! Nein, eher von 1950. Undisziplinierte Softwerker brauchen klare Anweisungen und Kontrolle. Wer glaubt Scrum ohne Disziplin zum Laufen zu bekommen, dem kann ich nur viel Spaß wünschen.
Ing schrieb: > Man mag zu trockenen Planungsprozessen stehen wie man will, ganz ohne > diese Planung bricht einem ab einer gewissen Komplexität das Dach übern > Kopf zusammen. Ist das Dach denn schon zusammengebrochen? Wenn ja: Nach dem Desaster sollte eigentlich jedem in der Firma klar sein, dass am Entwicklungsprozess etwas geändert werden muss. Vielleicht bist du mit deiner Erfahrung der einzige, der in der Lage ist, so etwas umzusetzen. Sprich doch einfach mal mit den Verantwortlichen darüber. Evtl. fördert das sogar deine Karriere in der Firma. Wenn nein: Vermutlich gibt es bereits so etwas wie einen Entwicklungsprozess, sonst wüsste ja keiner der Entwickler, was er jeden Tag zu tun hat. Der Prozess basiert aber möglicherweise nicht auf einem starren Regelwerk und deckt sich nicht mit den Verfahren, die du in deinem Studium gelernt hast. Gerade in kleineren Entwicklergruppen kristallisiert sich oft im Lauf der Zeit eine Vorgehensweise heraus, bei der ein paar erfahrene Mitarbeiter den Wagen in die richtige Richtung lenken, ohne dass es für ihre Rolle einen speziellen Namen oder eine genaue Beschreibung gibt. Solche Vorgehensweisen mögen auf der einen Seite chaotisch anmuten, auf der anderen Seite können sie aber sehr effizient, gut auf das jeweilige Projektumfeld hin optimiert und vor allem sehr flexibel sein. Die standardisierten Vorgehensmodelle, wie sie dir vorschweben, sind meist auf größere Entwicklergruppen zugeschnitten, wo eine direkte Kommunikation unter den Mitgliedern nur eingescränkt möglich ist. Wie groß ist denn bei euch die Anzahl der Softwareentwickler, die gleichzeitig an einem Projekt arbeiten?
> Softwareprojekte sind so komplex, und arbeiten in einer so komplexen > Umgebung, dass die Entwicklung unmöglich komplett planbar ist. Bei einem > Haus oder einem Bauteil auf Basis bekannter Technologie ist das was ganz > anderes. Die sind komplex und ja ein Plan Bedarf ständiger Anpassungen. Aber erstmal einen Plan haben ! Und wie Wahrheit ist, dass gute Pläne an folgenden Dingen scheitern: Zeit und Einstellung der Personen ! Man gesteht der Planung zu wenig Zeit zu und die Anforderungsmanager haben kein Bock zu denken, es ist halt leichter wenn man schonmal was zum draufklicken hat und ein paar Dinge ausprobieren kann. Typisch ist es z.B. dass der Anfoderungsmanager den IST-Zustand gar nicht genau kennt, erst der Entwickler sagt ihm beim coden dann, was er noch zu berücksichtigen hat. Das muss man bei Planestellung nicht bis ins letzte Detail machen, das ist echt aufwendig, aber nen groben Plan sollte man haben. > Komplett spezifizierte Anforderungen zu haben ist utopisch - viele > Auftraggeber wissen nicht genau was sie brauchen, und was sich im > Endkundenmarkt durchsetzt ist sowieso unvorhersehbar (klassisches > Beispiel VHS vs Betamax). Man muss mit dem arbeiten was man hat, > flexibel auf neue Erkenntnisse - die man vorher unmöglich haben konnte - > reagieren und das Ziel ständig neu stecken. Scrum hilft dabei. Oh man, hier haben wir einen der Scrum-Jünger !!! Die Schulungen sind Gehirnwäsche. > Wenn man komplette Software-Projekte versucht durchzuplanen und alles > nach dem ursprünglichen Plan entwickelt, d.h. zwischendurch > dazugekommene Erkenntnisse und Technologien ignoriert, wird das Ergebnis > veraltet sein sobald es auf den Markt kommt - daher der Grundsatz, oft > kleine Versionssprünge zu veröffentlichen, um die Nutzer bei Laune zu > halten. > Auch bei Häusern ändern sich gelegentlich die Anforderungen > zwischendurch, und Dinge werden mittendin umgeplant. Das manifestiert > sich dann gelegentlich in kuriosen Konstruktionen. Es sagt niemand, dass man beim klassischen Vorgehen, nicht den Plan ständig anpassen kann. Wie gesagt, das Ziel sollte zuerst sein einen möglichst guten Plan zu haben, statt einen Plan von vorneherein abzulehnen. > > Motzkopp schrieb: >> Ja, dann kannst nach agil und CO ständig redisgnen oder neu machen, und >> das soll gut sein? Das ist nur teuer ! > Billiger als Projekte die nur für die Tonne entwickelt werden, weil man > sich ändernde Marktsituationen/-Erkenntnisse ignoriert. So ein Quark. Ich weiss nicht woher die Vorstellung kommt, das nach Wasserfall keine Änderungen am Plan mehr möglich sind und das das nur mit Scrum möglich ist. >> Und du glaubst ja wohl nicht, das >> eine funktionierende Frickelkei in der Praxis später noch redesigned >> wird. > Selbstverständlich werden Proof-of-Concept-Ansätze bereinigt und > ausgebaut, wenn sie gut ankommen. Bin 25 Jahre im Job ind 4 verschiedenen Unternehmen, das mit dem Redisgnen klappt in der Praxis nur mit KleinKlein Zeug, das keine anderen Entscheidungsgewalten abnicken müssen. Z.B. Meine jetzigen "Kunden", die Fachabteilungen ist das nicht vermittelbar, wofür sie wertvolle Resourcen opfern sollen. Was haben sie davon ?
Ing schrieb: > Motzkopp schrieb: >> Die Herren aus dem Anforderungs und Produktmanagment usw waren schon >> immer bequem und denkfaul, durch Scrum und diesen Scheiss kriegen sie >> jetzt auch noch ne offizielle Legimitation > > Aber wieso kommt man damit durch? Man stelle sich vor ein Haus zu > beauftragen ohne Planung! "War halt noch nicht klar wo die Fenster und > Türen rein sollen und wo der Schornstein stehen muss"? Bauteil fertigen > ohne Zeichnungen/CAD? Das leuchtet jedem sofort ein, dass da etwas nicht > stimmt. Bei Softwareprojekten ist das Bewusstsein offenbar auf dem Stand > von 1980 verharrt?! Die kommen damit durch, weil sie näher am Managment und am Kunden sitzen. Die Entwickler sind die Blaumänner in der Produktion, haben nichts zu kamellen, dürfen es nur ausbaden. Notfalls reden die Herren sich raus, schwieriger Kunde, Markt hat sich geändert, Kunde hat es umentschieden usw. usw.. Meiner Meinung sind diese Ausreden zu 90% vermeidbar, wenn man seinen Denkapparat ordentlich angeschmissen hätte, aber lieber ersteinmal auf was rumklicken können und dann umentscheiden um dann damit massenweise Geld/Entwiclungszeit zu vernichten.
Michael Gugelhupf schrieb: > Ing schrieb: > > Es ist übrigens ein Gerücht, dass bei Scrum keine Planung stattfindet > und es keine Anforderungen gibt. Jeder Sprint wird voraus geplant und > während eines Sprints wird sich an die Planung gehalten. Änderungen die > während eines Sprints reinkommen werden frühstens im nächsten Sprint > berücksichtigt. Damit das nicht zu lange dauert werden Sprints selber > sehr kurz gehalten. > > Scrum bedeutet viel Disziplin. > > Das ist das eigentliche Problem. Wenn die Beteiligten undisziplinert > sind, und die meisten sind es, dann kommt Mist raus. Der Product Owner > schafft die Requirements nicht ran oder sie sind extrem wage. Der Scrum > Master sichert nicht den Prozess. Die Sprints werden nicht sauber > geplant. Mitten in den Sprints wird die Richtung geändert, jeder > Programmierer macht was er will. > >> Bei Softwareprojekten ist das Bewusstsein offenbar auf dem Stand >> von 1980 verharrt?! > > Nein, eher von 1950. Undisziplinierte Softwerker brauchen klare > Anweisungen und Kontrolle. Wer glaubt Scrum ohne Disziplin zum Laufen zu > bekommen, dem kann ich nur viel Spaß wünschen. Jepp, hier haben wir einen, sie einer meiner letzten Postings ! Merke: Es liegt nie an Scrum, wenns nicht klappt, es liegt an den Leuten, oder man hat es falsch umgesetzt usw. ! Daher kommt mir das ganze auch so sektenartig vor, oder man will noch Scrum-Schulungen verdienen und die ganzen zertifizierten Scrummaster wollen es nicht umsonst gemacht haben.
Ing schrieb: > hatte ich bisher einfach nur Pech mit den Firmen oder ist das > "branchenüblich"? Das ist so durchaus üblich. Wenn ein Unternehmen sich hauptsächlich als Maschinenbauer sieht, woher soll es dann auch eine große Kompetenz in Sachen Softwareentwicklung besitzen?
motzkopp schrieb: > Jepp, hier haben wir einen, sie einer meiner letzten Postings ! Ach du Pfeife, hör erst mal auf zu plenken. Hättest du mich gefragt was an Scrum falsch ist hätte ich dir einen mehrstündigen Vortrag darüber halten können. Aus Erfahrung. Danach hätte ich noch eine Stunde dran hängen können, wie Scrum-Projekte durch Ausnutzung der Schwächen erfolgreich sabotiert werden. Aber du hast ja nicht gefragt. Du hast einfach rumgegrölt. So wie ein Afd-Anhänger, unqualifizierte, unwissende aber im Besitz der alleinigen Wahrheit und noch stolz drauf. Weißt du, es ist traurig wenn ein angeblicher Ingenieur wie du nicht einmal in Ruhe eine Diskussion zum Für und Wider einer Methode aushalten, geschweige denn führen kann. Nun, da alles Weitere bei dir nur Perlen vor die plenkenden Säue ist schenke ich mir alles Weitere.
motzkopp schrieb: > Merke: Es liegt nie an Scrum, wenns nicht klappt, es liegt an den > Leuten, oder man hat es falsch umgesetzt usw. ! > Daher kommt mir das ganze auch so sektenartig vor, oder man will noch > Scrum-Schulungen verdienen und die ganzen zertifizierten Scrummaster > wollen es nicht umsonst gemacht haben. Versteiff Dich doch nicht so auf SCRUM. Mit denen Leuten, mit denen es mit SCRUM klappt, kannst Du auch ohne SCRUM genauso viel reißen. Du musst nur weg vom umfassenden Plan vorab. Wenn Deine Auftraggeber wissen, was sie wollen, z.B. deren Geschäftsprozesse auf neues Steuerrecht anpassen oder eine Produktionsstraße automatisieren, dann ist das doch gut. Dann gibt es zwar hier oder da eine Änderung, aber dann weiss anfangs, was hinten rauskommen soll. Wenn Du etwas Neues entwickelst (ein Messgerät, eine Maschine, die erstmals elektronisch gesteuert wird, ...) dann kannst Du nicht wissen, was Du willst, einfach weil das bisher niemand in der Hand gehabt hat. Dann brauchst Du Entwickler (keinen Techniker), Ingenieure, keine Programmierer, Kreativität statt Sorgfalt. Oder besser gesagt, die Mischung daraus. Dann brauchst Du die Freiheit, heute die Arbeit der letzten 2 Wochen wegzuschmeißen und neu zu machen, heute die Annahme von gestern (es wird nie mehr als 255 geben) zu verwerfen. Hätte Ford die Kunden befragt, hätten sie sich schnellere Pferde gewünscht.
Programmierer schrieb: > Ing schrieb: >> Aber wieso kommt man damit durch? > > Weil es funktioniert. Die Branchengrößen machen es vor. > Das höre ich auch immer wieder. Die Branchengrössen können sich von der Ressourcengewalt ganz anders mit dem Zeug beschäftigen. Die können viel Ressourcen versemmeln, nur das Produkt muss 100% sein, das nutzen Millionen von Leuten. Kann man nicht mit normalen Softwarebuden vergleichen, wo jede Stunde irgendein Kunde bezahlen muss und sich änderende Anforderungen und ständiges anders und neu Gemache finanziell ganz anders auswirken. Ist aber hipp, dass denen großen nachzumachen.
A. S. schrieb: > > Wenn Du etwas Neues entwickelst (ein Messgerät, eine Maschine, die > erstmals elektronisch gesteuert wird, ...) dann kannst Du nicht wissen, > was Du willst, einfach weil das bisher niemand in der Hand gehabt hat. > Dann brauchst Du Entwickler (keinen Techniker), Ingenieure, keine > Programmierer, Kreativität statt Sorgfalt. Oder besser gesagt, die > Mischung daraus. Dann brauchst Du die Freiheit, heute die Arbeit der > letzten 2 Wochen wegzuschmeißen und neu zu machen, heute die Annahme von > gestern (es wird nie mehr als 255 geben) zu verwerfen. > > Hätte Ford die Kunden befragt, hätten sie sich schnellere Pferde > gewünscht. Diesen Anwendungsfall unterschreibe ich, siehe meinem letzten Postung, da zählt das innovative schnelle Produkt 100 mal mehr, als die Ressourcen und man startet auf der gründen Wiese. Ich arbeite zur Zeit an einer seit 25 Jahren existierenden aus 50 Mio Zeilen bestehenden -grob gesagt- Buchhaltungssoftware. Schmeiss da mal kurz was um, jedes Flag einer Tabelle kann ungeahnte gravierende Auswirkung haben...
Mark B. schrieb: > Das ist so durchaus üblich. Wenn ein Unternehmen sich hauptsächlich als > Maschinenbauer sieht, woher soll es dann auch eine große Kompetenz in > Sachen Softwareentwicklung besitzen? Indem es entspr. Leute dafür einstellt und nicht die interne Truppe dafür missbraucht die ein bischen was zusammenschustern kann.
Dick Boutsos schrieb: > Indem es entspr. Leute dafür einstellt und nicht die interne Truppe > dafür missbraucht die ein bischen was zusammenschustern kann. Das scheitert an einem ganz banalen Grund: Wenn man selbst keine Kompetenz in X besitzt, wie soll man dann erkennen welche Person genau die richtige wäre um X korrekt durchzuführen? Außerdem: Reine Informatiker tun sich mit der Ansteuerung von Maschinen eher schwer, da ihnen hierfür oft das Wissen aus Physik und Elektrotechnik fehlt. Also nimmt man oftmals doch einen Ingenieur dafür. Der mag manchmal auch gutes Wissen über Methodik der Softwareentwicklung haben - oft genug aber hat er es nicht. Weil es nicht sein Fachgebiet ist.
:
Bearbeitet durch User
A. S. schrieb: > Wenn Du etwas Neues entwickelst (ein Messgerät, eine Maschine, die > erstmals elektronisch gesteuert wird, ...) dann kannst Du nicht wissen, > was Du willst, einfach weil das bisher niemand in der Hand gehabt hat. Äh, doch? Wenn es eine kommerzielle Entwicklung ist, wovon ich jetzt mal ausgehe, dann gibt es in jedem Fall eine konkrete Anwendung die realisiert werden soll. Vielleicht soll eine Fernsteuerung her für die Maschine X, oder in Produkt Y soll die zusätzliche Funktion Z hinein weil der Kunde das so haben will... Also zumindest Top-Level Requirements werden definitiv existieren. Wenn es nichtmal die gibt, wird doch niemand das Budget für eine Entwicklung bereitstellen.
:
Bearbeitet durch User
Dick Boutsos schrieb: > Mark B. schrieb: > Das ist so durchaus üblich. Wenn ein Unternehmen sich hauptsächlich als > Maschinenbauer sieht, woher soll es dann auch eine große Kompetenz in > Sachen Softwareentwicklung besitzen? > > Indem es entspr. Leute dafür einstellt und nicht die interne Truppe > dafür missbraucht die ein bischen was zusammenschustern kann. Softwareentwicklung ist aber keine Rocket Science. Es ist auch kein Missbrauch, wenn die Angestellten ihr Wissen und ihre Fähigkeiten etwas erweitern.
Mark B. schrieb: > Das scheitert an einem ganz banalen Grund: > Wenn man selbst keine Kompetenz in X besitzt, wie soll man dann erkennen > welche Person genau die richtige wäre um X korrekt durchzuführen? Was das fürn Nullargument?
Dick Boutsos schrieb: > Mark B. schrieb: >> Das scheitert an einem ganz banalen Grund: >> Wenn man selbst keine Kompetenz in X besitzt, wie soll man dann erkennen >> welche Person genau die richtige wäre um X korrekt durchzuführen? > > Was das fürn Nullargument? Ist kein Nullargument. Denk einfach mal bisschen nach, dafür ist dein Gehirn ja da. Wenn niemand in einer Firma echte Kompetenz in Sachen Software besitzt, und schon gar nicht die Personalabteilung, wie will man dann einen guten Entwickler einstellen? Es fehlt einem ja dann die Fähigkeit, beurteilen zu können wer wirklich gut ist.
:
Bearbeitet durch User
Qwertz schrieb: > Softwareentwicklung ist aber keine Rocket Science. Es ist auch kein > Missbrauch, wenn die Angestellten ihr Wissen und ihre Fähigkeiten etwas > erweitern. Naja. Ich will mal so sagen: Die Menge an schlecht geschriebenem, undokumentierten und schlecht wartbarem Legacy Code ist legendär groß. Scheint also wohl doch nicht so einfach zu sein, seine Kenntnisse diesbezüglich auf einen guten Stand zu bringen - sonst hätten die Leute es ja gemacht.
:
Bearbeitet durch User
Mark B. schrieb: > Also zumindest Top-Level Requirements werden definitiv existieren. Wenn > es nichtmal die gibt, wird doch niemand das Budget für eine Entwicklung > bereitstellen. Top-Level Requirement ist ganz hoch im Bullshit-Bingo. Der Kunde hat Wünsche. - Einfachere Bedienung - Fernsteuerung - Automatisierung bisher manueller Tätigkeiten - Aussagekräftigere Anzeigen - Eine Verriegelung, dass dies oder jenes nicht passiert SW im Maschinenbau heisst weder Stückzahlen wie beim IPhone oder Auto, noch EDV, wo schon seit 70 Jahren Tausende von Programmierern an einer SW arbeiten. Das was im Maschinenbau SW ist, wird bei IPhone oder Auto "Vorentwicklung" genannt, und dort gibt es aus guten Grund ähnliche Freiheiten und nicht die staren, auf Perfektion ausgerichteten Vorgehensmodelle. Dort darf man spielen, probieren, kreativ sein. Und ja, auch beim Maschinenbau gibt es SIL, SAfety und Co, und dort sind Vorgehensmodelle Pflicht, weil die Aufgabe eine andere ist: Eine konkrete, zu Anfang bekannte Funktion mit bewährten Mitteln zu realisieren. Aber das ist nur ein (ungeliebter) Teil der SW im Maschinenbau
Beitrag #6117036 wurde von einem Moderator gelöscht.
Ich will da mal aus meinem Bereich ein kürzlich aufgetretendes Problem schildern. Es gibt eine Tabelle mit Buchungen, wo wir 1,2 Mrd Datensätze haben. Dort mussten wir ein neues DB Feld einführen. Rückwirkend mussten alle Datensätze mit einem nicht einfach zu ermittelnden Wert gefüllt werden. Dies passierte durch eine aufwendige PLSQL Routine auf einer Oracle DB. Nun das Problem: Die Downzeit des Servers war nicht lange genug, um dieses Update durchzuführen. Erst nach wochenlangem Tüfteln, testen und optimieren haben wir das Problem gelöst. Da gab es schon viel schlimmere Probleme, aber das Bsp versteht jeder Softie. Warum erzähle ich das ? Weil das ein Scheiss Feld war, was so harmlos in irgendeiner Maske in der GUI erscheint, fürn Anforderungsmanager vollkommen langweilig, für die Entwickler viel Arbeit. Mit Scrum dann haha, brauchen wir doch nicht, oder anders, oder so, hmm? Da sprinten wir durch. Wir müssen innovativer umd flexibler werden ! Erst mal was raushauen und dann entscheiden, wo es lang geht.
Motzkopp schrieb: > Mit Scrum dann haha, brauchen wir doch nicht, oder anders, oder so, hmm? > Da sprinten wir durch. Scrum ist doch für Deine Aufgaben überhaupt nicht sinnvoll. Das ist so, als wenn jemand 13er Maulschlüssel verteufelt, weil die Prüfung einer 12V-Batterie damit nur unzureichen möglich ist.
Mark B. schrieb: > Ist kein Nullargument. Denk einfach mal bisschen nach, dafür ist dein > Gehirn ja da. Wenn niemand in einer Firma echte Kompetenz in Sachen > Software besitzt, und schon gar nicht die Personalabteilung, wie will > man dann einen guten Entwickler einstellen? Es fehlt einem ja dann die > Fähigkeit, beurteilen zu können wer wirklich gut ist. Nach deiner Logik wäre dann jede Firma noch in der produktionstechnischen Steinzeit, weil sie angeblich nicht in der Lage ist fähige Leute zu erkennen. Dafür hat Gott die Studienabschlüsse und Arbeitszeugnisse geschaffen. Wenn sich einer bewirbt mit 5 Jahren Erfahrung in Softwareengineering und Informatikstudium wird der auch Ahnung haben, jedenfalls mehr als der Maschinenbauer mit nebenher erworbenen Programmierkenntnissen oder E-Techniker mit MC-Fokus. Das Problem ist ein ganz anderes in diesen Firmen: Man hat noch gar nicht erkannt wie unprofessionell man dort arbeitet, das Gestümpere gilt dort als normal. Da wurschtelt halt der Maschinenbauer die Software irgenwie zusammen oder der E-Techniker die Steuerung aber wenns mal komplexer wird und über klassisches MC-Gefrickel hinausgeht glaubt er kann da wie bisher weiterfrickeln. Dazu kommt noch wie oben schon beschrieben, dass schnelle Ergebnisse gewünscht werden, der ahnungslose Vorgesetzte bestimmt also wie gearbeitet werden soll. Selbst wenn die Entwickler erkannt haben, dass sie mit dem Gefrickel nicht mehr weiterkommen und das ändern wollen würden, der Chef oder wer auch immer die Entscheidungsmacht hat, funkt mit seinen unrealistischen Zeitvorgaben immer dazwischen. Wenn ich schon in solchen Knallfroschbuden vom "Chefentwickler" höre dass Testen überflüssig ist aber denen ständig die Projekte um die Ohren fliegen und keinen Termin reissen. Fragt man die wie sie ihre Projekte planen schauen die einen an wie ein Mondkalb. Scrum, Projektmanagement, Testszenarien, alles unnützer Kram für die, der nur Zeit kostet. Denen rennen auch regelmässig die Fähigen Leute weg, weil die keine neuen Strukturen etablieren dürfen. Da muss erst mal Erkenntnis+Wille da sein, das man so wie man jetzt 'arbeitet' es völlig unprofessionell ist und das geändert werden muss.
Dick Boutsos schrieb: > Wenn ich schon in solchen Knallfroschbuden vom "Chefentwickler" höre > dass Testen überflüssig ist aber denen ständig die Projekte um die Ohren > fliegen und keinen Termin reissen. Fragt man die wie sie ihre Projekte > planen schauen die einen an wie ein Mondkalb. Scrum, Projektmanagement, > Testszenarien, alles unnützer Kram für die, der nur Zeit kostet. Denen > rennen auch regelmässig die Fähigen Leute weg, weil die keine neuen > Strukturen etablieren dürfen. Da muss erst mal Erkenntnis+Wille da sein, > das man so wie man jetzt 'arbeitet' es völlig unprofessionell ist und > das geändert werden muss. Richtig. Und warum ist das so? Weil man nicht versteht, wie es richtig gemacht werden muss (also die Entwicklung von Software). Und warum weiß man das nicht? Weil man sich in diesem Fachgebiet nicht auskennt. Wenn eine Firma clever genug ist, SW-Entwickler mit Berufserfahrung einzustellen und diese auch darüber entscheiden zu lassen, wie der Prozess der Entwicklung denn vonstatten gehen soll, dann ist ja gut. Aber ob das so in der Regel passiert? Da bin ich skeptisch.
Mark B. schrieb: > Weil man nicht versteht, wie es richtig > gemacht werden muss (also die Entwicklung von Software). Doch, von Zeit zu Zeit kommen dann solche Informatik-Experten und wollen eine 5-Mann-Entwicklung professionalisieren, so wie es bei EDV-SW (mehr oder weniger) gut funktioniert. Dann passieren folgende Dinge, die hier im Forum ja auch schon geschildert wurden: - Unsinnige, unhinterfragte Regeln, die im gegenwertigen Kontext keinen Sinn machen. (Stefan U: jeder Member-Zugriff nur über Getter/Setter) - Völlige Ausblendung des µC-Kontexts (Andreas S: Nein, die x kB-RAM im Datenblatt sind MB: ein µC mit so wenig RAM gäbe keinen Sinn) - Design in UML: Nicht nur schlecht geeignet für Automaten, meist auch nur gemalt, nicht modelliert (nicht nur, dass kein Code erzeugt wird, ... das Modell selber ist mangels Umgebung in sich selber nicht konsistent oder verifizierbar) - Frühe Entscheidungen (Dann haben die Leute, die keine Ahnung von SW haben, halt ihre wünsche nicht ausreichend durchdacht)
A. S. schrieb: > Doch, von Zeit zu Zeit kommen dann solche Informatik-Experten und wollen > eine 5-Mann-Entwicklung professionalisieren, so wie es bei EDV-SW (mehr > oder weniger) gut funktioniert. Dann passieren folgende Dinge, die hier > im Forum ja auch schon geschildert wurden: > > - Unsinnige, unhinterfragte Regeln, die im gegenwertigen Kontext keinen > Sinn machen. (Stefan U: jeder Member-Zugriff nur über Getter/Setter) Ein echter Informatik-Experte weiß natürlich, dass das Quatsch ist. Objekte sollen Nachrichten miteinander austauschen. Echte Informatik-Experten lesen zum Beispiel solche Artikel: https://www.javaworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html Und verstehen sie auch :-) Das Problem bleibt nach wie vor, zu erkennen wer denn nun ein echter Experte ist und wer ein Möchtegern-Experte... und sowas steht halt auf keinem Diplomzeugnis der Welt drauf.
:
Bearbeitet durch User
A. S. schrieb: > µC-Kontexts A. S. schrieb: > Mark B. schrieb: >> Weil man nicht versteht, wie es richtig >> gemacht werden muss (also die Entwicklung von Software). > > Doch, von Zeit zu Zeit kommen dann solche Informatik-Experten und wollen > eine 5-Mann-Entwicklung professionalisieren, so wie es bei EDV-SW (mehr > oder weniger) gut funktioniert. Dann passieren folgende Dinge, die hier > im Forum ja auch schon geschildert wurden: > > - Unsinnige, unhinterfragte Regeln, die im gegenwertigen Kontext keinen > Sinn machen. (Stefan U: jeder Member-Zugriff nur über Getter/Setter) > > - Völlige Ausblendung des µC-Kontexts (Andreas S: Nein, die x kB-RAM im > Datenblatt sind MB: ein µC mit so wenig RAM gäbe keinen Sinn) > > - Design in UML: Nicht nur schlecht geeignet für Automaten, meist auch > nur gemalt, nicht modelliert (nicht nur, dass kein Code erzeugt wird, > ... das Modell selber ist mangels Umgebung in sich selber nicht > konsistent oder verifizierbar) > > - Frühe Entscheidungen (Dann haben die Leute, die keine Ahnung von SW > haben, halt ihre wünsche nicht ausreichend durchdacht) Wer in Business Applikationen z.B. jedes Bit eines ints nutzt, um sich platzsparend Zustände zu merken, der kriegt in der Welt gewaltig hinter die Ohren, im µC-Kontext mag das ja sinnvoll sein. Das mit den Gettern und Settern hätte ich auch gesagt. Hauptgrund neben anderen Vorteilen: Ich kann da einen Breakpoint reinsetzen.
Mark B. schrieb: > Echte Informatik-Experten lesen zum Beispiel solche Artikel: > https://www.javaworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html > > Und verstehen sie auch :-) > > Das Problem bleibt nach wie vor, zu erkennen wer denn nun ein echter > Experte ist und wer ein Möchtegern-Experte... und sowas steht halt auf > keinem Diplomzeugnis der Welt drauf. "It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details." Was den für Implementierungsdetails ? Wo ist der Unterscheid zu public members, die ich ja dann stattdessen benutzen muss ? Ich bin auch kein Fan davon alle member Variablen mit gettern und settern auszustatten, sondern nur die, auf die ich von aussen zugreifen muss. "To see why, consider that there might be 1,000 calls to a getX() method in your program, and each call assumes that the return value is of a particular type. You might store getX()'s return value in a local variable, for example, and that variable type must match the return-value type. If you need to change the way the object is implemented in such a way that the type of X changes, you're in deep trouble. If X was an int, but now must be a long, you'll get 1,000 compile errors." Die kriege ich auch, wenn ich den Typ einer 1000 mal benutzen public member Variabe von int auf long ändere. Liebe Informatik Experten, ich habe es nicht verstanden, erklärt mir warum getter und setter schlechter sein sollen, als public members.
Wow, ist ja echt interessant. Der Krieg der Vorgehensmodelle :D Vielleicht wären Schulungen im Bereich der Komplexitätsforschung gar nicht so verkehrt. Man kann lernen komplexe Systeme zu erkennen und besser zu beurteilen. Und ich denke Software Entwicklung im wirtschaftlichen Umfeld stellt ein komplexes System dar. Es würde genügen die grundlegenden Wesenszüge solcher Systeme zu verstehen und was einzelne Veränderungen bewirken können. Und obwohl ich keine berufliche Erfahrung habe würde ich intuitiv wetten, dass es nicht das perfekte Modell gibt, genau wie es auch nicht die perfekte Programmiersprache gibt. Abhängig von diversen Faktoren kann ein Modell in einem Unternehmen besonders gut oder besonders schlecht funktionieren. Aufwand, Zeitbedarf, Effizienz, Flexibilität... diese Werte können nicht alle perfektioniert werden. Besonders große Flexibilität wird andere Werte zwangsläufig hochtreiben, etwa den Zeitbedarf. Wenn ein Modell so gestaltet ist dass es hohe Flexibilität bei möglichst geringem Zeitbedarf bietet, treibt möglicherweise den Aufwands Wert hoch weil es hohe Disziplin durch Einhaltung vieler Regeln bedarf um effizient und flexibel zu funktionieren. Da aber nicht alle im Unternehmen diszipliniert sind funktioniert es nicht wie es theoretisch sollte. Bei Programmiersprachen ist es ja auch so. Besonders einfache Programmiersprachen etwa Scriptsprachen sind langsamer. Und eine Programmiersprache wie Rust die Vorteile einer GC Sprache ohne einen GC haben will bezahlt den Preis mit einer höheren Lernkurve der Sprache, was dann auch für viele eine problematische Hürde darstellt. Vieles deutet also darauf hin dass es gar kein perfektes Vorgehensmodell in Projekten geben kann. Maximal flexibel, maximal schnell, maximal günstig, maximal effizient, maximal leicht realisierbar... geht also nicht. Was neue Modelle oft auszeichnet ist eine Verschiebung eines Wertes nach oben ohne den Verweis auf die zwangsläufige Senkung eines anderen Wertes. Also es kommt z.B. ein neues Modell dass viel mehr Flexibilität und Zeitersparnis verspricht. Erst die Praxis zeigt dann dass es dies beispielsweise mit einer höheren Komplexität für die Beteiligten bezahlt, was dann bei manchen nicht funktioniert, weil die Beteiligten überfordert sind. Während die durchschnittliche Kompetenz in einem anderen Unternehmen höher ist und dort funktioniert es etwas besser. Und dann streiten sich die Leute darüber welches System besser sei :D
motzkopp schrieb: > Liebe Informatik Experten, ich habe es nicht verstanden, erklärt mir > warum getter und setter schlechter sein sollen, als public members. Getter und Setter sind genauso schlecht wie public Members! Hier mal ein fiktives Beispiel irgendeiner Connection-Klasse. Die ersten beiden Klassen sind schlecht, da public Zugriff auf Implementierungsdetails (enum-Member) besteht. In der 3. Klasse ist der Zugriff komplett gekapselt, man kann das Objekt nach seinem Zustand fragen.
1 | // some C# |
2 | public enum State |
3 | {
|
4 | Open, Closed |
5 | } |
6 | |
7 | public class Connection |
8 | {
|
9 | // BAD: public member |
10 | public State ConnectionState; |
11 | } |
12 | |
13 | public class Connection |
14 | {
|
15 | // BAD: public setter/getter |
16 | public State ConnectionState { get; set; }
|
17 | } |
18 | |
19 | public class Connection |
20 | {
|
21 | // GOOD: private setter/getter |
22 | private State ConnectionState { get; set; }
|
23 | public bool IsOpen() { return ConnectionState == State.Open; }
|
24 | public bool IsClosed() { return ConnectionState == State.Closed; }
|
25 | } |
Ändert man den enum, sind bei den ersten beiden Klassen alle Aufrufe im Client-Code zu ändern, die auf den enum zugreifen. Bei der 3. Klasse betreffen die Änderungen nur die Klasse selbst. merciless
Dirk K. schrieb: > motzkopp schrieb: >> Liebe Informatik Experten, ich habe es nicht verstanden, erklärt mir >> warum getter und setter schlechter sein sollen, als public members. > > Getter und Setter sind genauso schlecht wie public Members! Na, dann mich ich erstmal beruhigt, wobei ich persönlich die Getter und Setter wesentlich besser finde, wegen Breakpoint setzen und mögliche Modifizierung an zentraler Stelle. > > public class Connection > { > // GOOD: private setter/getter > private State ConnectionState { get; set; } > public bool IsOpen() { return ConnectionState == State.Open; } > public bool IsClosed() { return ConnectionState == State.Closed; } > } > > Ändert man den enum, sind bei den ersten beiden Klassen > alle Aufrufe im Client-Code zu ändern, die auf den enum > zugreifen. Bei der 3. Klasse betreffen die Änderungen > nur die Klasse selbst. > > merciless Du hast geschummelt. Hier gibt es noch ein Mapping zwischen einem Enum und einem Boolean Wert, was die Abstraktion des Enums ermöglicht. Klar muss dann der Rest des Code das Enum nicht kennen. Was ist, wenn ich wirklich ein int haben will ?
Nachtrag: Schummeln im Sinne eines Informationsverlust, der nur aufging, weil der Status nur zwei Zustände haben kann. Du kannst ja mal mit einem byte das Spiel betreiben: private byte a; .. public bool IsMinus128(a == -128) .. public bool Is0(a == 0) public bool Is1(a == 1) public bool Is2(a == 2) public bool Is3(a == 3) .. dann kannst du auch den internen Datentyp von byte auf int ändern, ohne das der Rest des Codes betroffen ist ;).
motzkopp schrieb: > Liebe Informatik Experten, ich habe es nicht verstanden, erklärt mir > warum getter und setter schlechter sein sollen, als public members. Auf die Daten innerhalb eines Objekts soll man möglichst gerade nicht von außerhalb der Klasse beliebig zugreifen können. Wenn man das macht, hat man ja gerade keine Datenkapselung. Außerdem kann man dann die Implementierung einer Klasse nicht ändern, wenn anderer Code da immer beliebig auf deren Membern herumwühlt.
motzkopp schrieb: > Du hast geschummelt. Hier gibt es noch ein Mapping zwischen einem Enum > und einem Boolean Wert, was die Abstraktion des Enums ermöglicht. Klar > muss dann der Rest des Code das Enum nicht kennen. Was ist, wenn ich > wirklich ein int haben will ? Ich könnte den enum auf 47 verschiedene Werte aufbohren, dann müsste ich im o.g. Beispiel 47 Methoden IsXYZ() haben. Dann muss ich aber die gesamte Architektur in Frage stellen. Als aller erstes sollte man sich die Frage stellen, wieso überhaupt Client-Code Kenntnisse von inneren Zuständen eines Objektes haben muss. In den meisten Fällen ist das auf eine schlechte Architektur zurückzuführen. In meinem Beispiel würde ich dann die 47 Zustände in einer dedizierten State-Machine kapseln. motzkopp schrieb: > Nachtrag: Schummeln im Sinne eines Informationsverlust, der nur aufging, > weil der Status nur zwei Zustände haben kann. Du kannst ja mal mit einem > byte das Spiel betreiben: > > private byte a; > .. > public bool IsMinus128(a == -128) > .. > public bool Is0(a == 0) > public bool Is1(a == 1) > public bool Is2(a == 2) > public bool Is3(a == 3) Und dieser Quatsch sagt mir, dass du nicht wirklich Ahnung von Software-Entwicklung hast. Auf diese Art kann man jedes Beispiel ins Lächerliche ziehen. Natürlich muss die Information (enum) gemappt werden, wie soll sonst die Kapselung erfolgen. merciless
:
Bearbeitet durch User
> Und dieser Quatsch sagt mir, dass du nicht wirklich Ahnung > von Software-Entwicklung hast. Auf diese Art kann man jedes > Beispiel ins Lächerliche ziehen. > > merciless Aber, aber, lieber Kollege ! Es ware hier die Rede von den so schlechten getter und settern. Da will ich als Begründung nicht irgendeinen konstruierten Fall haben. Der einzige vollfertige Ersatz sind public members und die halte ich für wesentlich schlechter !
Mark B. schrieb: > motzkopp schrieb: >> Liebe Informatik Experten, ich habe es nicht verstanden, erklärt mir >> warum getter und setter schlechter sein sollen, als public members. > > Auf die Daten innerhalb eines Objekts soll man möglichst gerade nicht > von außerhalb der Klasse beliebig zugreifen können. Wenn man das macht, > hat man ja gerade keine Datenkapselung. Außerdem kann man dann die > Implementierung einer Klasse nicht ändern, wenn anderer Code da immer > beliebig auf deren Membern herumwühlt. Jajaja, das ist alles klar. Wenn ich aber nun mal nen paar Werte der Klasse setzen oder lesen will, hmmm ? Ganz darauf verzichten ?
Jo man; Ihr habt's voll drauf. Meine Forderung: Mindestlohn 150 k€/a für Progger!
motzkopp schrieb: >> Und dieser Quatsch sagt mir, dass du nicht wirklich Ahnung >> von Software-Entwicklung hast. Auf diese Art kann man jedes >> Beispiel ins Lächerliche ziehen. >> >> merciless > > Aber, aber, lieber Kollege ! Es ware hier die Rede von den so schlechten > getter und settern. Da will ich als Begründung nicht irgendeinen > konstruierten Fall haben. Der einzige vollfertige Ersatz sind public > members und die halte ich für wesentlich schlechter ! Dann, lieber Kollege, nenne doch mal ein Beispiel, wo du von außen unbedingt einen Wert in das Objekt setzen musst. Wenn sich das nicht umgehen lässt, dann würde ich einen Setter verwenden, weil man sonst keine Möglichkeit hat, auf die Änderung eines Wertes zu reagieren (vielleicht muss die Gültigkeit geprüft werden, oder eine Neuberechnung angestoßen werden, etc.). merciless
Dirk K. schrieb: > Dann, lieber Kollege, nenne doch mal ein Beispiel, > wo du von außen unbedingt einen Wert in das Objekt > setzen musst. Wenn sich das nicht umgehen lässt, dann > würde ich einen Setter verwenden, weil man sonst keine > Möglichkeit hat, auf die Änderung eines Wertes zu reagieren > (vielleicht muss die Gültigkeit geprüft werden, oder > eine Neuberechnung angestoßen werden, etc.). > > merciless Ich persönlich nutze Setter selten, ich versuche alles über den Konstruktor zu übergeben. Aber manchmal lässt es sich nicht vermeiden, die Bsp hast du ja selber schon genannt. Also halten wir fest: Standardlehrbuch-Empfehlung getter und setter zu benutzen (als Ersatz für public members) - Richtig und Gut ! Gegenempfehlungen beziehen sich nur auf absolute Feinheiten, ist aber eine Gelegenheit sich als Creme de la Creme Informatik Experte zu positionieren !
Motzkopp schrieb: > Richtig und Gut ! > Gegenempfehlungen beziehen sich nur auf absolute Feinheiten, ist aber > eine Gelegenheit sich als Creme de la Creme Informatik Experte zu > positionieren ! Eine Frage an die Experten (wobei Du, Motzkopp, ja nach eigenem Bekunden auch eher EDV machst): Wer von Euch auf dieser Welle macht denn wirklich embedded Maschinen-SW? Nicht GUI, nicht Visu, nicht Eingabe von Ablaufplänen, sondern wirkliche Steuerungstechnik, (weniger Regelungstechnik, da das ja eher Matlab-Code ist)? Also Wenn Sensor so, dann Aktor so, wenn Zeit abgelaufen, dann, wenn dies dann das? Die meisten Mantras von Kapselung und keinen globalen Objekten greifen da nämlich meist nicht oder nur schlecht. Es gibt nämlich einen globalen Kontext, mit realen (nicht virtuellen) Teilen, die in einer konkreten, physischen Abhängigkeit zueinander stehen. Ich unterscheide es in virtuelle Objekte (ein Quadrat auf der Zeichenfläche, ein Menber in der Adressliste, ein Fehlerbit im Logfile) und reale Objekte (das Rad vorne Links im Auto). Virtuelle Objekte sind gut OOP-kapselbar, können fast beliebig instanziiert werden (50 neue Quadrate, neue Mitglieder? Nur zu). Konkrete Objekte werden dann meist alibi-mäßig genauso gehandhabt ("ich leite alle 4 Räder von der Klasse Rad ab! und instanziiere sie dann." Super, hier ein Lutscher). Das ist quatsch. Es gibt genau 4 Räder am Auto, und alle 4 haben spezifische Eigenschaften und es macht überhaupt keinen Sinn, ein 5tes zu instanziieren oder nur 3. Kein DSP kommt damit klar, wenn man ein Rad weglässt oder 2 tauscht. Globale Objekte spiegeln hier nur die Aufgabe wieder und sind nicht böse. Wie weit das ignoriert wird, zeigt sich, wenn Autosar (wo Milliarden hinterstehen) als Gebastel angesehen wird, weil es den EDV-Mantras nicht folgt. Ähnliches gilt für die Zeit, die in Steuerungstechnik eine viel breitere Rolle einnimmt als in der EDV, wo einfach nur alles akzeptabel schnell und gbgf. transaktionssicher sein muss. Das, genau das ist der Unterschied, warum die EDV-Erfahrung der Informatiker im Maschinenbau (und genau darum ging es dem TO) regelmäßig scheitert.
A. S. schrieb: > Ähnliches gilt für die Zeit, die in Steuerungstechnik eine viel breitere > Rolle einnimmt als in der EDV Fast jeder der Infrommatiker, die von der Hochschule kommend meine Hardware zur Maschinensteuerung zu programmieren hatten, schaffte es binnen weniger Tage, dass die Steuerung "zu langsam" und die Aufgabe damit nicht lösbar ist. Sie fragen dann regelmäßig nach mehr Rechenleistung um die nötigen Reaktionszeiten im 100µs-Bereich zuverlässig ohne großen Jitter einhalten zu können! Regelmäßig nehme ich sie dann an die Hand und zeige ihnen, was der Compiler da für umständliches Zeug aus ihrem umständlichen Zeug macht. Früher oder später hat es dann noch jeder von ihnen kapiert, wie man z.B. Funktionsaufrufe samt Parameterübergabe so zu gestalten hat, dass sie effizient umgesetzt werden. Sie finden heraus, dass es schneller ist, für ein Flag ein 32 Bit-Wort zu nehmen, als viele Flags in ein einziges Wort zusammenzupacken. Und kaum hat man die grundlegenden Grundlagen zum prozessor- und compilerfreundlichen Programmieren gelernt, ist der Rechner auf einmal wieder schnell genug, obwohl er nur 4 Cores mit je 1GHz hat...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Fast jeder der Infrommatiker, die von der Hochschule kommend meine > Hardware zur Maschinensteuerung zu programmieren hatten Jetzt lästern schon die Mods verallgemeinernd über Informatiker... Waren das denn auch Informatiker mit Embedded Spezialisierung? Können frisch aus der Hochschule kommende Ings das besser? Als Embedded-Spezialisierter Informatiker wird man von "normalen" Informatikern belächelt weil man kein Experte in PHP, nodejs, Mobile App Development, ... ist und nur so komisches Elektronik Zeug macht. Von Ings muss man sich anhören dass Ings das alles besser können... Toll! Ein kleines bisschen wie bei Immigranten 2. Generation, welche hier als Ausländer und in der Heimat der Eltern als Deutsche gelten. Die habens auch nicht leicht...
Das sind nur Lothars Tagträume. In denen verarbeitet er Neid auf Informatiker. Als Mod sollte man sich etwas besser im Griff haben, als hier dumpf auf das beliebte Ing vs. Inf zu gehen, auch wenn es dafür Jubel vom Pöbel gibt.
Programmierer schrieb: > Als Embedded-Spezialisierter Informatiker wird man von "normalen" > Informatikern belächelt weil man kein Experte in PHP, nodejs, Mobile App > Development, ... ist und nur so komisches Elektronik Zeug macht. Von > Ings muss man sich anhören dass Ings das alles besser können... Toll! Da ist ein wenig was dran. grins Ich finde aber nicht schlimm, dass es so ist.
Programmierer schrieb: > Lothar M. schrieb: >> Fast jeder der Infrommatiker, die von der Hochschule kommend meine >> Hardware zur Maschinensteuerung zu programmieren hatten > > Jetzt lästern schon die Mods verallgemeinernd über Informatiker... Nein, das tut Lothar nicht. Es geht offenbar nur um diejenigen, die "Hardware zur Maschinensteuerung zu programmieren hatten". > Waren > das denn auch Informatiker mit Embedded Spezialisierung? Können frisch > aus der Hochschule kommende Ings das besser? Das ist die Frage. Als ich damals Informatik studiert habe, musste man ein Nebenfach belegen, also eine Art Spezialisierung wählen. Bei mir war das Elektrotechnik inkl. (natürlich) Mikrocontrollerprogrammierung und dementsprechend hätte ich vermutlich mit Lothars Aufgabenstellung weniger Probleme gehabt als seine heutigen Infos. Wie sieht das heutzutage aus? > Als Embedded-Spezialisierter Informatiker wird man von "normalen" > Informatikern belächelt weil man kein Experte in PHP, nodejs, Mobile App > Development, ... ist und nur so komisches Elektronik Zeug macht. Von > Ings muss man sich anhören dass Ings das alles besser können... Toll! Das schreibt Lothar nicht. Eher, dass es das heutige Abstraktionsniveau der Software immer noch spielend schafft, selbst schnellste Controller an ihr Limit zu treiben, wenn man sich nicht mal klar gemacht hat, was der Compiler mit dem Code anstellt. Und da hat er Recht. (schreibe ich als Dipl.-Inf. ;-)
Dirk K. schrieb: > Ändert man den enum, sind bei den ersten beiden Klassen > alle Aufrufe im Client-Code zu ändern, die auf den enum > zugreifen. In diesem Sinne also nur noch Klassen ohne jegliches öffentliche Interface? Und auch keine öffentlichen Funktionen mehr in jeglichem Code? Denn man könnte ja gezwungen sein das API zu ändern und dann müssten alle Benutzer angepasst werden? Sorry, aber diese Argumentation die Du da vorgebracht hast ist ungültig. Bei einem öffentlichen API muss man halt vorher mal tief in sich gehen und scharf nachdenken und planen bevor man wild drauf los schreibt damit man es später möglichst nicht mehr so oft ändern muss. Und man macht es auch nicht breiter als gerade eben notwendig. Und ob da jetzt ein Setter oder Getter oder Property oder sonstige öffentliche Methode oder Funktion dabei ist macht dabei nicht den geringsten Unterschied.
Ich würde mich einem Vorposter anschließen, das man frisch von der Hochschule erstmal in nix Erfahrung hat. Gilt für Infos genauso wie für Ings. Ansonsten gilt für Leute, die eher EDV machen: Da kommt es sehr wohl auf Performance an, nur nicht auf 100µs. Es geht meist um Massendaten und der erste Blick bei Performaceproblemen richtet sich immer gegen IO/Datenbankabfragen. Weniger und sehr sehr schnelle Abfragen ist da das Ziel. Da kann man was rausholen ! Danach kommen irgenwelche Schleifen über Massendaten und was die da so machen. Danach kommt lange nichts. Für Optimierungen des Codes Richtung compilerfreundlichkeit muss man schon sehr verzweifelt sein. Ich habe schon oft Code gesehen, der furchtbar kompliziert und umfangreich war, aber eigentlich nur einfache Dinge machte. Da hat jemand ziemlich unverständlichen Code hinterlassen, vermutlich ewig Zeit verbraten, nur um die letzten µs rauszuholen, vollkommen unnötig. Das ist bei Business-Apps nicht angesagt. Optimierungen, die den Code komplizierter machen, nur wenn es unbedingt sein muss und an letzter Stelle, wenn man bereits erstere erwähnte Möglichkeiten ausgeschöpft hat ! Daher haben logischweise Leute aus anderern Bereichen mehr Übung darin.
Chris D. schrieb: > Nein, das tut Lothar nicht. Es geht offenbar nur um diejenigen, die > "Hardware zur Maschinensteuerung zu programmieren hatten". Und auch Maschinensteuerung ist etwas was Informatiker durchaus beherrschen können. Chris D. schrieb: > Wie sieht das heutzutage aus? Genau so. Es gibt z.B. die Spezialisierung "Embedded Systems". Da lernt man Regelungstechnik, Sichere Systeme (FuSi und so), Mikrocontroller-Programmierung in C und C++, E-Technik-Grundlagen, DSP, Adaptive Filter usw. Sollte doch für den Maschinenbau gar nicht so falsch sein. Chris D. schrieb: > Eher, dass es das heutige Abstraktionsniveau der Software immer noch > spielend schafft, selbst schnellste Controller an ihr Limit zu treiben, Das hat aber nichts mit Informatikern an sich zu tun.
PS: In der Informatik-Spezialisierung "Embedded Systems" gibt es auch Robotik-Fächer wo man Dinge wie Inverse Kinematik, ROS, Roboter-Simulation usw lernt. Es gibt sogar einen Informatik Master-Studiengang extra komplett für Robotik, u.a. mit Teilnahme am Robocup. Man macht teilweise auch Schaltungsentwicklung und Platinenlayouts. Die Teilnahme an der Formula Student (sehr viel hardwarenahe Programmierung und Fahrzeugtechnik) wird gefördert. Ist auch nicht so weit weg von Industrie und Maschinenbau, oder?
Programmierer schrieb: > Chris D. schrieb: >> Nein, das tut Lothar nicht. Es geht offenbar nur um diejenigen, die >> "Hardware zur Maschinensteuerung zu programmieren hatten". > > Und auch Maschinensteuerung ist etwas was Informatiker durchaus > beherrschen können. Ja, natürlich - ich mache (neben anderem) genau das :-) > Chris D. schrieb: >> Wie sieht das heutzutage aus? > > Genau so. Es gibt z.B. die Spezialisierung "Embedded Systems". Da lernt > man Regelungstechnik, Sichere Systeme (FuSi und so), > Mikrocontroller-Programmierung in C und C++, E-Technik-Grundlagen, DSP, > Adaptive Filter usw. Sollte doch für den Maschinenbau gar nicht so > falsch sein. Danke für die Info. Ja, das müsste dann doch passen - wenn Lothars Infos diese Vertiefungsrichtung auch hatten. Aber man darf natürlich auch nicht vergessen, dass man nicht viel kann, wenn man frisch aus dem Studium kommt und nichts nebenbei gemacht hat (daher unterstütze ich auch Formula Student - ist eine tolle Sache). Wir Älteren vergessen das sehr oft. Und dass sie nur wenig Zeit brauchten, um Lothars Erfahrungen aufzunehmen, zeigt ja, dass sie durchaus fähig sind. > Chris D. schrieb: >> Eher, dass es das heutige Abstraktionsniveau der Software immer noch >> spielend schafft, selbst schnellste Controller an ihr Limit zu treiben, > > Das hat aber nichts mit Informatikern an sich zu tun. Richtig. Aber ehrlich: irgendwo ist das doch Wahnsinn, wenn für eine simple Taschenlampen-App (also im Prinzip etwas, das auf Knopfdruck eine LED ein- und ausschalten muss) mittlerweile tatsächlich 5 MByte heruntergeladen werden müssen. Und dann schaut man sich eine alte Sinumerik 810T-CNC-Steuerung an, die komplett keine 512kByte belegt und auf einem 80186 mit 16MHz läuft und ist erstaunt, wieviel das Ding bereits beherrscht - in Echtzeit.
:
Bearbeitet durch Moderator
Chris D. schrieb: > Aber ehrlich: irgendwo ist das doch Wahnsinn, wenn für eine simple > Taschenlampen-App (also im Prinzip etwas, dass auf Knopfdruck eine LEDe > ein- und ausschalten muss) mittlerweile tatsächlich 5 MByte > heruntergeladen werden müssen. Wobei App-Bloat eine ganz eigene Problematik ist, die mit dem Programmierer-Problem für Maschinensteuerung nichts zu tun hat.
Walter T. schrieb: > Wobei App-Bloat eine ganz eigene Problematik ist, die mit dem > Programmierer-Problem für Maschinensteuerung nichts zu tun hat. Ich bin mir da nicht sicher, ob man das trennen kann. Denn offenbar führt genau die Denkweise "Wir haben unendlich viel Speicher und Rechenleistung und tolle Wollmilchsäue als Bibliotheken" zu solchen Programmkonstrukten, bei denen ohne größere Überlegung sehr große Datenmengen per Funktionsaufruf übergeben werden und so die Echtzeitfähigkeit sprengen. Daher auch meine Frage, ob man auch als heutiger Informatiker nochmal "ganz unten" nachschaut (und bspw. in Assembler programmiert) und ein Gespür dafür vermittelt bekommt, was Code effizient macht. Erfreulicherweise wird das ja in der entsprechenden Vertiefungsrichtung auch noch gemacht. Ich nehme deswegen an, dass Lothars Schützlinge einfach aus einem anderen Bereich kamen. Aber vielleicht noch zum Thema Maschinenbausoftware: wenn ich das hier so lese, dann bin ich doch froh, dass wir hier nur zu zweit sind. Aber: schon hier muss geplant werden (allerdings ohne irgendwelche spezielle Software). Sehr bewährt hat sich, dass man nach dem ersten Anforderungskatalog eines Kunden eine gewisse Zeit verstreichen lässt, in der man selbst weitere Punkte sammelt und in der dem Kunden garantiert noch "Kleinigkeiten" einfallen - und erst dann überhaupt in die Softwareplanung geht. Und da ist dann noch lange keine einzige Zeile Code geschrieben. Aber auch das "Was könnte der Kunde noch zusätzlich wollen?" hat viel mit Erfahrung zu tun, ebenso wie den Code so zu gestalten, dass später noch leicht Erweiterungen möglich sind.
Chris D. schrieb: > Aber man darf natürlich auch nicht vergessen, dass man nicht viel kann, > wenn man frisch aus dem Studium kommt und nichts nebenbei gemacht hat Ja, aber das gilt für alle Studiengänge. Tatsächlich sind Informatiker hier eher im Vorteil, weil man im Studium und auch privat durchaus programmieren üben kann. Maschinen bauen oder Labor-Experimente sind da schon etwas schwieriger. Chris D. schrieb: > Aber ehrlich: irgendwo ist das doch Wahnsinn, wenn für eine simple > Taschenlampen-App (also im Prinzip etwas, das auf Knopfdruck eine LED > ein- und ausschalten muss) mittlerweile tatsächlich 5 MByte > heruntergeladen werden müssen. Das ist aber ein ganz anderes Problem. Google hat hier entschieden, dass das das kleinere Übel ist: Die Apps bringen ihre eigenen Libraries und Frameworks mit, alles zusammen in der .apk Datei. Das führt dazu dass beliebte Frameworks - auch die, die von Google selbst stammen - dutzendfach auf dem selben Gerät installiert sind. Dies ließe sich durch einen Paketmanager wie APT lösen, welcher die Bibliotheken bei Bedarf einmalig zentral installiert, die dann von den Apps benutzt werden können. Ein solches System wäre, wie eben APT, aber derart komplex, schwer beherrschbar und damit auch fehleranfällig, dass man das dem Normalo-Android-User nicht zutrauen wollte. Unter Windows kennt man das als "Dll-Hell". Die pragmatische Lösung ist es, nur ein Minimum an gemeinsamer Funktionalität mit Android selbst auszuliefern (das Android-Framework), und den Rest bringen die Apps selbst mit. Die funktionieren dafür praktisch "immer" und man kann sie auch leichter wieder deinstallieren, ohne Abhängigkeits-Chaos. Dass APT in der Praxis so gut funktioniert ist den Maintainern zu danken, welche unermüdlich mit riesigem Aufwand die Paketdatenbanken pflegen. Das ist im schnelllebigen Mobile-Bereich, wo ständig neue Apps und App-Versionen herauskommen, kaum zu stemmen. Wer mal eine Distro genutzt hat, welche bei allen Paketen immer brandaktuelle Versionen ausliefert kann ein Lied singen von unlösbaren Abhängigkeitsproblemen (die gerne auch Updates komplett blockieren), die man nur durch komplizierte Fummelei auflösen kann. Dazu kommt, dass Apps Medien (Grafik, Video, Ton) für verschiedene Sprachen und verschiedene Display-Auflösungen mitliefern. Das kann auch eine Menge Platz belegen. Google versucht das mit App Bundles in den Griff zu bekommen, was aber seine eigenen Probleme hat. Chris D. schrieb: > Und dann schaut man sich eine alte Sinumerik 810T-CNC-Steuerung an, Kann man da auch beliebige Apps von Drittherstellern installieren ohne dass diese sich in die Quere kommen oder unauthorisierten Zugriff auf Daten erhalten, eigene Apps ultrakomfortabel mit einer IDE entwickeln, komplexe GUIs mit Medieninhalten bauen, Daten über verschiedene Netzwerke austauschen, und sodass das ganze auch noch ziemlich sicher ist? Das Problem, beliebige Anwendungen und Komponenten kombinieren und flexibel, effizient, robust und benutzerfreundlich ausliefern zu können ist praktisch ungelöst. Wenn jemand eine Lösung hat, immer raus damit.
Bernd K. schrieb: > Dirk K. schrieb: >> Ändert man den enum, sind bei den ersten beiden Klassen >> alle Aufrufe im Client-Code zu ändern, die auf den enum >> zugreifen. > > In diesem Sinne also nur noch Klassen ohne jegliches öffentliche > Interface? Und auch keine öffentlichen Funktionen mehr in jeglichem > Code? Denn man könnte ja gezwungen sein das API zu ändern und dann > müssten alle Benutzer angepasst werden? Sorry, aber diese Argumentation > die Du da vorgebracht hast ist ungültig. Nope, es muss das Ziel sein, Abhängigkeiten zu minimieren und Kapselung zu maximieren. Aber diesen Idealfall wird man in der Praxis nie erreichen. Ein gutes Design findet dann halt einen Kompromiss, mit dem man Leben kann. Das wiederum ist das, was viele Nicht-Informatiker nicht verstehen und davon ausgehen, Overengineering macht den guten Informatiker aus - mitnichten. Ich programmiere typischerweise keine Software für Embedded Systeme, hatte aber auch schon Projekte, die zeitkritisch waren. Man fängt halt bei einer Lösung an, die nahe am Ideal liegt und muss dann Kompromisse finden, um die Ausführungszeit zu drücken. Da schrumpft dann die Klassenhierarchie und Indirektionen durch Benutzung von Interfaces verschwinden etc. Die Leute aus der Hardwareecke rotzen typischerweise ein paar tausend Zeilen globale C-Funktionen hin und meinen gute Software zu schreiben. Denen fehlt meistens der Blick aus der anderen Richtung. Erst sauberen Code schreiben, auf Wartungsfreundlichkeit, achten etc., dann kann man über Optimierungen reden, um den Code schneller zu machen. merciless
:
Bearbeitet durch User
Programmierer schrieb: > Jetzt lästern schon die Mods verallgemeinernd über Informatiker... Ich hatte die paar, mit denen ich direkt zu tun hatte, beispielhaft angebracht. Wo habe ich Ansprüche auf die Allgemeingültigkeit meiner Beobachtungen gestellt? Programmierer schrieb: > Chris D. schrieb: >> Nein, das tut Lothar nicht. Es geht offenbar nur um diejenigen, die >> "Hardware zur Maschinensteuerung zu programmieren hatten". > Und auch Maschinensteuerung ist etwas was Informatiker durchaus > beherrschen können. Tun die, die ich da "nachgebildet" habe, ja jetzt auch. Nur wussten sie das eben vorher offensichtlich nicht. Oder nicht hinreichend. Chris D. schrieb: > Und dass sie nur wenig Zeit brauchten, um Lothars Erfahrungen > aufzunehmen, zeigt ja, dass sie durchaus fähig sind. Ja, es wurde ihnen einfach nicht beigebracht. Oder es wurde nicht darauf hingedeutet, dass das wichtig wäre. Oder sie haben es vergessen. Oderwasweißich. Wobei nach eigener Aussage bis dahin die wenigsten mal ein Assemblerfile ihres Codes angeschaut oder gar näher analysiert hatten... Programmierer schrieb: > Tatsächlich sind Informatiker hier eher im Vorteil, weil man im Studium > und auch privat durchaus programmieren üben kann. Maschinen bauen oder > Labor-Experimente sind da schon etwas schwieriger. Allerdings ist es halt so, dass man zum Lernen einer Srategie zur Steuerungsprogrammierung eben auch eine Steuerung haben muss, die im Ideal auch was steuert. Denn sonst lernt man bestenfalls, Reaktionszeiten im 100ms Bereich zu programmieren, weil ein Mensch an der Tastatur oder der Maus eben nicht viel schneller ist. Und an der Maschine/Hardware selber muss man dann eben 1000 mal schneller reagieren und darf auch nicht unnötig herumtrödeln. Am Rande: gerade habe ich das "Problem" an der Backe, dass ein Software-Kollege vor dem Speichern von Logdaten den Powerfail nicht abfragt und deshalb SD-Karten korrumpiert werden. Der hat mich dann vorwurfsvoll angeschaut und gemeint, das müsse doch die Hardware sicherstellen, dass das Schreiben funktioniert... :-o
:
Bearbeitet durch Moderator
Dirk K. schrieb: > Nope, es muss das Ziel sein, Abhängigkeiten zu > minimieren und Kapselung zu maximieren. Das erreichst Du aber nicht mit pauschalen Fausregeln wie oben (die von sich aus an dem Grundproblem gar nichts ändern) sondern nur durch viel allgemeinere Praktiken und Überlegungen bei der Planung der Architektur die sich meist nicht auf einfaches "tu dieses anstatt jenem dann ist alles gut" herunterbrechen lassen. Über dieses Thema kann man ganze Bücher schreiben. Wenn ein naiver Anfänger nämlich jetzt liest daß ein öffentliches enum per se böse sein soll und damit im Hinterkopf dann überall mit aller Gewalt anfängt seinen Code seitenweise mit is_foo(), is_bar(), is_baz(), ..., set_foo(), set_bar(), set_baz(), ... vollzupflastern und dann als nächstes überall nochmal seitenweise if/else oder switch-Konstrukte braucht um dieses umständliche API zu bedienen anstatt einfach den wert des enums zu speichern oder weiterzureichen ist niemandem gedient! Es gibt enums da weiß man von vornherein daß sie sich niemals ändern werden und es gibt enums da weiß man vorher schon daß sie unvollständig sind. Aber gerade letztere haben so viele Elemente daß Dein is_foo()/is_bar()/... Ansatz sowieso vollkommen unpraktikabel ist, dann nimmt man (zumindest nach außen hin) vielleicht auch kein enum sondern numerische Konstanten, aber das muß man im Einzelfall entscheiden: Wer benutzt diese API überhaupt? Kann ich in einem einzigen commit den Datentyp überall ändern ohne daß es jemals nach außen dringt? Auf jeden Fall wie auch immer man es macht, es hat nichts mit Properties vs setter/getter zu tun, das ändert absolut nichts am Grundproblem wie man API-Brüche vermeidet. Einen Setter braucht man in der Regel nur dann wenn das Setzen auch eine Aktion auslösen soll, meist weiß man das aber vorher schon, und da kommt es auch auf die Programmiersprache an, es gibt auch Sprachen da kann man nachträglich bei Bedarf noch hooks an Property-Zugriffe dranhängen und am öffentlichen API ändert sich dadurch dann gar nichts, oder man kann Properties haben die read-only sind, da kann man sich den ganzen getter/setter-Bloat und die daran hängende ewige Diskussion um die Sinnhaftigkeit dann komplett sparen!
Ing schrieb: > nahmhaften Unternehmen dieser Branche komplexe (Hochsprachen-)Software Also im Maschinenbau wären das in dieser Reihenfolge VB .net und VB 6 / RealBasic / Xojo und neuerdings PyQt
Bernd K. schrieb: > Dirk K. schrieb: >> Nope, es muss das Ziel sein, Abhängigkeiten zu >> minimieren und Kapselung zu maximieren. > > Das erreichst Du aber nicht mit pauschalen Fausregeln wie oben > ... > Wenn ein naiver Anfänger nämlich jetzt liest daß ein öffentliches enum > per se böse sein soll und damit im Hinterkopf dann überall mit aller > Gewalt anfängt seinen Code seitenweise mit is_foo(), is_bar(), is_baz(), > ..., set_foo(), set_bar(), set_baz(), ... vollzupflastern und dann als > nächstes überall nochmal seitenweise if/else oder switch-Konstrukte > braucht um dieses umständliche API zu bedienen anstatt einfach den wert > des enums zu speichern oder weiterzureichen ist niemandem gedient! Ja immer schön auf dem enum rumreiten: Das war ein Beispiel, um Kapselung zu demonstrieren, das kann man doch nicht verallgemeinern! Ach, heute ist ja Freitag... merciless
Lothar M. schrieb: > Am Rande: gerade habe ich das "Problem" an der Backe, dass ein > Software-Kollege vor dem Speichern von Logdaten den Powerfail nicht > abfragt und deshalb SD-Karten korrumpiert werden. Der hat mich dann > vorwurfsvoll angeschaut und gemeint, das müsse doch die Hardware > sicherstellen, dass das Schreiben funktioniert... :-o Im Grunde genommen hat er ja auch Recht: Keine Software der Welt kann etwas gegen einen plötzlichen Ausfall der Versorgungsspannung unternehmen. Denn wenn keine Spannung da ist, läuft die Software nun mal nicht (mehr). Deshalb gibt es zur Lösung solcher Probleme eine Pufferung über eine alternative Spannungsversorgung. Sei es eine Batterie, oder ein entsprechend groß dimensionierter Kondensator, ... Dann fährt man das System eben sauber herunter, wenn ein Spannungsausfall detektiert wurde, und gut ist.
Mark B. schrieb: > Deshalb gibt es zur Lösung solcher Probleme eine Pufferung über eine > alternative Spannungsversorgung. Sei es eine Batterie, oder ein > entsprechend groß dimensionierter Kondensator, ... > Dann fährt man das System eben sauber herunter, wenn ein > Spannungsausfall detektiert wurde, und gut ist. So hatte ich Lothar verstanden: solange kein Signal "Powerfail" anliegt, ist das Schreiben der Karte problemfrei bzw. die Versorgung ausreichend gepuffert (vermutlich mit Vorgabe der maximalen Pufferzeit). Verabsäumt man aber dessen Abfrage, dann wird das Schreiben zur Glückssache und das ist hier offenbar prompt schief gegangen. Es ist also durchaus eine Sache der Software.
A. S. schrieb: > Konkrete Objekte werden dann meist alibi-mäßig genauso gehandhabt ("ich > leite alle 4 Räder von der Klasse Rad ab! und instanziiere sie dann." > Super, hier ein Lutscher). Das ist quatsch. Es gibt genau 4 Räder am > Auto, und alle 4 haben spezifische Eigenschaften und es macht überhaupt > keinen Sinn, ein 5tes zu instanziieren oder nur 3. Kein DSP kommt damit > klar, wenn man ein Rad weglässt oder 2 tauscht. Globale Objekte spiegeln > hier nur die Aufgabe wieder und sind nicht böse. Wie weit das ignoriert > wird, zeigt sich, wenn Autosar (wo Milliarden hinterstehen) als Gebastel > angesehen wird, weil es den EDV-Mantras nicht folgt. Schon recht. Es gibt freilich auch Fälle beim Automobil, wo es sinnvoll sein kann wenn man mehr oder weniger Objekte instanziieren kann. Zum Beispiel haben manche Autos vorne und hinten elektrische Fensterheber, manche nur vorne und hinten nicht, manche gar keine. Auch manche Ausstaatungsverianten kann man vielleicht sinnvoll mit OOP abbilden. Wenn das entsprechende System verbaut ist, wird eben instanziiert, wenn nicht dann eben nicht. Aber klar: Man muss nicht alles mit OOP machen. Und auch wenn man in C++ etc. prgrammiert, kann es durchaus globale Objekte geben. Wenn diese sinnvoll mit der Realität übereinstimmen, wie bei dem Beispiel mit den genau 4 Rädern, dann ist das doch okay so.
Chris D. schrieb: > So hatte ich Lothar verstanden: solange kein Signal "Powerfail" anliegt, > ist das Schreiben der Karte problemfrei bzw. die Versorgung ausreichend > gepuffert (vermutlich mit Vorgabe der maximalen Pufferzeit). > > Verabsäumt man aber dessen Abfrage, dann wird das Schreiben zur > Glückssache und das ist hier offenbar prompt schief gegangen. > > Es ist also durchaus eine Sache der Software. Die alternative Spannungsversorgung sollte natürlich noch so lange funktionieren, dass man sauber protokollieren kann was geschehen ist. Sonst weiß man ja hinterher gar nicht, warum das System ausgefallen ist. Viel Spaß dann bei der Fehlersuche! ;-) Wenn man also den Log-Vorgang nicht mehr sinnvoll abschließen kann, weil einem vorher schon der Saft ausgeht, dann ist das zumindest nicht alleine ein Problem der Software.
:
Bearbeitet durch User
Mark B. schrieb: > Im Grunde genommen hat er ja auch Recht: Keine Software der Welt kann > etwas gegen einen plötzlichen Ausfall der Versorgungsspannung unternehmen. Lies mal, was ich geschrieben habe: natürlich ist ein Powerfail-Signal da. Man muss es verwenden. Es ging mir eher darum, dass es dem Softwerker überhaupt nicht bewusst war, dass es da überhaupt ein Problem geben könnte. > ein entsprechend groß dimensionierter Kondensator Dass wir angesichts der knappen Stützzeit dieser Komponente vorher in der Spec festgehalten hatten, dass keine Schreibzugriffe auf die SD-Karte erfolgen dürfen, ist dabei nur ein kleiner Nebenschauplatz. Es ergab sich eben "mit der Zeit", dass die Logdaten gespeichert werden müssen. Mal sehen, wie ich aus der Nummer wieder rauskomme...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Mark B. schrieb: >> Im Grunde genommen hat er ja auch Recht: Keine Software der Welt kann >> etwas gegen einen plötzlichen Ausfall der Versorgungsspannung unternehmen. > Lies mal, was ich geschrieben habe: natürlich ist ein Powerfail-Signal > da. Man muss es verwenden. Es ging mir eher darum, dass es dem > Softwerker überhaupt nicht bewusst war, dass es da überhaupt ein > Problem geben könnte. > >> ein entsprechend groß dimensionierter Kondensator > Dass wir angesichts der knappen Stützzeit vorher in der Spec > festgehalten hatten, dass keine Schreibzugriffe auf die SD-Karte > erfolgen dürfen, ist dabei nur ein kleiner Nebenschauplatz. Es ergab > sich eben "mit der Zeit", dass die Logdaten gespeichert werden müssen. > > Mal sehen, wie ich aus der Nummer wieder rauskomme... Nun ja, ohne vernünftiges Mitloggen der Fehlermeldungen stelle ich mir die Fehlersuche eher schwierig vor. Aber ich kenne das System und die Anforderungen an dieses nicht. Nur wenn man nicht mehr loggen kann, obwohl es gerade äußerst sinnvoll wäre dies zu tun, dann ist das zumindest sagen wir suboptimal :-)
Lothar schrieb: > Ing schrieb: >> nahmhaften Unternehmen dieser Branche komplexe (Hochsprachen-)Software > > Also im Maschinenbau wären das in dieser Reihenfolge VB .net und VB 6 / > RealBasic / Xojo und neuerdings PyQt Im Maschbau wird echt VB häufig eingesetzt, oder ist das ein Scherz ? Für was, die Leitrechner ?
motzkopp schrieb: > Im Maschbau wird echt VB häufig eingesetzt, oder ist das ein Scherz ? > Für was, die Leitrechner ? Heute wohl nicht mehr, aber es war recht verbreitet, die Visualisierungen in VB zu machen. Oder halt alles, wo irgend ein Benutzer mit dem PC interagiert. MFC und Windows API waren damals nicht wirklich intuitiv, Delphi gut aber exotisch (Pascal), QT und DotNet gabs noch nicht. Java auf Windows auch irgendwie Stiefmütterlich. Mit DotNet haben dann viele von denen, die in C eh µC gemacht haben, auf C# umgestellt, weil es ja C so ähnlich ist ;-)
A. S. schrieb: > Mit DotNet haben dann viele von denen, > die in C eh µC gemacht haben, auf C# umgestellt, weil es ja C so ähnlich > ist ;-) Ist ja auch so. Im Vergleich zu VB oder MS Visual C++ ist C# eine wohltat.
:
Bearbeitet durch User
A. S. schrieb: > auf C# umgestellt, weil es ja C so ähnlich > ist ;-) C# soll wohl ähnlicher zu ObjectPascal/Delphi (somit also exotisch) sein als jegliches C/C++-Derivat. Nur die geschweiften Klammern und die unsägliche Prefix-Typen-Grammatik wurde beibehalten damit der Kulturschock abgemildert wird.
:
Bearbeitet durch User
Bernd K. schrieb: > C# soll wohl ähnlicher zu ObjectPascal/Delphi (somit also exotisch) sein > als jegliches C/C++-Derivat. C# hat praktisch nichts mit C, C++, Pascal zu tun. Wenn schon ist C# sehr ähnlich zu Java, da beides auf Bytecode und einer VM basiert. Wie jetzt die Klammern aussehen und wo die Typen stehen ist ein rein kosmetischer Aspekt und sonst ziemlich egal. Lothar M. schrieb: > Es > ergab sich eben "mit der Zeit", dass die Logdaten gespeichert werden > müssen. Ach, eine sich plötzlich ändernde Anforderung, die die Informatiker ausbaden müssen...
Programmierer schrieb: > da beides auf Bytecode und einer VM basiert Das ist für die Sprache irrelevant, das ist nur ein Implementierungsdetail des zufällig gerade verwendeten Compilers.
Bernd K. schrieb: > Das ist für die Sprache irrelevant, das ist nur ein > Implementierungsdetail des zufällig gerade verwendeten Compilers. Zum einen das und auf der Zielmaschine kann man dann immer noch ngen drüber laufen lassen.
Bernd K. schrieb: > Das ist für die Sprache irrelevant, das ist nur ein > Implementierungsdetail des zufällig gerade verwendeten Compilers. Gut zu wissen, dann schreibe ich meine AVR Programme demnächst in C#, weil ich dessen Syntax schöner finde als die von C.
Dann will ich hier auch mal den Klugscheisser geben: C# ist sehr sehr ähnlich zu Java, da hat Microsoft abgeschaut, was beide auszeichnet ist die Garbage Collection, man braucht sich um den Speicher nicht zu kümmern. Anders als bei Delphi, C++, C. Die haben gemeinsam, dass es Pointer gibt, das kennt ein Java oder c# Entwickler nicht. Und C ist die einzige nicht OOP Sprache von allen.
Ing schrieb: > hatte ich bisher einfach nur Pech mit den Firmen oder ist das > "branchenüblich"? Nein, so ein Chaos ist branchenüblich und stammt aus vielen Dingen wie Unwissenheit, Knappheit an Ressourcen, Budget, wie auch fehlendes QM, kein seriöses Requirement Engineering oder Tools u.v.m. Auch in anderen traditionellen aber auch modernen Branchen üblich: man ist sich immer noch gewöhnt, in Projekten mit Office, x Wordversionen, xy Excelversionen und hunderte Mails zu arbeiten, vor allem verstaubte Projektleiter. Grüsse klausi
klausi schrieb: > stammt aus vielen Dingen wie > Unwissenheit, Knappheit an Ressourcen, Budget, wie auch fehlendes QM, > kein seriöses Requirement Engineering oder Tools u.v.m. Gibt es sich alles. Ist in Summe aber nicht stichhaltig. Gerade Budget ist im Maschinenbau da, QM wurde quasi dort erfunden, und das deutscher Maschinenbau keine Anforderungen kennt bzw. Kundenwünsche erfüllt, ist auch nicht wirklich offensichtlich. Vielleicht ist es doch so, dass sich offensichtlich falsche Methoden dann doch als das herausgestellt haben, was sie sind: falsch. Ja, wenn die Schreiner Doors verwenden würden, ihre Zollstöcke regelmäßig kalibrieren und jeden Woche einen Tage am internen Qualitätszirkel teilnehmen würden, dann würden sich die vielen Fehler (vermessene Türen, falsche Maserung) sicher reduzieren. Oder welche Fortschritte würde die Physik machen, wenn sie sich endlich wie die Mathematik rein auf Berechnungen stützt, anstatt an all diesen fehlerbehafteten Messungen festzuhalten,.
Motzkopp schrieb: > Dann will ich hier auch mal den Klugscheisser geben: > C# ist sehr sehr ähnlich zu Java, da hat Microsoft abgeschaut, was beide > auszeichnet ist die Garbage Collection, man braucht sich um den Speicher > nicht zu kümmern. https://en.wikipedia.org/wiki/C_Sharp_(programming_language) Zitat: C# was designed by Anders Hejlsberg, ... James Gosling, who created the Java programming language in 1994, and Bill Joy, a co-founder of Sun Microsystems, the originator of Java, called C# an "imitation" of Java; Gosling further said that "[C# is] sort of Java with reliability, productivity and security deleted." Klaus Kreft and Angelika Langer (authors of a C++ streams book) stated in a blog post that "Java and C# are almost identical programming languages. Boring repetition that lacks innovation," "Hardly anybody will claim that Java or C# are revolutionary programming languages that changed the way we write programs," and "C# borrowed a lot from Java - and vice versa. Now that C# supports boxing and unboxing, we'll have a very similar feature in Java." In July 2000, Hejlsberg said that C# is "not a Java clone" and is "much closer to C++" in its design. https://en.wikipedia.org/wiki/Anders_Hejlsberg Zitat: He was the original author of Turbo Pascal and the chief architect of Delphi. He currently works for Microsoft as the lead architect of C# and core developer on TypeScript. > Anders als bei Delphi, C++, C. Die haben gemeinsam, dass es Pointer > gibt, das kennt ein Java oder c# Entwickler nicht. Na na na: https://www.c-sharpcorner.com/article/pointers-in-C-Sharp/ merciless
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.