Was bringt einem Maschinencode?

Bitte aktiviere JavaScript!
Ich glaube 90% der heutigen Software würde besser, schneller und resourcen sparender laufen wenn die Programmierer vorher mal Assembler gelernt hätten.

Das ist wie mit dem Auto eine Runde auf dem Ring drehen. Kann jeder Depp und kommt irgendwie am Ziel an. Will er schneller ankommen muss er schnelleres auto kaufen.
Aber die, die sich mit der Technik auseinader setzen wissen wie man ein Fahrwerk so einstellt das man immer perfekte Bodenhaftung hat und damit schneller und Teileschonender fährt und sind mit einem Polo schneller am Ziel als der erstere mit seinem Porsche.
Ja, aber was ist "besser"?

Gute Software ist vor allem 1: (möglichst) fehlerfrei! Sobald das nicht gegeben ist, kannst Du die Software in die Tonne treten.

Und ich finde es ehrlich gesagt extrem lustig, wenn hier wirklich Leute in Maschinencode optimieren wollen. Denn auf der anderen Seite sehe ich dann Dinge, wie AOP, wo also Performance weggeschmissen wird. (So da teilweise Reflection eingesetzt wird, dann sogar ganz massiv!)

Ich finde das wäre bei gleichem Ausbildungsstand aber deutlich einfacher. Das mit dem "Jeder muss es warten können" ist ja heutzutage nur ein Problem weil du immer für den "dümmsten" Programmierer schreiben must. Gäbe es hier einen einheitlichen mindest Standard was ein Programmierer können muss wäre alles viel einfacher.
Also das kann man so nicht stehen lassen! Optimierungen auf Maschinencode Basis hast Du noch nicht gesehen, oder? Da wirst Du dann anderen Code sehen, als Du erwartest. Wir haben und damals in der Schule die Optimierungen des Compilers angesehen und das war schon extrem. Nach einer Funktion den Stack zurückbauen war da dann plötzlich ein ganz anderer Befehl, so dass wir da erst am stutzen waren. Und Reihenfolgen umändern, um irgendwas an Ticks zu sparen oder das Nachladen zu optimieren. Also da geht es nicht mehr um "gleichen Ausbildungsstand" nur auf einer anderen Sprache sondern da geht es um extremes Detailwissen, denn Du musst die Internas der CPU kennen. Und das, was Du heute schreibst, kann morgen Müll sein oder ggf. nicht mehr funktionieren, weil die neue CPU Generation irgend etwas anders macht oder Du bei der Nutzung von einem "Feature" nicht beachtet hast, dass der Status der CPU nach anderen Tricks in einem Status ist, dass der Trick nicht geht ...

Und das fängt ja schon bei tollen anderen Optimierungen an: Man kann doch Variablen einsparen! Da nutzt man vorhandene Variablen halt für Fehlermeldung ausgeben oder so... (Das habe ich damals in Produktion erlebt! Auf AIX Systemen hat ein Entwickler so Speicher eingespart. Da die Software einen relativ kleinen Speicherdurchsatz hatte, war das in % sogar schon eine deutliche Einsparung! Nur eben ging es da um IO Leistung auf dem Netzwerk - hin zu einer Datenbank und zu anderen Systemen im Netzwerk. Und die Kisten hatten ohne Ende Speicher und die Speicherauslastung war halt immer sehr niedrig....
Und der Effekt war: Wenn beim Start die Verbindung zum Oracle-Server nicht klappte, dann gab es eine Fehlermeldung. Diese wurde aber über die gleiche Variable ausgegeben, in der der Hostname stand, weshalb man beim Start des Services immer in das Logfile schauen musste und bei einem Fehler wurde der Service erneut gestartet... )

Daher: Finger weg von Optimierungen!
Es gibt eine Analyse mit folgendem Design. (Und ehe mir da jemand wieder so einen Müll vorwirft: Da wird man natürlich ein brauchbares Design wählen!) Und dann wird das nur noch implementiert und da gilt KISS! Wer da Zeit verschwendet und "smart" sein will, der kriegt einen drüber! Probleme am Design gefunden? Wichtige Verbesserung am Design? => Klar, das wird besprochen. Aber sonst wird da nichts optimiert!

Wenn es Laufzeit-Probleme gibt: Dann wird dies analysiert: Wo wird denn wie viel Zeit benötigt? Und dann werden Lösungen gefunden. Das ist dann aber wieder auf Design Ebene! Nicht die Implementations Ebene.

