letzter Beitrag von Goodwell am
Für solche Sachen würd ich eher Antlr nehmen, oder etwas ähnliches.
Der Wegwerf-Prototyp sollte Zeit sparen, weil die dynamischen Datentypen in Perl eingebaut sind. Danach hatte ich geplant, den Compiler systematisch mit Tools (yacc/lex) oder ohne Tools in C zu realisieren.
Hauptsache, man hat nicht Interface = new ObjektDasInterfaceUmsetzt() irgendwo geschrieben, sondern das irgendwo in drölfzig Helferklassen versteckt.Und wenn das nicht fix? Und sich womöglich doch erst zur Laufzeit entscheidet. Man kann doch nicht alles statisch vorgeben.
Arbeitest du dann mit Class-Factories (auch wieder so ein Design Pattern
) oder mit altmodischen case-Kaskaden.
Und von anonymen Methode und Lambda-Ausdrücken hältst du dann sicher auch nicht. Du scheinst irgendwie gegen alles zu sein, was moderne Programmierung ausmacht.
Ich habe noch kaum ein Projekt getroffen, wo man dieses Dependency-Zeug wirklich brauchte. In fast allen Fällen war es genau eine Klasse die es gab, und die hat man per Interface verwendet. Dafür brauche ich doch so ein Verstecken nicht?
So unterschiedlich können Erfahrungen sein. Wenn ich keinen Dependency Container brauche, dann verwende ich auch keinen.
Wie gesagt, gibt es noch den Zwischenweg über Class-Factories. Das hängt aber von der Projektstruktur ab.
Ja, und viele Frameworks verwenden Dependency Container. Da kommt man dann nicht drum rum. Man muss die dann aber für den eigene Code nicht zwingend verwenden, wenn es nicht sinnvoll ist.
Ich verwende die Design Pattern, die mir weiterhelfen. Weder lehne ich bestimmte Pattern aus Prinzip ab noch verwende ich sie aus Prinzip.
Maximale Testbarkeit (über Unittests) ist bei uns ein großes Thema. Das wird ohne einige Design Pattern sehr schwierig und umständlich.
Alles anzeigenSo unterschiedlich können Erfahrungen sein. Wenn ich keinen Dependency Container brauche, dann verwende ich auch keinen.
Wie gesagt, gibt es noch den Zwischenweg über Class-Factories. Das hängt aber von der Projektstruktur ab.
Ja, und viele Frameworks verwenden Dependency Container. Da kommt man dann nicht drum rum. Man muss die dann aber für den eigene Code nicht zwingend verwenden, wenn es nicht sinnvoll ist.
Ich verwende die Design Pattern, die mir weiterhelfen. Weder lehne ich bestimmte Pattern aus Prinzip ab noch verwende ich sie aus Prinzip.
Maximale Testbarkeit (über Unittests) ist bei uns ein großes Thema. Das wird ohne einige Design Pattern sehr schwierig und umständlich.
Ja, die Stile sind sehr unterschiedlich. Ist immer schwierig, verschiedene Ansichten unter einen Hut zu bekommen.
Unit Tests sind sehr wichtig, wobei ich aber kein Fan davon bin, den eigentlich Code zu verunstalten, damit man Unit Tests machen kann.
Unit Tests sollten Code abtesten, so wie er im Endprodukt abläuft. Das ist z.Bsp. schwierig, wenn man mit externen Systemen kommuniziert.
Klar, kann man da überall per Interfaces Mocks einziehen, etc.. Aber dann testet man ja nicht mehr den Code, der später läuft, sondern den Mock. Manche Sachen bekommt man nicht per Unit Tests abgedeckt.
Da tue ich mich auch schwer die Testabdeckung mit KPIs zu versehen. Wie so oft, vieles hängt von vielem ab, und pauschales Erzwingen der gleichen Werte (z.Bsp.> 80% Codeabdeckung durch Unit Tests) halte ich für gefährlich.
Wenn man sowas forciert, führt das nur zu Workarounds.
Unit Tests sollten Code abtesten, so wie er im Endprodukt abläuft. Das ist z.Bsp. schwierig, wenn man mit externen Systemen kommuniziert.Klar, kann man da überall per Interfaces Mocks einziehen, etc.. Aber dann testet man ja nicht mehr den Code, der später läuft, sondern den Mock. Manche Sachen bekommt man nicht per Unit Tests abgedeckt.
Externe Systeme sind ein Totschlagargument gegen Unittests, das man häufig hört.
Man kann aber die Ein- und Ausgabelogik oft sehr gut von der eigentlichen Ein-/Ausgabe trennen. Das ist keine Verunstalten und das sind auch keine Mocks. Das ist einfach eine Designentscheidung wie man die Interfaces aufbaut.
Man kann dann die gesamte Logik unabhängig vom externen System unittesten. Natürlich muss man auch gegen das externe System testen, aber das macht man sicher nicht bei jeder Codeanderung. Die Unittests laufen aber jedesmal.
Bei meinen kleinen Softwareprojekten zuhause mache ich das auch nicht so konsequent. Das liegt aber daran, dass ich da häufig einfach losprogrammiere und viel rumexperimentiere. Und Dinge eben bewusst ganz anders angehe. Sonst wäre das kein Hobby sondern einfach nur die Fortführung meiner Arbeit zuhause. Einige dieser privaten Projekte sind aber auch schon im Choas geendet und ich musste komplett neu aufsetzen.
Ganz ehrlich, ich bin dann auch froh wenn irgendwann Rente ist. Privat werde ich sicher immer irgendwas basteln, aber beruflich ist das je nach Projekt wirklich ein Graus.
Nachdem sich die F64 Programmiererelite über "neumodische" Programmiertechniken auslässt bis ich ganz froh das mein Kopp für so einen Beruf nicht ausreicht. Mein Gefühl sagt mir das ich zuhause einiges richtig machen muss, wenn die Kritik der Profis so heftig ausfällt. 
Das liegt aber daran, dass ich da häufig einfach losprogrammiere und viel rumexperimentiere.
Wenigstens einer der meine Vorgehensweise praktiziert. 
Unit Tests sollten Code abtesten, so wie er im Endprodukt abläuft. Das ist z.Bsp. schwierig, wenn man mit externen Systemen kommuniziert.Klar, kann man da überall per Interfaces Mocks einziehen, etc..
Der externe Dienstleister hat keine Testumgebung?
Ansonsten kann man auch ein eigenes Mock des fremden Systems bauen und eben nur die URL beim Testen auf localhost setzen. Ist halt Aufwand, ja, aber der eigene Code muss dadurch nicht hässlich werden.
Mit "Extern" meine ich Schnittstellen zu anderen Systemen, die nicht direkt Teil des Projektes sind. Datenbank zum Beispiel, oder ein Webservice.
Sowas ruft man bei Unit Test ja nicht sinnvoll auf. Sowas gehört zu Integrationstests, oder Smoketests beim Deployment.
Unit Tests sind sehr wichtig, wobei ich aber kein Fan davon bin, den eigentlich Code zu verunstalten, damit man Unit Tests machen kann.
Da stimme ich dir voll zu.
Unit Tests sollten Code abtesten, so wie er im Endprodukt abläuft. Das ist z.Bsp. schwierig, wenn man mit externen Systemen kommuniziert.
Klar, kann man da überall per Interfaces Mocks einziehen, etc.. Aber dann testet man ja nicht mehr den Code, der später läuft, sondern den Mock. Manche Sachen bekommt man nicht per Unit Tests abgedeckt.
Bei Unittests muss man eigentlichh auch nicht jede letzte Codezeile testen, sondern nur quasi das "observable behaviour". Wenn ich also einen Mock verwende, dann deshalb um z.B. Fehlersituation zu erzeugen, die im Normalfall kaum auftreten. Dann teste ich ja nicht den Mock, sondern die Reaktion meines Codes auf die entsprechenden Situation.
Unit Tests sollten Code abtesten, so wie er im Endprodukt abläuft. Das ist z.Bsp. schwierig, wenn man mit externen Systemen kommuniziert.
Klar, kann man da überall per Interfaces Mocks einziehen, etc.. Aber dann testet man ja nicht mehr den Code, der später läuft, sondern den Mock. Manche Sachen bekommt man nicht per Unit Tests abgedeckt.
Bei Unittests muss man eigentlichh auch nicht jede letzte Codezeile testen, sondern nur quasi das "observable behaviour". Wenn ich also einen Mock verwende, dann deshalb um z.B. Fehlersituation zu erzeugen, die im Normalfall kaum auftreten. Dann teste ich ja nicht den Mock, sondern die Reaktion meines Codes auf die entsprechenden Situation.
Stimmt. Aber es ist gibt so geniale Manager, die KPIs aufstellen, die besagen, es müssen mindestens 80% Code durch Unit-Tests abgedeckt sein. Geht halt schwierig, wenn das Schnittstellencode ist. Dem doofen Tool ist das natürlich egal, das macht erstmal rot und der Entwickler darf zusätzlich zum eigenen Code auch noch ein Analyse-Tool pflegen.
Da stimme ich dir voll zu.
Bei Unittests muss man eigentlichh auch nicht jede letzte Codezeile testen, sondern nur quasi das "observable behaviour". Wenn ich also einen Mock verwende, dann deshalb um z.B. Fehlersituation zu erzeugen, die im Normalfall kaum auftreten. Dann teste ich ja nicht den Mock, sondern die Reaktion meines Codes auf die entsprechenden Situation.
Genau. Man braucht so etwas wie eine Spezifikation für die zu testende Methode. Das ist dann das "observable behaviour".
Ein interessanter Ansatz ist das "Test driven design". Da sind die Tests selber die Spezifikation. Und da man die Spezifikation braucht, bevor man eine Methode implementieren kann, schreibt man zuerst den Test. Und dann erst die Methode. Das zwingt einen dazu, sich vorher Gedanken über die Funktionalität und die Grenz- und Sonderfälle zu machen. Habe ich ich aber selbst projektweit auch noch nicht angewendet.
Schon sehr interessant dass die Mehrheit (zumindest von uns älteren Semestern) bei den neuen Konzepten mit viel Augenmaß rangeht. Habe mich in vielen der Schilderungen wiedergefunden
Gibt es hier vielleicht auch jemanden der das Programmieren erst in jüngerer Zeit an der Uni gleich von Grund auf mit den aktuellen Design Patterns und Sprachfeatures gelernt hat und in seiner Freizeit freiwillig ein bisschen "asketische" Programmierung auf dem Cevi oder dergleichen betreibt?
Ein interessanter Ansatz ist das "Test driven design". Da sind die Tests selber die Spezifikation. Und da man die Spezifikation braucht, bevor man eine Methode implementieren kann, schreibt man zuerst den Test. Und dann erst die Methode. Das zwingt einen dazu, sich vorher Gedanken über die Funktionalität und die Grenz- und Sonderfälle zu machen. Habe ich ich aber selbst projektweit auch noch nicht angewendet.
Das ist wahr , aber der Gegenpol von agilen Softwareprojekten. Mit dem Attribut agil lässt sich sehr elegant Bequemlichkeit und leider auch Unfähigkeit zu tiefer und konzentrierter Reflexion der Projektziele verstecken.
Ein interessanter Ansatz ist das "Test driven design". Da sind die Tests selber die Spezifikation. Und da man die Spezifikation braucht, bevor man eine Methode implementieren kann, schreibt man zuerst den Test. Und dann erst die Methode. Das zwingt einen dazu, sich vorher Gedanken über die Funktionalität und die Grenz- und Sonderfälle zu machen. Habe ich ich aber selbst projektweit auch noch nicht angewendet.
Das ist wahr , aber der Gegenpol von agilen Softwareprojekten.
Nein, das ist ein Missverständnis. Man schreibt nicht erstmal sämtliche Tests und dann alle Methoden. Sondern man schreibt für jede Methode erstmal einen Test und dann direkt die Methode. Mit agiler Programmierung kollidiert das überhaupt nicht.
Sondern man schreibt für jede Methode erstmal einen Test und dann direkt die Methode.
Klingt für mich als würde man das Pferd von hinten aufzäumen.
das Pferd von hinten aufzäumen
Malen nach Zahlen - Ein Crashkurs im Test Driven Development
TDD hat schon was, aber das erfordert Disziplin. Vor allem sollte man die Tests nicht nur nach dem Gut-Pfad aufsetzen, sondern gleich die Grenzfälle ausloten.
Und da stösst man IMHO unter anderem auf die Paradeprobleme: Vollständige Anforderungen. Wer hat die schon mal gesehen?
So ein Gutfall ist schnell erklärt, aber was, wenn etwas nicht passt oder schiefläuft?
Ne ganz andere Sache, die mich heutzutage stört, sind diese ganzen Programme, die alle Nase lang durch eine neue Version ersetzt werden. Klassiker sind die Apps bei den Händis, wo in der Regel die Updates sogar vollautomatisch durchgeführt werden. Erst letztens war zum Beispiel der Programmierer meiner E-Mail-App der Meinung, dass ich ab sofort meine Mails mit rosa Rahmenfarbe lesen soll... 
Yeah!
Aber das ist nicht bei den Apps stehen geblieben. Andere Software zieht nach. Firefox zum Beispiel, wo man immer die neuste Version nutzen muss, weil ältere keine Sicherheitsupdates erhalten. Und ständig kommt 'ne neue Version raus, und dann geht wieder irgendwas nicht. Oder Qgis: Da kommt alle vier Monate eine neue Version raus, jede dritte davon mit Longterm-Support (wobei der aber halt auch nur ein Jahr lang andauert). Vermutlich gibt es auch Software, wo der Longterm-Support noch kürzer ausfällt. Wenn das so weitergeht, sind wir demnächst so weit, dass der Longterm-Support schon rum ist, während gerade das automatische Update eingespielt wird... 
TDD hat schon was, aber das erfordert Disziplin. Vor allem sollte man die Tests nicht nur nach dem Gut-Pfad aufsetzen, sondern gleich die Grenzfälle ausloten.
Und da stösst man IMHO unter anderem auf die Paradeprobleme: Vollständige Anforderungen. Wer hat die schon mal gesehen?
Deswegen hatte ich weiter oben was vom Pferd aufzäumen geschrieben.
Firefox zum Beispiel, wo man immer die neuste Version nutzen muss, weil ältere keine Sicherheitsupdates erhalten. Und ständig kommt 'ne neue Version raus, und dann geht wieder irgendwas nicht.
Firefox habe ich jetzt endgültig entfernt, in letzter Zeit ging nicht mal mehr der Kopierenpunkt im Kontextmenu zuverlässig. Was nicht ordentlich funktioniert fliegt. Marktanteil von Firefox ist wohl auch nur noch so 7%.
