Hallo Zusammen, ich möchte diesen Beitrag mal starten um zu erfahren wie man große Software/Firmwareprojekte (größer 100.000 Codezeilen) an andere Kollegen weitergibt, bzw. diese bereits während der Erstellung der Software mit einbezieht. Hintergrund hier ist einen zweiten Entwickler zu haben, der bei Bedarf ohne große schwierigkeiten sofort am Code des anderen weiterarbeiten kann. - Wie machen das andere Leute / Firmen? - Wöchentliche Meetings bei dem man sich zusammensetzt und den Code bespricht? - Eine sehr große Dokumentation bei der alles bis ins kleinste Detail beschrieben ist? - ...?
Das wichtigste ist "lesbarer" bzw. "navigierbarer" Code. Läuft eine Funktion in ein Assert oder einen unerwarteten Rückgabewert, dann sollte er dieses Detail im Code auch separat erforschen können. Von da kann er mit wenigen Dokumenten die Struktur erforschen. Ein Lehrbuch für C++ oder Stricken beginnt auch bei einfachen Dingen und wird immer komplexer. Dokumentation ist nur hilfreich, wenn mehr Zeit ins Lesen fließt als ins schreiben. Zentrale Konzepte, globale Strategien, Schnittstellen-Beschreibungen, gegen die ein anderer Programmiert, Super. 10 Seiten Prosa, die der Entwickler runterschreibt und die niemand liest, sind hingegen oft wertlos für den Nächsten. Sie helfen eher dem Schreiber. Stell Dir einen Supermarkt vor: Du brauchst vorab komplexe Konzepte und Strategien, da steckt sehr viel (uns unbekanntes) Know How drin. Der Neue Kollege kann sich den Supermarkt aber am Besten erstmal anhand der Ordnung der Produkte erschließen und sich von da in die Struktur einarbeiten.
Flo schrieb: > Wie machen das andere Leute / Firmen? Wenn man sich von der Vorstellung löst, dass ein Programmierer für ein Projekt zuständig ist, geht das einfach. Die Team Mitglieder programmieren wechselweise teile der Software, ein anderer Kontrolliert das (Testen, Code-Review, Doku prüfen). So hast du automatisch für jeden Teilbereich immer mindestens zwei Leute, die sich damit einigermaßen auskennen.
Oder anders gesagt: wenn du der einzige Entwickler für das einzige Stück Software im Unternehmen bist, habt ihr noch ganz andere Probleme. Oliver
Eine kurze Dokumentation, die AKTUELL gehalten wird, wäre nützlich für den Einstieg. Wichtig wäre für mich, wie man mögliche Fehler frühzeitig erkennt und behandelt. Manches Programm prüft sich deshalb selbst. Dokumentation sollte so sein, dass man in >20 Jahren noch etwas damit anfangen kann. Thema Voyager https://www.pcwelt.de/article/2114489/voyager-sonden-software-update.html
Dokumentation ist wichtig. Zu viel ist aber kontraproduktiv, weil - das keiner lesen will - das keiner pflegen will - man es bei Geld-/Zeitmangel vernachlässigt Wo ich gerade arbeite hat sich folgendes bewährt: Der technische Projektleiter, der auch mit dem Auftraggeber verhandelt, sammelt die Anforderungen vom Kunden irgendwo für sich. Er zerlegt das in viele kleine Aufgaben (Tickets), die von den Programmierern und Testern abgearbeitet werden. Änderungen der Anforderungen werden in den Tickets dokumentiert. Die Programmierer beschreiben alle Funktionen aus ihrer Sicht und für sich selbst bzw. ihr Team. Dazu gehören auch knapp formulierte Anleitungen zum Build-Pozess, Installation, Konfiguration und Erstellung der Lieferungen. Ein simples Wiki eignet sich dazu ganz gut. Die größte Herausforderung dabei ist, eine Form zu finden, die allen zusagt. Beispiel:
1 | Function sendNotificationMailAfterStatusChange() |
2 | |
3 | This function is called whenever the status of a customer has been changed. |
4 | |
5 | * Find a usable email address in this order |
6 | * First choice is the email address of the customer, if set |
7 | * otherwise use the email address of default contact partner of the customer |
8 | * otherwise use the email address of the administrator of the customer |
9 | * otherwise use the email address of any contact person of the customer who has an email address set |
10 | * otherwise abort with error ... |
11 | * Load the email template from DB table ... where name is notifMail_<oldStatus>_<newStatus> |
12 | * if there is no such template, then abort with error ... |
13 | * Call the sendMail() function (link) with the following arguments |
14 | * ... |
15 | * Return 0 (success) |
Man sollte nur die Funktionen dokumentieren, die für die Geschäftslogik relevant sind. Wie genau auf die DB Zugegriffen wird, ist eher uninteressant und sollte eh nach einem Standard Pattern ablaufen, dass die ganze Anwendung durchzieht. Nur bei besonderen Abweichungen muss man das detaillierter erklären. Eventuell gibt es eine separate Doku wo die Standard Patterns erfasst sind. Projektleiter nutzen diese Doku wiederum als Basis, um künftige Änderungen zu planen und Fragen zu klären (warum passiert hier dies und nicht das?). Auch die Manuals für die Kunden basieren darauf.
:
Bearbeitet durch User
Flo schrieb: > Wie machen das andere Leute / Firmen? Keep it simple, nicht den allerneuesten C++23 Quatsch einbauen, lieber einfachere Strukturen in common knowledge. Dokumentiere die Schnittstellen exakt, je nach dem wo Schnittstellen sind, Libraries, Klassen, Programme etc. mit Aufrufbeispielen. Auch externe Anforderungen klar formuliert mit abheften. Baue automatisierte Tests, damit jeder Fehler den er einbaut gleich auffällt, baue sie auf eine Art die auch von anderen leichtverständlich zu erweitern ist. Nein, dokumentiere nicht jede Codezeile, bespreche nichts was man wegen der schieren Menge wieder vergisst weil es in dem Moment unwichtig ist.
Softwareentwicklung ist immer noch Kunsthandwerk. In allen anderen Bereichen hat sich das von James Watt entwickelte Konzept durchgesetzt. In seinem System lassen sich die Ingenieure beliebig austauschen. Bis 2000 rum war die Vorgehensweise zur Softwareentwicklung durchaus sinnvoll. Die Hardware was viel zu teuer. Du brauchtest geniale Kunsthandwerker, die auf der viel zu schlappen Hardware ein nützliches Programm zustande brachten. Heutzutage hast du ein Henne-Ei-Problem. Würden alle Firmen die Softwareentwicklung nach Watts Konzept organisieren, könntest du die Entwickler beliebig austauschen. Aber für das alte Kunsthandwerk gibt es nicht genug Entwickler. Du bekommst nur fähige Entwickler, wenn du dich auf deren Forderungen einlässt.
Xanthippos schrieb: > Bis 2000 rum war die Vorgehensweise zur Softwareentwicklung durchaus > sinnvoll. Die Hardware was viel zu teuer. Du brauchtest geniale > Kunsthandwerker, die auf der viel zu schlappen Hardware ein nützliches > Programm zustande brachten. Myth. Schon 1968 hinkte die SW hinterher. https://de.wikipedia.org/wiki/Softwarekrise (Man denkt immer, dass davor nur Nerds vor sich hin programmierten. Seit den 50ern arbeiten Teams mit tausenden Programmierern an einer SW.)
:
Bearbeitet durch User
> Seit den 50ern arbeiten Teams mit tausenden Programmierern an einer SW.
"Die Seele einer neuen Maschine" oder folklore.org . Das wurde von ein
paar Genies entwickelt, nicht vom Fußvolk. Auch Fred Brooks musste
zugeben, ein exzellenter Entwickler bringt 10 mal so viel zustande, wie
ein guter Entwickler.
Ingenieure wie Gustave Eiffel oder Rudolf Diesel gibt es heutzutage
nicht mehr. Aber es gibt immer noch Softwareentwickler wie Linus
Torvalds.
Das Problem wurde schon 68 erkannt, aber immer noch nicht gelöst. Einen
Linus Torvalds kannst du immer noch nicht ersetzen.
Was mir sehr hilft ist keine Dokumentation bis ins kleinste Detail sondern: -> Erstmal verstehen, was das Produkt überhaupt macht!? -> Was bietet das Produkt einem Anwender? -> Welche Schnittstellen gibt es zum Anwender? -> Kann der Anwender das System parametrieren bzw. Daten abfragen? -> Wie hängen die Schnittstellen und andere Systemkomponenten zusammen? Die Punkte im Hinterkopf würde mir das Einarbeiten in eine Firmware vereinfachen.
Xanthippos schrieb: > Das wurde von ein paar Genies entwickelt, nicht vom Fußvolk. Schon klar, dass da nicht 1000 Entwickler ein SCRUM-Team bilden. > Auch Fred Brooks musste zugeben, ein exzellenter Entwickler bringt > 10 mal so viel zustande, wie ein guter Entwickler. Dann weißt Du auch, warum die Performance eines Garagenstartup nicht skaliert. > Einen Linus Torvalds kannst du immer noch nicht ersetzen. Unglückliches Beispiel: Eher Allen/Gates oder Wozniak, die sich nicht in ein gemachtes Nest gesetzt haben. Aber klar: In jeder Branche gibt es führende Talente. Auch einen Neuer kannst Du nicht ersetzen. Oder mit Turek, Maier oder Illgner vergleichen. So what. Hier geht es um eine (vermutlich ältere) SW, die von einem Maintained wird und wo ein zweiter dazu kommt. Das war vor 50 Jahren vermutlich die gleiche Herausforderung wie heute.
In der Softwareentwicklung haben wir immer wieder komplett neu angefangen. Immer wieder das selbe. Die Neuen verstanden die Altlasten nicht, wollten sie auch nicht verstehen und fingen mit neuen Ideen wieder von vorne neu an. Als die Entwickler der Großrechner in Rente gingen, kamen Apple II und IBM PC auf. Das Visicalc konnte ein einzelner Kunsthandwerker entwickeln. Novell Fileserver entwickelten auch ein paar einzelne Künstler. Als die PC Netze zu komplex wurden, fingen wir mit den TCP/IP Standards neu an. Als Firmenintranet zu komplex wurde, versuchten wir es mit Cloud Services und Smartphone Apps. Jeder gute Softwareentwickler kann dem Chef sagen "Den alten Schrott übernehme ich nicht, wenn ich das nicht neu machen kann, suche ich mir einen anderen Job." Vergleich das mal mit Automobilbau, Maschinenbau, Bauwesen... Stell dir vor, ein Statiker sagt den Chef "Verstehe ich nicht, will ich nicht verstehen. Ich will das Haus abreißen und ganz anders neu bauen".
Xanthippos schrieb: > Jeder gute Softwareentwickler kann dem Chef sagen "Den alten Schrott > übernehme ich nicht, wenn ich das nicht neu machen kann, suche ich mir > einen anderen Job." Es ist ja nicht der alte Code allein. Oftmals gibt es auch keine vernünftig dokumentierten Anforderungen dazu, keine sauber definierte Architektur, keine Design-Dokumente, und die Schnittstellen zwischen den Software-Modulen sind auch nirgends richtig beschrieben. Dementsprechend schwer ist es, sich überhaupt einigermaßen zurechtzufinden. Qualitativ schlechten Code sollte man tatsächlich besser wegwerfen als beibehalten.
:
Bearbeitet durch User
Es geht doch gar nicht um den Code. Code ist trivial, kann man bald durch KI erzeugen lassen. Es geht um Loesungen. Die werden nicht per - Schnipp - hingeworfen. Und vor Jahrzehnten war nicht die Hardware zu teuer und konnte nichts. Die Probleme waren anders. Wenn das Problem der Welt darin besteht mit einem Transistor einen Ballon aufzublasen benoetigt man eben Jemanden der den Transistor und Ballon versteht, und die Beiden zusammenhaengen kann. Ob das jetzt 10'000 Mark kostet ist egal. Das Problem ist nachher geloest, alle sind happy und applaudieren. Der Konstrukteur wird vom/mit dem Buergermeister praesentiert und bekommt eine Auszeichnung. Heutzutage wird millionenfach dupliziert, man kassiert millionenfach, der Buergermeister wird nicht mehr benoetigt. Den Konstrukteur benoetigt man trotzdem.
:
Bearbeitet durch User
Mark B. schrieb: > Es ist ja nicht der alte Code allein. Oftmals gibt es auch keine > vernünftig dokumentierten Anforderungen dazu, keine sauber definierte > Architektur, keine Design-Dokumente, und die Schnittstellen zwischen den > Software-Modulen sind auch nirgends richtig beschrieben. Dementsprechend > schwer ist es, sich überhaupt einigermaßen zurechtzufinden. Genauso sieht es aus. Habe ich auch so erlebt. Es ist schlicht grausam und völlig demotivierend, auch für neue Mitarbeiter. Mark B. schrieb: > Qualitativ schlechten Code sollte man tatsächlich besser wegwerfen als > beibehalten. Volle Zustimmung.
:
Bearbeitet durch User
Moin, 900ss schrieb: > Mark B. schrieb: >> Qualitativ schlechten Code sollte man tatsächlich besser wegwerfen als >> beibehalten. > > Volle Zustimmung. Ach. Arm dran ist besser als Arm ab. Nur dummerweise sollte man den qualitativ schlechten Code erst dann wegwerfen, wenn man: a.) einen anderen Code hat, der compiliert. b.) belastbar sichergestellt hat, dass der auch wirklich "qualitativ besser" ist. und nicht schon vorher, denn sonst guckt die Fertigung etwas schmal. Gruss WK
Flo schrieb: > Hallo Zusammen, > > ich möchte diesen Beitrag mal starten um zu erfahren wie man große > Software/Firmwareprojekte (größer 100.000 Codezeilen) an andere Kollegen > weitergibt, Üblicherweise genau dann, wenn es brennt. Und dann mit einem Sprung ins kalte Wasser. > bzw. diese bereits während der Erstellung der Software mit > einbezieht. In der idealen Welt arbeiten natürlich mehrere Personen am gleichen Projekt. Zwar in anderen Bereichen, aber wenn Not am Mann ist, übernimmt das einer von ihnen. Einfach, weil sie in die Sturktur schon eingearbeitet sind. > Hintergrund hier ist einen zweiten Entwickler zu haben, der bei Bedarf > ohne große schwierigkeiten sofort am Code des anderen weiterarbeiten > kann. Das ist eine Wunschvorstellung. Rational: Der Code ist gut dokumentiert, die Entwickler haben auf "findige Tricks zur Optimierung des letzten Quäntchen verzichtet" und lesbaren Code erzeugt, es gibt einheitliche Funktionsprototypen, es wird nicht in jeder Funktion mit einem anderen Datentyp gearbeitet, es gibt funktionale Diagramme, die auf Metaebene den Codeauflauf beschreiben. Real: Irgendein Entwickler hat mal angefangen, ein Anderer hat es übernommen, ist aber in seinem Sabbat-Jahr, ein weiterer hat hier und da was hinzugefügt, es gibt eigentlich keinen, der jede Ecke des Programms kennt, Dokumentation ist eher so mähbäh und Kommentare fressen unbändig viel Speicherplatz auf dem Controller und wurden deshalb gleich ganz weggelassen. Die ganze Software tut zwar was sie soll, ist aber so behäbig wie die Volkswagen-Behörde und so durchsichtig, wie das Steuersparmodell eines Milliardärs. > - Wie machen das andere Leute / Firmen? Dokumentation kostet Geld und bringt keinen Profit. Und da goldgepresstes Latinum wichtiger ist, als alles andere auf dieser Welt, sehen wir uns eher mit Fall 2 konfrontiert. Je größer die Firma, umso eher wird Wert auf Wartbarkeit und Dokumentation gelegt und wenn die Firma ganz groß ist, dann dokumentiert man mehr, als dass man entwickelt. Irgendwo dazwischen liegt der Median. > - Wöchentliche Meetings bei dem man sich zusammensetzt und den Code > bespricht? Da halte ich wenig von. Einfach, weil man vom bloßen Erklärt bekommen wenig lernt. Man hat dann vielleicht im Hinterkopf, dass man xyz irgendwo irgendwann schonmal gesehen hat, aber das reicht eigentlich nicht, um dann auch selbst Veränderungen durchführen zu können. > - Eine sehr große Dokumentation bei der alles bis ins kleinste Detail > beschrieben ist? > - ...? Es gibt so einen tollen Spruch: Es wird auf dieser Welt nicht zu wenig geschrieben, es wird zu wenig gelesen. Eine überkandidelte Dokumentation ist ein Totschläger. Niemand, der nur die Anzahl an Seiten sieht, hat wirklich Lust, sich das anzusehen. Eine API-Dokumentation mag sinnvoll sein (falls relevant), eine Funktionsübersicht mit einem bis zwei Sätzen, die die Funktion erklären. Mehr braucht es aber auch nicht, weil man als Entwickler eigentlich schnell lernt, seinen Fokus auf's Wesentliche zu richten. Zu viel Bla Bla lenkt einfach nur ab. Und, wie oben schon erwähnt, gewisse Ablaufdiagramme (z.B. von komplexen Algorithmen). Ich habe mit vielen Entwicklern zu tun gehabt. Es gibt ganz wenige herausragende, die binnen Sekunden den Kern erfassen können. Die allermeisten schlürfen behäbig ins Thema, schauen sich den Code an, verstehen das Grundprinzip, aber nicht, warum hier z.B. eine Betragsfunktion verwendet wird, bevor der Wert weiterverarbeitet wird. Ich denke bei einem derart komplexen Programm ist die einzige Chance eine echte Vertretung zu haben, wenn diese auch aktiv beteiligt ist.
Es nützt eine akademisch tolle Lösung wenig, wenn sie in der Praxis versagt. Es gibt gute Programmierer und gute Praktiker. Sie sollten die Anforderungen der Anderen kennen, wenn es eine gute Lösung werden soll!
900ss schrieb: > Mark B. schrieb: >> Qualitativ schlechten Code sollte man tatsächlich besser wegwerfen als >> beibehalten. > > Volle Zustimmung Na ja, qualitativ schlecht nach wessen Massstab, deinem ? Humbug. Qualitativ schlecht ist code, wenn er nicht (auch im Fehlerfall) funktioniert, wenn er langsam ist oder viele Ressourcen verbraucht. Das sind Massstäbe, Metriken. Nicht deine Verblendung 'alle doof ausser ich'. Daher kommt auch 'never change a running system'. Übrigens zeigt ein Blick in den Code von CP/M, Windows 1-3.11, GEM, dass Software die kommerziell erfolgreich war auch gut geschrieben war. Mit Win32 (David Cutler) ging es signifikant bergab.
Michael B. schrieb: > Na ja, qualitativ schlecht nach wessen Massstab, deinem ? Ich habe nur eine Äußerung bestätigt, wo ich meine das sie stimmt. Und es ist erstmal ganz allgemein die Qualität gemeint, nach welchen Kriterien/Massstäben die festgelegt wird, ist nicht diskutiert worden. Ich habe keine genannt. Weshalb dichtest du das jetzt dazu und unterstellst mir etwas? Michael B. schrieb: > Nicht deine Verblendung 'alle doof ausser ich'. Ich weiß ja wo es herkommt. Dein Nick ist halt Programm. Und leider auch häufiges pöbeln, so wie jetzt auch. Es ist schade, da es Ausreißer gibt mit Beiträgen von dir, die tatsächlich sehr gut sind.
900ss schrieb: > da es Ausreißer gibt mit Beiträgen von dir, die tatsächlich sehr gut > sind. Deine Bewertung ist einfach: stimmt er mir zu, ist sein Beitrag gut, äussert er Kritik, ist sein Beitrag schlecht. Auf die Art kommst du halt nie zur Wahrheit.
Martin S. schrieb: > Flo schrieb: >> Hallo Zusammen, >> >> ich möchte diesen Beitrag mal starten um zu erfahren wie man große >> Software/Firmwareprojekte (größer 100.000 Codezeilen) an andere Kollegen >> weitergibt, > > Üblicherweise genau dann, wenn es brennt. Und dann mit einem Sprung ins > kalte Wasser. Danke. Wenigstens ein Realist. Oliver
Michael B. schrieb: > stimmt er mir zu, ist sein Beitrag gut, äussert er Kritik, ist sein > Beitrag schlecht. Falsch. Wenn die Kritik sachlich und nicht persönlich werdend ist, dann ist der Beitrag schon mal lesenswert. Leider ist das bei dir oft nicht der Fall. Stänkern und pöbeln liegt einigen Leuten leider eher.
:
Bearbeitet durch User
Ich lerne niemandem mehr ein: Zeitverschwendung. Ich habe schon oft irgendwelchen Neuzugängen was gezeigt. Entweder die Person ist dann nach ein paar Wochen weg oder in einer anderen Abteilung. Alle guten Leute die da sind, brauchten das nie. Von diesem "Einlernen" profitieren am Ende nur die Schwurbler. Die dann Wissen abgreifen und damit hausieren gehen. Was habe ICH davon? Nichts. Sollen sich selbst kümmern.
:
Bearbeitet durch User
900ss schrieb: > Wenn die Kritik sachlich und nicht persönlich werdend ist, dann ist der > Beitrag schon mal lesenswert. Dann lies mal deine Beiträge mit ihren persönlichen Beleidigungen.
Cyblord -. schrieb: > Von diesem "Einlernen" > profitieren am Ende nur die Schwurbler. Die dann Wissen abgreifen und > damit hausieren gehen. Was habe ICH davon? Nichts. Sollen sich selbst > kümmern. Sehe ich auch so. Das einzige, was ich tue und verlange ist ein kompletter turnaround-Zyklus: Installieren der Tools, Auschecken, ein Bit ändern, Builden, Ablegen, einspielen/nutzen/ablegen. Meist bleibt ein Haken oder Schritt vergessen. Wenn das perfekt beschrieben ist, super --> 0 Arbeit für den alten. Wenn es hakelt, bringt der alte das mit dem neuen zum fliegen, der neue aktualisiert ggf. die Doku. Mir reicht es, wenn der neue es danach alleine kann.
Cyblord -. schrieb: > Ich lerne niemandem mehr ein: Zeitverschwendung. Ich habe schon oft > irgendwelchen Neuzugängen was gezeigt. Entweder die Person ist dann nach > ein paar Wochen weg oder in einer anderen Abteilung. > Alle guten Leute die da sind, brauchten das nie. Von diesem "Einlernen" > profitieren am Ende nur die Schwurbler. Die dann Wissen abgreifen und > damit hausieren gehen. Was habe ICH davon? Nichts. Sollen sich selbst > kümmern. Vermutlich hauen sie deshalb auch gleich wieder ab bei solchen tollen Kollegen, da fühlt man sich gleich sauwohl - aber woanders.
Xanthippos schrieb: > Jeder gute Softwareentwickler kann dem Chef sagen "Den alten Schrott > übernehme ich nicht" Ich halte mich für einen guten Softwareentwickler, weil ich genau das nicht mache. Neuentwicklungen gibt der Chef mir nicht mehr so gerne, weil ich dabei zu schnell bin (sagt er). Er braucht für mich immer drei Leute für Code-Review und Test, die dann Monatelang zu nichts anderes mehr kommen weil ich sie zu ballere. Sich in Altlasten rein zu fuchsen dauert länger, die meisten Kollegen können das gar nicht. Manchmal fühle ich mich, als hätte ich damit die Arschkarte gezogen. Andererseits klappt es ganz gut und ich denke, dass man so für die Firma auch wichtiger wird.
:
Bearbeitet durch User
Franko S. schrieb: > Cyblord -. schrieb: >> Ich lerne niemandem mehr ein: Zeitverschwendung. Ich habe schon oft >> irgendwelchen Neuzugängen was gezeigt. Entweder die Person ist dann nach >> ein paar Wochen weg oder in einer anderen Abteilung. >> Alle guten Leute die da sind, brauchten das nie. Von diesem "Einlernen" >> profitieren am Ende nur die Schwurbler. Die dann Wissen abgreifen und >> damit hausieren gehen. Was habe ICH davon? Nichts. Sollen sich selbst >> kümmern. > > Vermutlich hauen sie deshalb auch gleich wieder ab bei solchen tollen > Kollegen, da fühlt man sich gleich sauwohl - aber woanders. Das hat mit "tollen" Kollegen nichts zu tun. Das ist einfach die Konsequenz aus der Erfahrung, die ich auch gemacht habe. Wir haben hier in den letzten 6 Jahren inzwischen den 4ten Neuzugang. Einer ist noch da. Die anderen sind, oder wurden gegangen. Jedes Einlernen frisst mindestesn zwei Wochen Arbeitszeit. Zwei Wochen, in denen man selbst kaum produktiv ist, sich aber rechtfertigen muss, warum das eigene Zeug nicht fertig wird. Wenn das Einlernen fruchtet: Geschenkt. Aber meiner Erfahrung nach ist das Perlen vor die Säue, weshalb ich das auch nicht mehr mache, sondern ein Kollege. Irgendwann kommt der schon auch noch an den Punkt. Die Sache mit dem Einlernen ist ja die: Wir sind hier keine Schule. Wir erwarten, dass das Rüstzeug vorhanden ist. Sonst könnten wir einen Azubi nach der Lehre übernehmen und bei Adam und Eva mit ihm anfangen. Was wir beibringen sollen und müssen sind betriebliche Abläufe, Toolchains, Organisationsstruktur. Der Rest muss von der Person selbst kommen. Einer von den oben genannten 4 Zugängen war sogar so schlecht, dass wir mittlerweile alles, was er in der Zeit bei uns gemacht hat (bevor er gegangen wurde) nochmal komplett neu gemacht werden musste. Jetzt ist er Projektleiter bei einem Unternehmen für Automatisierungstechnik. Naja, Aufschwätzen konnte er so richtig gut. Ich muss korrigieren: Es waren 5 Neuzugänge und einer davon haben wir tatsächlich als Geselle innerbetrieblich übernommen. Aber das war auch einer der seltenen Fällen von Azubis, die wirklich motiviert und gut in dem waren, was sie so als Azubi-Aufgaben bekommen haben.
:
Bearbeitet durch User
Michael B. schrieb: > Dann lies mal deine Beiträge mit ihren persönlichen Beleidigungen. Wenn ich welche finde mache ich das gerne :)
:
Bearbeitet durch User
Lu O. schrieb: > Es nützt eine akademisch tolle Lösung wenig, wenn sie in der Praxis > versagt. Falls du mit "akademisch" das gleiche meinst wie ich: Meistens funktionieren diese Lösungen durchaus sehr gut. Es gibt aber zu viele Leute im Team, die sie nicht verstehen. Aus Unternehmerischer Sicht bleibt man flexibler und fährt billiger, wenn man auf besonders komplizierte Sachen so weit wie möglich verzichtet, damit möglichst viele Entwickler den Code möglichst rasch erfassen. Diese Überlegung hat bei Google zur Entwicklung einer eigenen Programmiersprache (Namens Go) geführt. Rein technisch ist sie vollkommen überflüssig. Sie kann nicht besser, als andere etablierte Sprachen. Aber sie kann weniger, vor allem weniger kompliziertes, was die "erfahrenen" Programmierer zur Einfachheit zwingt und dem Nachwuchs den Zugang erleichtert.
:
Bearbeitet durch User
Michael B. schrieb: > Übrigens zeigt ein Blick in den Code von CP/M, Windows 1-3.11, GEM, dass > Software die kommerziell erfolgreich war auch gut geschrieben war. Mit > Win32 (David Cutler) ging es signifikant bergab. Im Linux Quelltext soll es tausende Stellen mit schimpfenden Kommentaren gegeben haben. Wir machen das bei und in der Firma auch. So ein "WFT why do we not simply use a treemap here?" ist eine Ermunterung an die erfahrenen Programmierer, den ganzen Block bei Gelegenheit zu ersetzen, falls sie da durch blicken.
:
Bearbeitet durch User
Flo schrieb: > ich möchte diesen Beitrag mal starten um zu erfahren wie man große > Software/Firmwareprojekte (größer 100.000 Codezeilen) an andere Kollegen > weitergibt, bzw. diese bereits während der Erstellung der Software mit > einbezieht. Dafür verwende ich ClearCase: https://de.wikipedia.org/wiki/Rational_ClearCase Es gibt aber auch viele andere Versionsverwaltungen.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Im Linux Quelltext soll es tausende Stellen mit schimpfenden Kommentaren > gegeben haben OpenOffice schimpft zwar nicht, enthält (zumindest damals als ich mich damit beschäftigen musste) aber extrem viele Kommentare was noch nicht implementiert ist oder besser implementiert werden sollte. Sprich: wird 'verkauft' ist aber noch halbfertig.
Martin S. schrieb: > Wir haben hier in den letzten 6 Jahren inzwischen den 4ten Neuzugang. > Einer ist noch da. Die anderen sind, oder wurden gegangen. Jedes > Einlernen frisst mindestesn zwei Wochen Arbeitszeit. Zwei Wochen, in > denen man selbst kaum produktiv ist, sich aber rechtfertigen muss, warum > das eigene Zeug nicht fertig wird. Wenn das Einlernen fruchtet: > Geschenkt. Aber meiner Erfahrung nach ist das Perlen vor die Säue, > weshalb ich das auch nicht mehr mache, sondern ein Kollege. Irgendwann > kommt der schon auch noch an den Punkt. Und dann sind das nicht nur potentielle Kollegen sondern eben auch Schwurbler wie Vertriebler usw. denen man mal die Produkte erklären soll. Davon hat man selbst Null und gar Nichts. Nicht mal Kollegen die einem bei der Arbeit zur Hand gehen können.
> Einlernen frisst mindestesn zwei Wochen Arbeitszeit. Zwei Wochen, in > denen man selbst kaum produktiv ist, sich aber rechtfertigen muss, warum > das eigene Zeug nicht fertig wird. Also wenn das anlernen eines neuen Kollegen nur zwei Wochen dauert, dann scheint ihr erstaunlich unkomplexe Dinge zu machen. Und wenn ich mich gegen irgendjemanden dafuer rechtfertigen muesste das etwas 2Wochen spaeter fertig wird dann wuerde ich SOFORT nach einem anderen Job suchen. Vanye
Cyblord -. schrieb: > Und dann sind das nicht nur potentielle Kollegen sondern eben auch > Schwurbler wie Vertriebler usw. denen man mal die Produkte erklären > soll. Sei froh, wenn Du wissensdurstige Vertriebler hast, die geben auch mal Rückmeldung, was der Kunde braucht. Wenn der Vertrieb nicht funktioniert, hast Du bald keine Kunden mehr.
Vanye R. schrieb: > Also wenn das anlernen eines neuen Kollegen nur zwei Wochen dauert, > dann scheint ihr erstaunlich unkomplexe Dinge zu machen. Das dachte ich auch. Für zwei Wochen ( oder gar zwei Monate) würde ich mir nicht ins Hemd machen.
:
Bearbeitet durch User
Lu O. schrieb: > Sei froh, wenn Du wissensdurstige Vertriebler hast, die geben auch mal > Rückmeldung, was der Kunde braucht. Wenn der Vertrieb nicht > funktioniert, hast Du bald keine Kunden mehr. Realitätscheck: Der Vertrieb beklagt sich, die Entwicklung ignoriert ihn und der Produktmanger hat keinen Bock, etwas ändern zu lassen. Der Vertriebler wird umsatzabhängig bezahlt und verkauft den Kram trotzdem. Die Ignoranten behalten Oberhand, weil deren Stümperei ja trotzdem Umsatz bringt.
Steve van de Grens schrieb: > Neuentwicklungen gibt der Chef mir nicht mehr so gerne, weil ich dabei > zu schnell bin (sagt er). Er braucht für mich immer drei Leute für > Code-Review und Test, die dann Monatelang zu nichts anderes mehr kommen > weil ich sie zu ballere. Sorry, aber auf welcher Ebene ergibt das irgendeinen Sinn?
Martin S. schrieb: >> Wöchentliche Meetings bei dem man sich zusammensetzt und den Code >> bespricht? > > Da halte ich wenig von. Einfach, weil man vom bloßen Erklärt bekommen > wenig lernt. Man hat dann vielleicht im Hinterkopf, dass man xyz > irgendwo irgendwann schonmal gesehen hat, aber das reicht eigentlich > nicht, um dann auch selbst Veränderungen durchführen zu können Würde ich so unterschreiben. Hab das selbst hinter mir. Über Monate jede Woche (war nicht nur eine Software) Man wird mit viel scheiß beschissen, merken kann man es sich eh nicht alles und die Fragen tauchen erst auf wenn man selbst damit arbeitet. Klar macht es Sinn paar Dinge zu erklären, Grundlagen, ein Konzept (falls es sowas überhaupt gibt) oft gibt's das nicht, alles ist historisch gewachsen & was Was macht und wieso, weshalb warum weiß eh niemand mehr. mMn muss der neue in so einem Fall anfangen Aufgaben zu bekommen, sich mit dem Code vertraut machen und dann gezielt Fragen stellen. Oftmals sind es dann ja aber keine trivialen Aufgaben mehr, sondern Sachen bei denen selbst der alte Hase erstmal nachdenken muss. Und wenn es doll läuft ist der alte Hase eh schon weg in Rente. Dann darf der Leiter der Entwicklung dem PM erklären, warum jetzt erstmal Stillstand herrscht und sich nix mehr tut mit neuen Features :) Viele Firmen sind da so dermaßen schlecht aufgestellt und haben noch nie etwas von einem Bus-Faktor gehört. Wenn dann zusätzlich von dem/den alten Hasen etwas boshaftigkeit hinzukommt und sie bestimmten Kram soundurchsichtig geschrieben haben um sich ja unersetzbar zu machen... Tjaaa, dann sollte eigentlich derLeiter der Software dran sein, dass er sowas zugelassen hat... Aber das bleibt eh nurWunschdenken
Steve van de Grens schrieb: > Sich in Altlasten rein zu fuchsen dauert länger, die meisten Kollegen > können das gar nicht. Manchmal fühle ich mich, als hätte ich damit die > Arschkarte gezogen. Andererseits klappt es ganz gut und ich denke, dass > man so für die Firma auch wichtiger wird. Das haben sich diejenigen die das verbrochen haben bestimmt auch schon gedacht. Verklausulierten kack schreiben den niemand durchblickt um ja unersetzbar zu sein. Kann man den Firmen nur wünschen das sowas auffällt
Bruno V. schrieb: > Sorry, aber auf welcher Ebene ergibt das irgendeinen Sinn? Wenn einer programmiert und die anderem im Team nur noch testen, ist das schon schlecht, weil das ganze Produkt von einem einzigen Programmierer abhängt. Die Kollegen können sich danach nicht gut gegenseitig vertreten. Außerdem will wohl kein Programmierer lange Zeit nur testen. Man kann natürlich programmierte Änderungen so lange liegen lassen, bis alle Programmieraufträge fertig sind, und erst dann testen. Aber das diese Strategie nicht mehr Zeitgemäß ist, muss ich wohl niemandem hier erklären.
:
Bearbeitet durch User
Vanye R. schrieb: >> Einlernen frisst mindestesn zwei Wochen Arbeitszeit. Zwei > Wochen, in >> denen man selbst kaum produktiv ist, sich aber rechtfertigen muss, warum >> das eigene Zeug nicht fertig wird. > > Also wenn das anlernen eines neuen Kollegen nur zwei Wochen dauert, > dann scheint ihr erstaunlich unkomplexe Dinge zu machen. Und > wenn ich mich gegen irgendjemanden dafuer rechtfertigen muesste das > etwas 2Wochen spaeter fertig wird dann wuerde ich SOFORT > nach einem anderen Job suchen. > > Vanye Jetzt mal Hand aufs Herz, wenn man Erfahrungen in der Softwareentwicklung hat, sich schon in über ein dutzend Projekten eingearbeitet hat, dann sind zwei Wochen machbar. Nicht jedoch, wenn es total neue Technologien und oder Methoden sind. Was macht Erfahrungen aus? Und was macht Wissen aus? Kennt ihr die Unterschiede?
Xanthippos schrieb: > Immer wieder das selbe. Die Neuen verstanden die Altlasten nicht, > wollten sie auch nicht verstehen und fingen mit neuen Ideen wieder von > vorne neu an. und ich sollte eine bestehende "Luftmessung" erweitern wo schon 100k Baugrupen gelaufen sind, ich brauchte 3 Wochen um den Gruppenleiter zu überzeugen das das alte Prüfprogramm nichts misst! Dann erst durfte ich es neu machen, bei gleichzeitiger Prüftiefe verbessern und noch 30% Zeitersparnis. Leider wurden vom Prüfling keine 100k mehr bestellt, es waren knapp 1000. Die alten Kollegen haben schnell das Weite gesucht bevor der Schwindel aufflog und alles über Ihnen zusammenbricht.
:
Bearbeitet durch User
Dergute W. schrieb: > sollte man den qualitativ schlechten Code erst dann wegwerfen, wenn man Das versteht sich sowieso von selbst. Darum muss man es auch nicht erst extra erläutern. Wenn man aber sowieso das Software-Modul XYZ ändern muss, weil neue Anforderungen es so verlangen, dann kann man da auch aufräumen. Hin und wieder gelingt das sogar, obwohl dem Management natürlich die Code-Qualität vollkommen egal ist und nur auf Termine geschaut wird. Dass schlechte Qualität an SW-Anforderungen, SW-Architektur, SW-Design und SW-Implementierung auch automatisch schlechte Termintreue bedeutet, das hat man leider auch nach vielen Jahren immer noch nicht verstanden.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Wenn einer programmiert und die anderem im Team nur noch testen, ist das > schon schlecht, ... Stefan, ich habe großen Respekt vor Dir und Deinem (öffentlichen) Werk. Aber das widerspricht vollständig meiner Erfahrung mit guten Programmierern: Deren Code ist viel kleiner und lesbarer für eine Aufgabe, so das alle gewinnen. Tests, Code-Reviews etc. werden entweder weniger oder helfen den anderen, zu wachsen. Natürlich wachsen nicht alle mit. Aber einige schon. Und die anderen werden langfristig halt mit Projekten mit weniger Potential betraut. Gute Leute können es sich sogar leisten, arrogant zu sein (gegenüber Wannabies, nie gegenüber weniger befähigten oder Peers), da sie notfalls auch mit einem halben Team die volle Leistung bringen können. Wenn jemand anderes "zu gut für Neues" geschrieben hätte, wäre mein Bild: * macht viel Code (statt guten*) * Eigenbrödler (niemand profitiert davon) * Pedant (verlangt Prozesstreue) * fachlich wenig geschätzt (Als Hilfe, ja, aber niemand reißt sich darum, mit ihm zu arbeiten) (* Gute Programmiere machen x Zeilen am Tag. Schlechte 2x. Ein guter Programmierer ist ein Dichter: Er kämpft um jedes Wort, um jede Formulierung, um die Ausdruckskraft zu maximieren)
:
Bearbeitet durch User
Bruno V. schrieb: > Stefan, ich habe großen Respekt vor Dir und Deinem (öffentlichen) Werk. Das ist allerdings kein Produkt von Teamwork und auch sonst fachlich weit von meinem Job entfernt.
Bruno V. schrieb: > Ein guter Programmierer ist ein Dichter: Er kämpft um jedes Wort, um > jede Formulierung, um die Ausdruckskraft zu maximieren) Ein guter Programmierer arbeitet so, dass die SW in der Praxis gut verwendbar ist. Einer ist vor Jahren mit dem Flugzeug abgestürzt und hat sein Wissen mit ins Grab genommen. Da es NUR einen gab, war der Bestand der Firma in Gefahr!
Lu O. schrieb: > Bruno V. schrieb: >> Ein guter Programmierer ist ein Dichter: Er kämpft um jedes Wort, um >> jede Formulierung, um die Ausdruckskraft zu maximieren) > > Ein guter Programmierer arbeitet so, dass die SW in der Praxis gut > verwendbar ist. Einer ist vor Jahren mit dem Flugzeug abgestürzt und hat > sein Wissen mit ins Grab genommen. Da es NUR einen gab, war der Bestand > der Firma in Gefahr! Ich dachte, die einsamen Keller Lötkolben-, Tastentürhelden Zeiten seien vorbei. Heute sollst Du den ganzen Tag in Meetings verbringen und am Ende des Tages kommt die KI zum Diktat und setzt die Software um. Und am Ende des Tages hat man wie die Sozialwissenschaftler sich das Geld durchs Reden verdient. Das Denken überlassen wir der KI... Beide Perspektiven haben ihre Berechtigung. Während Präzision und Ästhetik wichtige Aspekte der Softwareentwicklung sind, ist es ebenso wichtig, dass Software robust, wartbar und von mehreren Personen verständlich ist, um die Abhängigkeit von Einzelpersonen zu verringern und die Kontinuität der Softwareentwicklung zu gewährleisten. Es scheint, dass in diesem Beitrag die Merkmale eines "guten" Programmierers diskutiert werden, sowie die potenzielle Arroganz, die einige talentierte Entwickler gegenüber weniger erfahrenen Kollegen oder solchen, die sich als "Wannabies" (Anfänger oder Möchtegern-Entwickler) erweisen, zeigen könnten. Die vorgeschlagenen Merkmale eines "guten" Programmierers könnten sein: Effizienz: Die Fähigkeit, mit weniger Aufwand mehr zu erreichen. Selbständigkeit: Die Fähigkeit, selbstständig zu arbeiten und auch unter Druck oder mit begrenzten Ressourcen gute Ergebnisse zu erzielen. Genauigkeit und Präzision: Die Fähigkeit, sich um jedes Detail zu kümmern und den Code auf höchstem Niveau zu halten. Respektiertes Fachwissen: Die Anerkennung durch Kollegen und Fachleute aufgrund ihres Wissens und ihrer Fähigkeiten. Kollaborationsfähigkeit: Die Bereitschaft, anderen zu helfen und als Teammitglied effektiv zu arbeiten. Die Erwähnung, dass gute Programmierer "sogar arrogant sein können", impliziert, dass sie sich aufgrund ihres Könnens ein gewisses Maß an Überlegenheit erlauben könnten, insbesondere gegenüber weniger befähigten Kollegen. Dies sollte jedoch nicht mit einer generellen Arroganz gegenüber ihren Kollegen oder dem Team verwechselt werden, da erfolgreiche Teams oft auf Zusammenarbeit und Respekt basieren. Die Metapher, dass ein guter Programmierer ein Dichter ist, der um jedes Wort und jede Formulierung kämpft, um die Ausdruckskraft zu maximieren, betont die Bedeutung von Eleganz, Klarheit und Effektivität im Code. Es zeigt auch, dass Programmierung nicht nur eine technische Fähigkeit ist, sondern auch eine kreative Kunstform sein kann.
Max schrieb: > Die Erwähnung, dass gute Programmierer "sogar arrogant sein können", > [...] insbesondere gegenüber weniger befähigten Kollegen. Ich hatte "gegenüber weniger befähigten Kollegen" explizit rausgenommen. Das offenbart einen miesen Charakter. Und gute Leute haben das meist nicht nötig. Ich meine eher die Arroganz, auf starre Prozesse oder Best Practices zu pfeifen, wenn sie offensichtlich ungeeignet sind. Beispielsweise ein einzelnes Goto zu verwenden, auch wenn der Projektleiter das kategorisch ausschließt. Oder Code zu reduzieren, obwohl nach LoC bewertet wird.
Max schrieb: > dass Programmierung nicht nur eine technische Fähigkeit ist, > sondern auch eine kreative Kunstform sein kann. Das ist es ganz sicher und genau deswegen fürchte ich nicht, von KI ersetzt zu werden.
Und jetzt kommt der Punkt, an dem geklärt werden sollte, was eigentlich „Programmieren“ ist, und auf welchem Level die Kunstform anfängt. Und da sag ich mal, die eigentliche Codeerestellung ist Handwerk, die aber ganz sicher aus Indien an die KI verlagert werden wird. Die „Kunst“ wird woanders benötigt. Oliver
Oliver S. schrieb: > die eigentliche Code-Erstellung ist Handwerk Dazu gehört aber auch: - Anforderungen verstehen - Unklarheiten klären - Lücken ergänzen - Code und Schnittstellen testen - Dokumentieren Dafür wenden Programmierer erheblich mehr Zeit auf, als für das Schreiben von Quelltext. Kein mir bekannter Programmierer kommt um diese Aufgaben herum. Bei QVC gab es vor einigen Jahren mal den Versuch, nur das reine Coden nach Indien auszulagern. Die haben so wenig mit gedacht, dass der Aufwand für die verbleibenden Aufgaben regelrecht explodiert ist und viele Korrektur-Runden gedreht werden mussten, was die Firma gar nicht gewohnt war.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Bei QVC gab es vor einigen Jahren mal den Versuch, nur das reine Coden > nach Indien auszulagern. Die haben so wenig mit gedacht, dass der > Aufwand für die verbleibenden Aufgaben regelrecht explodiert ist Das ist nicht nur die Erfahrung von QVC, sondern eigentlich jedem, der mal was nach Indien ausgelagert hat. Inder heisst bei uns 'grosse Klappe, nichts dahinter'. Gute Inder sitzen längst in den USA oder GB. Ex-UdSSR hingegen sind gute Leute.
Steve van de Grens schrieb: > Dafür wenden Programmierer erheblich mehr Zeit auf, als für das > Schreiben von Quelltext. Ok, das ist dann doch was anderes als das hier: Bruno V. schrieb: > Ein guter Programmierer ist ein Dichter: Er kämpft um jedes Wort, um > jede Formulierung, um die Ausdruckskraft zu maximieren) Wer da um jedes Wort kämpfen muß, ist wohl im falschen Job. Der Teil ist Handwerk. Oliver
Danke für die vielen Antworten. Nachdem sich das jetzt mehr in "Wer ist ein guter Programmierer" hinzieht wäre es wohl Sinnvoll den Thread zu schließen.
Flo schrieb: > Nachdem sich das jetzt mehr in "Wer ist ein guter Programmierer" hinzieht eigentlich ist das die Quintessens der Frage: Sieh zu, dass der Code klar, lesbar, ausdrucksstark ist und Anfoderungen/Schnittstellen festgehalten sind. Jemanden ohne konkrete Mitarbeit den Code erklären ist so vergeblich wie jemanden "Mal in Word einarbeiten lassen".
Steve van de Grens schrieb: > Bei QVC gab es vor einigen Jahren mal den Versuch, nur das reine Coden > nach Indien auszulagern. Die haben so wenig mit gedacht, dass der > Aufwand für die verbleibenden Aufgaben regelrecht explodiert ist und > viele Korrektur-Runden gedreht werden mussten, was die Firma gar nicht > gewohnt war. Nach meiner Wahrnehmung ist das aber eher ein kulturelles Thema, man darf in diesem Kulturkreis sein Gesicht nicht verlieren. Sein Gesicht verliert man, wenn man seine Arbeit nicht richtig beherrscht oder macht, also nicht genau das implementiert, was in der Spec steht, oder einen Vorgesetzten, oder die Spec kritisiert. Aus diesem Grunde denken viele Menschen dort zwar mit, wollen aber nicht negativ auffallen und äußern daher weder Kritik, noch Vorschläge. Mit unserer Kultur, Fragen direkt zu stellen, Themen offen anzusprechen und erkannte Probleme möglicherweise sogar selbst und ohne Rücksprache zu lösen, wird man in Indien sehr schnell sehr unangenehm auffallen. Das sollte man wissen, wenn man Arbeiten nach Indien auslagern möchte. Man kann das trotzdem machen, aber dann müssen die Specs absolut wasserdicht und vollkommen unmißverständlich ausformuliert sein, und zwar auch so, daß die Sprachbarrieren dabei keine Stolpersteine sein können. Denn das, was zuvor gesagt wurde, gilt natürlich nicht nur für die Coder, sondern auch für die Vorgesetzten: sie fragen im Zweifelsfall nicht nach, weil das hieße, daß sie ihren Job nicht können und deswegen ihr Gesicht verlieren.
Ein T. schrieb: > Nach meiner Wahrnehmung ist das aber eher ein kulturelles Thema, man > darf in diesem Kulturkreis sein Gesicht nicht verlieren. > [..] > Das sollte man wissen, wenn man Arbeiten nach Indien auslagern möchte. > Man kann das trotzdem machen, aber dann müssen die Specs absolut > wasserdicht und vollkommen unmißverständlich ausformuliert sein, und > zwar auch so, Diesem Irrglauben sind schon viele Firmen aufgesessen und haben Lehrgeld gelassen. Ich hatte einen guten Draht zum Leiter Systemtest eines Telefonanlagenherstellers. Man hat lokal Mitarbeiter entlassen, "von oben verordnet" und Testaufgaben nach Indien gegeben. Das Ergebnis war eine Katastrophe. Unser Partner in England hatte einen Techniker indischer Abstammung. War ein lieber Mensch, aber mit seinen Denkstrukturen bekam er Probleme der Anlagen nicht in den Griff. Es gibt auch andere Techniker begrenzter Kompetenz, aber Ranjit war irgendwie anders. Für mich hat sich der Eindruck gebildet, dass Europäer und Inder nicht harmonieren.
Manfred P. schrieb: > Für mich hat sich der Eindruck gebildet, dass Europäer und Inder nicht > harmonieren. die Inder schütteln auch immer den Kopf wenn sie ja meinen aber dann das ja nicht gilt.
:
Bearbeitet durch User
A. B. schrieb: > Wenn dann zusätzlich von dem/den alten Hasen etwas boshaftigkeit > hinzukommt und sie bestimmten Kram soundurchsichtig geschrieben haben Gibt's solche Arschlöcher wirklich? Also in meinem Umfeld (SW-Entwicklung für Steuerungstechnik) gibt es auch Programmcode, bei dem man sich fragt, was beim Schreiben im Gehirn des Entwicklers vorgegangen sein mag. Aber das ist in den wenigsten Fällen Absicht, sondern das schiere Unvermögen des Entwicklers, verständlichen Code zu schreiben (<grusel>, wenn ich dran denke, was ich da schon alles gesehen habe. Echt schlimm...) ciao Marci
Lu O. schrieb: > und hat > sein Wissen mit ins Grab genommen. Da es NUR einen gab, war der Bestand > der Firma in Gefahr! Dann war er allerdins ein schlechter Programmierer! ciao Marci
Marci W. schrieb: > wenn ich dran denke, was ich da schon alles gesehen habe. Echt schlimm Am schlimmsten finde ich meine eigenen Quelltexte, die ich vor vielen Jahren schrieb. Man lernt halt ständig dazu.
Steve van de Grens schrieb: > Am schlimmsten finde ich meine eigenen Quelltexte, die ich vor vielen > Jahren schrieb. Man lernt halt ständig dazu. 1. lernt man dazu 2. weiss man heute kaum noch warum man es damals so machte. Ich schaute mir letztens meinen relokatiblen Code vom Sharp PC1500 an. Es kab keinen Weg an den Programmcounter zu kommen, den brauchte man aber um mit branch +- und Return immer wieder zurück zu finden. Durch die Stackkorrektur und das ganze Programm blicke ich heute kaum noch durch.
Steve van de Grens schrieb: > Am schlimmsten finde ich meine eigenen Quelltexte, die ich vor vielen > Jahren schrieb. Geht mir auch so! Jugendsünden. Vergeben und vergessen ;-) ciao Marci
Steve van de Grens schrieb: > Marci W. schrieb: >> wenn ich dran denke, was ich da schon alles gesehen habe. Echt schlimm > > Am schlimmsten finde ich meine eigenen Quelltexte, die ich vor vielen > Jahren schrieb. Man lernt halt ständig dazu. Beim Corona-Lockdown habe ich mal die Zeit genutzt, aufzuraeumen und alte Disketten auszulesen. Ist schon interessant wie man die Probleme vor 30 - 35 Jahren geloest hatte. Natuerlich waren die Probleme einfacher (man wollte einfach nur eine Rechnung schreiben), aber die Maschinen (z.b. mit Turbo-Pascal 3.0 unter DOS) waren natuerlich dumm wie ein Stueck Brot (ach ja, Novell Netware war damals top of the line). Ich finde ich war damals viel kreativer :-) Was ich nie gemacht habe (jedenfalls willentlich): Selbst modifizierender Code. Gruesse
Thomas W. schrieb: > Ich finde ich war damals viel kreativer :-) Nun ja, Kreativität ist in bestimmten Bereichen reines Gift! :-) Oft sind die Quelltexte, die für mich schlimm aussehen, durchaus so kreativ, dass ich denke: "sowas Kompliziertes könnte ich gar nicht schreiben, da ich nicht so komplex denken kann und meine Gehirnleistung dafür nicht ausreicht". Ist ernst gemeint! Mein Code ist dagegen eher primitiv. Aber dafür versteht in hoffentlich auch jeder, ohne Knoten im Gehirn zu kriegen. ciao Marci
Marci W. schrieb: > Nun ja, Kreativität ist in bestimmten Bereichen reines Gift! :-) Oft > sind die Quelltexte, die für mich schlimm aussehen, durchaus so kreativ, > dass ich denke: "sowas Kompliziertes könnte ich gar nicht schreiben, da > ich nicht so komplex denken kann und meine Gehirnleistung dafür nicht > ausreicht". > Ist ernst gemeint! Mein Code ist dagegen eher primitiv. Aber dafür > versteht in hoffentlich auch jeder, ohne Knoten im Gehirn zu kriegen. > Komplex ist ja was anderes als kompliziert. Es gibt Entwickler, die sich kompliziert ausdrücken. Oft ist es auch Faulheit. Ich habe mal 'ne Klasse mit über 3000 Zeilen eingedampft, dass es nur noch ca. 2000 waren. Der Programmierer hat immer wieder den gleichen Kram programmiert (nur leicht abgeändert von Fall zu Fall), ihm kam aber nicht in den Sinn, mal 'ne Funktion zu extrahieren. Mein Refactoring war nicht mal besonders tiefgründig. Hätte ich mehr Zeit und Befugnisse in diesem Projekt gehabt (ich war da nur drei Wochen drin), hätte ich da noch mehr eingedampft. Und zumindest kann ich es über mich sagen: Bei mir entsehen solche Klassen gar nicht erst, da ich schon früh überlege, was ist denn der Boilerplate-Code hier und wo kann ich noch eine Funktion extrahieren. Dadurch wird der Code überschaubarer, weniger kompliziert und kann damit eher für komplexere Sachverhalte ertüchtigt werden.
Rudi R. schrieb: > Komplex ist ja was anderes als kompliziert. Es gibt Entwickler, die sich > kompliziert ausdrücken. Oft ist es auch Faulheit Das stimmt. Wenn ich Zeit habe, überarbeite ich meinen ersten Entwurf nochmal, damit er besser lesbar ist. Manchmal wird er dadurch etwas länger, aber das ist egal. > Dadurch wird der Code überschaubarer, weniger kompliziert und kann > damit eher für komplexere Sachverhalte ertüchtigt werden. Den Aspekt finde ich wichtiger, als die Anzahl der Zeilen oder raffinierte Tricks. Er ist meistens sogar wichtiger, als die Performance.
:
Bearbeitet durch User
Rudi R. schrieb: > Komplex ist ja was anderes als kompliziert. Auf jeden Fall. Komplexität ergibt sich schlicht aus einer Problemstellung. Man kann nur auf bestimmte Art und Weise mit Komplexität umgehen und diese beherrschen. Kompliziert ist die Art und Weise wie man Dinge tut, das hat man selbst in der Hand. Kein Code muss kompliziert sein.
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.