(Ansonsten hast Du den tollen Erfolg: Der Start der Applikation dauert 30s - das ist aus welchem Grund auch immer zu viel. Nun hast Du da etwas optimiert und ein Teil, den Du implementiert hast, braucht nur noch 10% der bisherigen Zeit. Leider war das ein Teil, der eh nur 10ms gebraucht hat. Jetzt nur noch 1ms. Also toll: statt 30s braucht es nur noch ... öhm ... 30s - die 9 ms hat der Kunde nicht einmal bemerkt....)

Und wenn die Performance über alles geht: Wieso gibt es dann die ganzen Laufzeit Checks? Was die an Zeit kosten! Prüfen ob Zugriffe innerhalb eines Arrays sind oder nicht ... Oder Context Switche sind eh böse - da kann man noch vieles optimieren. Was meint ihr, wie der Rechner abgehen würde, wenn man da Context Switche reduzieren würde ... User Context - was soll sowas denn?

==> Wir geben (aus gutem Grund!) ständig Performance weg. Und da wollt Ihr dann ernsthaft wieder drauf verzichten?

Aber das ist nur mein bescheidene Sicht. Jeder soll das machen, was er für richtig hält. Und es gibt bestimmt auch noch Anwendungsgebiete, in denen das noch gefragt ist (Microcontroller fallen mir da ein, aber mit der aktuellen Entwicklung wird das bald entfallen denke ich mal. Die werden immer leistungsfähiger und damit entfallen einige Notwendigkeiten. Und Themen wie Sicherheit werden immer wichtiger ... IoT Netze haben es ja schon in die Medien geschafft auf Grund von Vorfällen!).
 
Ja, aber was ist "besser"?

Gute Software ist vor allem 1: (möglichst) fehlerfrei! Sobald das nicht gegeben ist, kannst Du die Software in die Tonne treten.
Und da sind wir wieder bei meiner Aussage. Wer besser programmieren kann macht weniger Fehler. Wer versteht was er da tut macht weniger Fehler. Wer nur dicke Frameworks zusammen knüppelt kann meiner Meinung nach keine gute Software programmieren das ist heute aber der Standard. Wenn ich weiß wie ein Computer "denkt", dann "optimiere" ich automatisch dadurch das ich Code so designe, dass er für den Computer einfacher zu "bearbeiten" ist. Das gilt aber eben nicht nur für Maschinencode, das gilt auch für Java. Ist nur ein anderes Level des Verständnisses. Das erlange ich aber eben nur wenn ich weiß wie die Maschine funktioniert.

Ich akzeptiere deine Manie gegen Optimierungen. Ist ja auch nichts für jedermann. Und ich habe auch nirgends geschrieben das man heutzutage noch in Maschienencode schreiben soll. Ich habe lediglich geschrieben, dass wenn man Maschienencode zumindest mal vertanden hat, man ein ganz anderes Verständnis für den Computer bekommt und damit auch sein eigenes Denken "Wie programmiere ich Effektiv" sich ändert und man automatisch besseren Code schreiben wird.

Ich finde übrigens, dass es heutzutage immmer viel schwerer wird den Code anderer Leute zu lesen. Weil man kann ihn nur dann verstehen, wenn man den genau gleichen "Wortschatz" hat wie dieser. Sprich, wenn der nur ein Framework benutzt das ich nicht kenne dann darf ich mich da erstmal reinknien. Hätte er das gleiche benutzt wie ich es immer benutze wärs kein Problem. Wenn man diesen Gedanken jetzt einfach mal auf die Spitze treibt, dann wäre ein Code, der überhaupt kein Framework benutzt für jeden am einfachsten zu verstehen.
 
Und da sind wir wieder bei meiner Aussage. Wer besser programmieren kann macht weniger Fehler.
Deine Aussage lässt sich reduzieren auf: "Wer besser ist, ist besser".

"Programmierer" sind aber nun mal nur so gut, wie sie sind, da wird sich auch nicht ändern und war nie anders. Verbessern kann man aber die Methodiken, und maschinennahe Optimierungen sind dabei das Gegenteil von sinnvoll (die können aber durchaus ihren Sinn haben, aber nicht da, wo 99,9% der Programmierer täglich dran arbeiten).

Wer nur dicke Frameworks zusammen knüppelt kann meiner Meinung nach keine gute Software programmieren das ist heute aber der Standard.
Gatekeeping...

Frameworks sagen absolut nichts über "gute" Software aus oder gut programmieren können aus. Sie sind einfach nur ein "Werkzeug", entweder man weiß es zu nutzen, oder nicht - schlechter ist man im ersteren Fall nicht.

Wenn ich weiß wie ein Computer "denkt", dann "optimiere" ich automatisch dadurch das ich Code so designe, dass er für den Computer einfacher zu "bearbeiten" ist. Das gilt aber eben nicht nur für Maschinencode, das gilt auch für Java. Ist nur ein anderes Level des Verständnisses. Das erlange ich aber eben nur wenn ich weiß wie die Maschine funktioniert.
Code, der für den Computer einfach ist, ist für Menschen schwierig - Code wird hauptsächlich von Menschen gelesen, also sollte das für die einfach sein.

Ich finde übrigens, dass es heutzutage immmer viel schwerer wird den Code anderer Leute zu lesen. Weil man kann ihn nur dann verstehen, wenn man den genau gleichen "Wortschatz" hat wie dieser. Sprich, wenn der nur ein Framework benutzt das ich nicht kenne dann darf ich mich da erstmal reinknien. Hätte er das gleiche benutzt wie ich es immer benutze wärs kein Problem. Wenn man diesen Gedanken jetzt einfach mal auf die Spitze treibt, dann wäre ein Code, der überhaupt kein Framework benutzt für jeden am einfachsten zu verstehen.
Dein Gedanke geht leider etwas zu kurz.

Statt einem Framework, dass du kennen könntest, gibt es dann 4517 selbstgestrickte Varianten, in die du dich genauso reinknien musst. Nur gibt es da anders als beim Framework keine Doku, keine Beispiele und Tutorials, keine zug Mitwirkenden, die man fragen kann.

Jemand der Spring (Swing, JavaFX, beliebiges Framework...) kennt, findet sich in jedem entsprechendem Projekt zurecht.
Jemand der nur "selbstgestricktes Framework XY" kennt, findet sich in genau einem Projekt zurecht.

Wobei "selber stricken" natürlich auch sinnvoll sein kann, eben dann, wenn man Vorteile gegenüber bestehenden Frameworks bietet - nahezu jedes Framework ist so entstanden :)
 
Ich finde das wäre bei gleichem Ausbildungsstand aber deutlich einfacher. Das mit dem "Jeder muss es warten können" ist ja heutzutage nur ein Problem weil du immer für den "dümmsten" Programmierer schreiben must. Gäbe es hier einen einheitlichen mindest Standard was ein Programmierer können muss wäre alles viel einfacher.
Na, das kann ich so aber nicht stehenlassen. Ich versuche es mal mit einer Analogie aus dem Hardwarebereich:
Die meisten HW-Entwickler sehen ihren Schaltplan zu nichts weiter nutze, als dem ECAD mitzuteilen welche Footprints sie auf der Leiterkarte brauchen und wie diese verbunden werden müssen.
Das führt dann selbst für relativ einfache Schaltungen zu Schaltplänen, die im ECAD im Format >=A3 erstellt werden weil die Entwickler zu faul sind mehrere Schaltplanseiten anzulegen. Die Schaltpläne bestehen dann aus mehr oder weniger großen Blöcken mit mehr oder weniger Pins dran. Gerne versuchen HW-Entwickler dann, schon im Schaltplan das Platinenrouting vorzugeben.
Vor solchen Schaltplänen sitzt man dann erstmal und überlegt, was das Ganze eigentlich soll, das ist genauso wie mit unleserlichem, schlecht dokumentiertem Quellcode.

Und ja, viele Entwickler, die das so machen, halten sich für gut. Ich nicht, für mich fällt das in die Kategorie Frickler, die keinerlei Ansprüche an ihr Arbeitsergebnis haben.
Ich versuche stets, Schaltpläne so zu zeichnen, daß auch der dümmste Bauer sofort sieht was die Schaltung macht. Schaltpläne müssen bequem auf A4 ausgedruckt werden können, in der Regel beschreibt eine Schaltplanseite genau einen funktionalen Teilbereich (Spannungsversorgung, USB-Anbindung, LCD, ...), mit Prosa bin ich da auch nicht sparsam. Ganz vorne ein Blockschaltbild, daß eine Übersicht liefert.
Die Genialität eines HW-Entwicklers mißt sich meines Erachtens nicht daran, in seinem eigenen Chaos gut durchzublicken, denn das kann jeder. Zumindest während er daran arbeitet. Die meisten HW-Entwickler sitzen nach zwei Jahren wieder über ihren eigenen Designs und rätseln wer diesen verfluchten Mist verzapft hat, da sieht ja keine Sau durch.
Sondern die Genialität eines HW-Entwicklers mißt sich (m.E., unter anderem!) daran, Funktionen mit verblüffend wenig Teileaufwand zu implementieren und dabei andere Anforderungen gleich mitzuverbessern. Mit einem gut lesbaren Schaltplan stellt man diese Genialität zur Schau. Und selbst wenn ich meinen Schaltplan selber nie wieder lesen muß, so wird vielleicht wenigstens der ein oder andere Servicetechniker dafür dankbar sein.

Und soweit ich das mit meinen Programmierkenntnissen beurteilen kann, ist das beim Programmieren nicht anders, ganz im Gegenteil.

Und da sind wir wieder bei meiner Aussage. Wer besser programmieren kann macht weniger Fehler. Wer versteht was er da tut macht weniger Fehler.
Was heißt denn für dich "besser programmieren"? Und was sind denn deiner Definition nach Fehler? Schlechtes Design macht oft Probleme, ja. Und sonst? Fehler entstehen auch durch Schusseligkeit. Aber das ist dann oft relativ schnell behebbar, und hat meines Erachtens weniger mit den Programmierfähigkeiten ansich zu tun. Eher mit der Umgebung, allg. Auslastung, und teilweise auch Veranlagung. Die meisten Fehler, die ich mache, entstehen durch Schusseligkeit. Gerade deswegen lege ich auch soviel Wert auf kugelsicher übersichtliche Arbeit, so fallen Fehler wahrscheinlich eher auf.


Wenn ich weiß wie ein Computer "denkt", dann "optimiere" ich automatisch dadurch das ich Code so designe, dass er für den Computer einfacher zu "bearbeiten" ist. Das gilt aber eben nicht nur für Maschinencode, das gilt auch für Java. Ist nur ein anderes Level des Verständnisses. Das erlange ich aber eben nur wenn ich weiß wie die Maschine funktioniert.
Es gab im Mikrocontroller.net mal eine fürchterlich lange Diskussion darüber, wie man (ich glaub es war) die Abbruchbedingung in einer While-Schleife in C am besten formliert, sodaß das Programm schneller läuft.
Später hat jemand mal beide diskutierten Versionen geschrieben, kompiliert und das Resultat wieder disassembliert. Aus beiden Codevarianten hat der Compiler exakt denselben Maschinencode generiert.
Das hat mein Verständnis von Optimierung in Hochsprachen sehr geprägt.

Wenn man diesen Gedanken jetzt einfach mal auf die Spitze treibt, dann wäre ein Code, der überhaupt kein Framework benutzt für jeden am einfachsten zu verstehen.
Naja, eine graphische Benutzeroberfläche will ich nicht in C erstellen. Da bin ich um Werkzeuge wie Java ganz froh. Ansonsten halte ich es allgemein mit Paul Watzlawick:
Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.
 
Was mir gerade eingefallen ist: Einen Punkt hatte ich nicht beleuchtet obwohl ich es wollte:

Die Aussage, dass ich, nur weil Code lesbar sein soll, dann sozusagen für "Dumme" entwickeln muss. Das sehe ich so nicht.

Es ist immer eine Frage nach der Zielgruppe. Schreibe ich Code hier für einen Anfänger, dann sind Anfänger tatsächlich meine Zielgruppe und dann wird das Ergebnis anders aussehen, als wenn ich eine Zielgruppe von Experten habe.

In einem Projekt ist es so, dass i.d.R. Coding Guidelines bestehen. Und diese bilden sich über die Zielgruppe. Also ein Entwicklungsteam entscheidet, was wie lesbar ist und was bevorzugt wird.
-> So hat dies einen klaren Einfluss darauf, was jemand können muss, der in das Team soll/will.
-> Es hat einen Einfluss, woran ich mich gewöhne. (Der Punkt ist ja auch zu Recht angesprochen worden!)

Aber Ziel ist halt, dass jemand, der im Team ist und daher gewisse Dinge kennt und weiß, möglich gut den Code verstehen / warten / verändern / .... kann.

So ist klar: Nutze ich ein Framework (z.B. spring), dann sollte:
a) ich das Framework kennen und verstehen
b) jeder, der meinen Code lesen und verstehen will, den Code verstehen.

So nutze ich das Framework und werde nicht extra erläutern, was ich da genau mache so dies klar ist. Also krasses Beispiel: Logging framework: log.info(.....) Aufruf - da kommt dann kein Kommentar, dass ich nun einen Info-Logeintrag schreibe mit Logging Framework xyz. Und so verhält es sich auch bei Spring, nur eben ist es da weniger trivial, wenn z.B. die Security gesetzt wird. Aber: Wer das kennt, der versteht es. Wer es nicht kennt, dem fehlen die Grundlagen und der soll erst einmal die Grundlagen lernen!
 
Es ist immer eine Frage nach der Zielgruppe. Schreibe ich Code hier für einen Anfänger, dann sind Anfänger tatsächlich meine Zielgruppe und dann wird das Ergebnis anders aussehen, als wenn ich eine Zielgruppe von Experten habe.
Wobei das, mMn, kaum einen Unterschied macht, Ausnahmen bestätigen natürlich die Regel ;)

Aber was würde man für Anfänger anders lösen, als für Experten? "Normalen" Code würde ich nicht anders schreiben, wenn da so merkwürdige Konstrukte vorhanden sind, dass sie nur Experten verstehen, ist das entweder kein "normaler" Code oder gehört refactored.
Was man einschränken könnte, ist die Nutzung irgendwelcher Libs, Frameworks oder APIs - aber da ist selten eine sinnvolle Einschränkung möglich, zumindest fällt mir grad kein Beispiel ein, wo eine Lib sinnvoll ist, aber für Anfänger zu komplex ist. Die einzige Möglichkeit ist, die Dinge einfach zu lernen.
Mir fallen nur einige Dinge ein, bei denen Anfänger auf vermeintlich komplizierte Lösung (=Nutzung von Lib/Framework) verzichtet haben, und es stattdessen selbst gelöst haben - es ist immer nach hinten losgegangen.
 
Wieso ist doch eigentlich recht einfach. Je mehr "Features" einer Sprache oder eines FrameWorks ich nutze umso mehr verlange ich jemand anderem ab es zu verstehen.
Einfaches Beispiel. Benutze ich in Java streams, dann muss ich voraussetzen das jeder Streams kennt. Ich könnte das genauso gut und mit ein wenig mehr codezeilen ohne streams machen und die Anzahl derjenigen die es verstehen erhöht sich drastisch ohne das der Code daduchr unleserlich würde. Denn dann wäre ja jeder Code vor Java8 (Glaube das war das mit Streams bin aber nicht sicher) unleserlich.
Genau das kann ich dann eben skalieren auf jede Sprache und jedes Framework. W
 
Wobei das, mMn, kaum einen Unterschied macht, Ausnahmen bestätigen natürlich die Regel ;)
Ich denke schon, dass dies einen Unterschied macht.

Denk nur hier an das Forum: Klar andere Zielgruppe und schon verzichtet man auf Lambda oder steam(). Oder setzt noch einen Kommentar mit in den Code (Wo jeder mit mehr Erfahrung das sofort sehen würde ...)

Auf Arbeit kann ich dann durchaus auch Konstrukte wie
resultObject.stream().filter(e -> e.getName().equals("someKey")).findFirst().get().getValue();
stehen lassen. Nenne ich jetzt nicht mehr Clean Code, aber das Problem ist, dass das Vorgegebene resultObject ein List<> von Key/Value Paaren ist, was ich eigentlich als eigenständigen Typen kapseln würde mit einer Funktion getValue(key).
(List und keine Map, weil Keys mehrfach vorkommen können und dürfen!)

Ist also eine Gradwanderung: Was für Klassen führe ich noch ein und was packe ich noch alles an ... Da landet sowas leicht mal im Backlog für die nächste Überarbeitung, so jetzt keine Zeit dafür ist.
 
Wieso ist doch eigentlich recht einfach. Je mehr "Features" einer Sprache oder eines FrameWorks ich nutze umso mehr verlange ich jemand anderem ab es zu verstehen.
Und je mehr du selbst schreibst, anstatt bereist vorhandenes zu nutzen, umso mehr verlange ich jemand anderem ab es zu verstehen.

Du verzichtest nicht einfach nur auf etwas, du ersetzt es durch etwas eigenes, was nahezu immer erstmal mehr Code, den weniger Leute kennen, bedeutet.


Einfaches Beispiel. Benutze ich in Java streams, dann muss ich voraussetzen das jeder Streams kennt. Ich könnte das genauso gut und mit ein wenig mehr codezeilen ohne streams machen und die Anzahl derjenigen die es verstehen erhöht sich drastisch ohne das der Code daduchr unleserlich würde. Denn dann wäre ja jeder Code vor Java8 (Glaube das war das mit Streams bin aber nicht sicher) unleserlich.
Verzichtet man zusätzlich noch auf Collections und Strings, und löst stattdessen alles mit Arrays, muss man sogar noch weniger kennen...

Die Stream-Lösung kann übrigens für jemanden, der mit Mathe- oder FP-Hintergrund kommt, durchaus einfacher zu verstehen sein.


Wenn man dein Beispiel mal durch irgendwas ersetzt, was minimal größer ist als Streams, sieht das schon ganz anders aus.

Verzicht auf Jsonb/Gson/Jackson erspart das Lernen der entsprechenden Lib - aber JSON parsen ohne Lib steht in absolut keinem Verhältnis zum Lernen der Libs.
Am Parsen von CSV versucht sich jeder mal dran - spart das Einarbeiten in eine der X Libs, ist dafür aber auch bei jedem kaputt und ein vernünftiges Parsen ist deutlich mehr Aufwand, als alle Libs zusammen zu lernen.
Dependency-Injection (Spring wurde ja schon genannt) ist auch deutlich mehr Aufwand, als die dafür nötigen Libs kennen zu lernen.


Denk nur hier an das Forum: Klar andere Zielgruppe und schon verzichtet man auf Lambda oder steam(). Oder setzt noch einen Kommentar mit in den Code (Wo jeder mit mehr Erfahrung das sofort sehen würde ...)
Naja, auf Streams und Lambdas würde ich nicht verzichten, und einige andere machen das auch nicht (verwunderlich, dass in diese Thread noch keine Variante von @httpdigest auftaucht :p )

Kommentare braucht man halt, wenn man den Code erklären will. Normaler Code ist ja auch nicht als Erklärung für absolute Progammieranfänger gedacht, die grad die Syntax lernen.
Da sollte man wohl trennen zwischen Anfänger, die seit 2 Wochen Java kennen, und welchen die's seit einem Jahr kennen und die Grundlagen können.

Auf Arbeit kann ich dann durchaus auch Konstrukte wie
resultObject.stream().filter(e -> e.getName().equals("someKey")).findFirst().get().getValue();
stehen lassen. Nenne ich jetzt nicht mehr Clean Code, aber das Problem ist, dass das Vorgegebene resultObject ein List<> von Key/Value Paaren ist, was ich eigentlich als eigenständigen Typen kapseln würde mit einer Funktion getValue(key).
(List und keine Map, weil Keys mehrfach vorkommen können und dürfen!)

Ist also eine Gradwanderung: Was für Klassen führe ich noch ein und was packe ich noch alles an ... Da landet sowas leicht mal im Backlog für die nächste Überarbeitung, so jetzt keine Zeit dafür ist.
Wenn ich dich richtig verstehe, sagst du doch selbst, dass du so eine Lösung nicht bevorzugen würdest, sondern stattdessen eine saubere. Dass die es nicht ist, liegt doch eher an äußeren Bedingungen, anstatt an Anfänger vs. Experte.
Wenn das Team jetzt voller Anfänger wäre (also noch weniger in der gleichen Zeit schaffen würde), wäre doch auch noch weniger Zeit für die Überarbeitung, da würde die doch erst recht nicht passieren? o_O
 
Wenn ich dich richtig verstehe, sagst du doch selbst, dass du so eine Lösung nicht bevorzugen würdest, sondern stattdessen eine saubere. Dass die es nicht ist, liegt doch eher an äußeren Bedingungen, anstatt an Anfänger vs. Experte.
Wenn das Team jetzt voller Anfänger wäre (also noch weniger in der gleichen Zeit schaffen würde), wäre doch auch noch weniger Zeit für die Überarbeitung, da würde die doch erst recht nicht passieren? o_O
Hmm ... jetzt werden Begriffe wichtig denke ich mal. Mal schauen, ob ich es halbwegs sauber hin bekomme. Und das ist natürlich nur meine Sichtweise. Hier muss jeder für sich sehen, wie er das handhaben kann und will. (Und teilweise wird man auch einfach fremdbestimmt. Es geht hier ja nicht um meine Freizeit sondern um bezahlte Arbeit. Und der mit dem Geld will nun einmal auch etwas bestimmen :) )

Wenn ich Code erstelle, dann geht es um eine Akzeptanz. Diese setzt sich aus mehreren Dingen zusammen z.B.:
- Funktionalität -> Am Ende muss der Code machen, was gefordert war.
- Wartbarkeit -> Hier kommen dann Dinge rein wie "Clean Code", Unit Tests, ...
- Zeit / Kosten -> Das Ziel wurde in der zugesagten Zeit innerhalb des vorgesehenen Kostenrahmens erreicht.

Um ein Akzeptanz zu erreichen kann ich nur begrenzt auf alles eingehen. Ich kann nicht hingehen und eine bestehende Lösung komplett umschreiben (was Geld und Zeit kostet) nur damit der Code etwas schöner wird.

Daher werden Abstriche an den einzelnen Punkten gemacht. Dies geht aber nicht nur von mir aus, sondern es gibt viele Mitstreiter wie z.B. Produktmanager/-owner (Der kann zu der Funktionalität etwas sagen, hat ggf. das Geld und auch Anforderungen an die Zeit), Projektleiter (Der will, dass ich Funktionalität / Zeit / Kosten einhalte. Wartbarkeit interessiert ihn in seiner Rolle nicht, da das ja zukünftig Projekte sind.... Sein "Projekt" muss ja jetzt erfolgreich sein (Funktionalität in Zeit / Budget erreicht))

Und als Entwickler muss man dann auch Abstriche machen. Code muss lesbar sein, aber es muss ggf. nicht "perfekt" sein. Und da muss man dann offen reden, denn der Produktmanager muss wissen, dass da etwas zu überarbeiten ist, damit zukünftige Änderungen günstig (also mit geringeren Kosten / kürzeren Implementationszeiten) durchgeführt werden können.

Somit zurück zu dem Code:
Der Code ist in der Form in einem Entwicklungsteam akzeptabel. Aber wenn das nächste Mal der zugrunde liegende Code angepasst wird, dann wird es da eine Anpassung geben. Aber ich fange jetzt nicht in einem Entwicklungszyklus für Produkt A an, an Produkt B Änderungen vorzunehmen. Das kann gut gehen, aber die Gefahr ist groß, dass damit vieles aus dem Ruder läuft. (Dann geht evtl. plötzlich ein Test von Produkt B nicht mehr und die kleine, schnelle Änderung hat einen riesen Rattenschwanz, der Zeit/Geld kostet...)

Somit kommt da also auch noch ein Risikomanagement mit rein. Was für Änderungen kann ich wo / wie auf mich nehmen? Neue Risiken, die im Rahmen der Implementation erst auftauchen, sind immer blöd für ein Projekt....

Und natürlich kann man sich immer Fragen: Wieso musst Du das denn in Produkt B anpassen? Ich kann es doch direkt hier machen. Es spricht technisch ja nichts dagegen, eine neue Klasse zu erstellen, die dann so eine List<..> nimmt und alles entsprechend aufbereitet. Aber das ist auch nur ein Workaround, denn Code gehört ja an den richtigen Ort. Und etwas, das in B gehört, sollte nicht in A gepackt werden. Also ist lediglich die Frage, welchen Weg ich gehen möchte. Aber in dieser Situation sehe ich erst einmal keine "perfekte" Lösung für mich, so dass ich mich zurück lehnen würde und sagen würde: "Ich bin zufrieden und habe keine offenen Punkte".

Und es ist dann auch so, dass man mit einer Perfektionierung sehr viel Ressourcen verbrauchen kann. Daher ist es auch notwendig, dass man an irgend einem Punkt das Erreichte akzeptiert.

Ist das soweit deutlich und auch etwas klarer geworden? Ist teilweise schwer zu beschreiben bzw. man müsste sich noch länger hinsetzen und alles durchdenken ...
 
Ist das soweit deutlich und auch etwas klarer geworden? Ist teilweise schwer zu beschreiben bzw. man müsste sich noch länger hinsetzen und alles durchdenken ...
Das man oft Einschränkungen machen muss, ist klar ;)

Aber die Einschränkungen hängen ja nur selten davon ab, ob Anfänger oder Experten mit dem Code arbeiten müssen - entweder die Zeit für "guten" Code ist da, oder eben nicht. Und soweit ich das bisher sehen kann, ist die Wertschätzung für guten Code bei Anfängern mit am geringsten, und daher auch die Arbeit, die man da rein stecken würde.


Oder anders:
Diesen Code: resultObject.stream().filter(e -> e.getName().equals("someKey")).findFirst().get().getValue(); würdest du unter ansonsten gleichen Bedingungen anders schreiben, wenn du andere Teamkollegen hättest?
 
Diesen Code: resultObject.stream().filter(e -> e.getName().equals("someKey")).findFirst().get().getValue(); würdest du unter ansonsten gleichen Bedingungen anders schreiben, wenn du andere Teamkollegen hättest?
Ja, wenn die Akzeptanz nicht da wäre für die Stream API oder Lambdas, dann hätte ich den Code anders geschrieben. Dann wäre es eine Methode geworden, die in einer Schleife alle Elemente durchläuft und prüft um dann den ersten Fund zurück zu geben.
 
Die Diskussion gibt es ja öfter mal und in einem Punkt bin ich völlig bei @Thallius (obwohl ich jetzt nicht weiß, ob er ihn hier genannt hat :)) Es ist teilweise erschreckend, wie gedankenlos manche Entwickler mit Ressourcen umgehen. Da werden z. B. zig MB an Daten der Einfachheit (oder besser Bequemlichkeit?) halber komplett geladen. Das "Beste" daran ist die Argumentation: wenn dem Kunden der Speicher nicht reicht, soll er halt weitere Riegel einbauen, RAM kostet ja heute nichts mehr. Es ist manchen völlig egal, wie groß der Mist ist, den sie fabrizieren, irgendwer wird's schon richten.
 
Die Diskussion gibt es ja öfter mal und in einem Punkt bin ich völlig bei @Thallius (obwohl ich jetzt nicht weiß, ob er ihn hier genannt hat :)) Es ist teilweise erschreckend, wie gedankenlos manche Entwickler mit Ressourcen umgehen. Da werden z. B. zig MB an Daten der Einfachheit (oder besser Bequemlichkeit?) halber komplett geladen. Das "Beste" daran ist die Argumentation: wenn dem Kunden der Speicher nicht reicht, soll er halt weitere Riegel einbauen, RAM kostet ja heute nichts mehr. Es ist manchen völlig egal, wie groß der Mist ist, den sie fabrizieren, irgendwer wird's schon richten.
In dem Zusammenhang habe ich mir schon öfter die Frage gestellt: Ich kenne Hybernate nicht wirklich aber das ist ja das was alle benutzen.
Wenn ich eine Liste von Objecten habe, die als Attribute einen Namen und mehrere Listen auf weitere Objekte haben und ich nun einfach eine Liste mit den Namen aller Objekte haben will die mit "A" anfangen. Lädt Hybernate dann alle Objekte deren Name mit "A" anfängt komplett inklusive aller weiteren Objekte in den Listen? Ich wüßte jetzt nicht wie das anders gehen sollte, denn sonst bekomme ich ja inkonsistente Objekte.
Andererseits ist sowas ja ein absoluter Standard nicht immer das gesamte Object zu laden wenn ich nur einen Teil davon brauche (Das ist zumindest in meinem Denken so)
Wie funktioniert das also mit Hybernate?

Gruß

Claus
 
In dem Zusammenhang habe ich mir schon öfter die Frage gestellt: Ich kenne Hybernate nicht wirklich aber das ist ja das was alle benutzen.
Wenn ich eine Liste von Objecten habe, die als Attribute einen Namen und mehrere Listen auf weitere Objekte haben und ich nun einfach eine Liste mit den Namen aller Objekte haben will die mit "A" anfangen. Lädt Hybernate dann alle Objekte deren Name mit "A" anfängt komplett inklusive aller weiteren Objekte in den Listen? Ich wüßte jetzt nicht wie das anders gehen sollte, denn sonst bekomme ich ja inkonsistente Objekte.
Andererseits ist sowas ja ein absoluter Standard nicht immer das gesamte Object zu laden wenn ich nur einen Teil davon brauche (Das ist zumindest in meinem Denken so)
Wie funktioniert das also mit Hybernate?
Hibernate.

Ein Teil der Daten wird direkt geladen ("eager"), ein anderer Teil transparent erst dann, wenn benötigt ("lazy"), letzteres üblicherweise für Beziehungen.
 
Es ist teilweise erschreckend, wie gedankenlos manche Entwickler mit Ressourcen umgehen.
Da haben du/Thallius ja auch völlig recht und ich denke mal, daß das selbstverständlich ist. Ich glaube nicht daß das jemand ernsthaft angezweifelt hat oder anders sieht.

Ich will gar nicht wissen wieviele Schleifendurchläufe in Programmen überflüssig oder relativ einfach zusammenlegbar wären, keine Frage. Oder wieviele Variablen zwar deklariert und vielleicht noch initialisiert, aber nie weiter benutzt werden.

Aber das sind alles Probleme, die das eigentliche Thema - Maschinencode (oder ASM) - doch überhaupt nicht berühren. Oder nicht?
 
Aber das sind alles Probleme, die das eigentliche Thema - Maschinencode (oder ASM) - doch überhaupt nicht berühren. Oder nicht?
Ne, höchstens insofern, als dass man unterstellen kann, dass Leute mit Assemblererfahrung (oder Erfahrung auf entsprechend leistungsschwacher Hardware), mit begrenzten Ressourcen umzugehen wissen :)
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben