Moderne Softwareentwicklung

[freimatz]

Zitat von UntoterGeist:

Das ganze moderne Zeug ist aber irgendwie auch alt. Wann wurden die agilen Prinzipien ausgerufen? Wo beginnt OOP? Das gilt auch für andere Mechaniken, die dann plötzlich hip oder als groovie ausgerufen werden. Das nächste Ding ist halt deep-Learning, was schon jetzt an seine Grenzen gerät.

Was ich meinte ist zum einen: Es ist nicht alles Gold was glänzt und es wird nicht so heiß gegessen wie es gekocht wird.

Und diese ganzen neuen Methoden sind ja schön. Aber in wiefern verbessern oder beschleunigen sie was?

Wann wurden die agilen Prinzipien ausgerufen? Das Agile Manisfest war von Februar 2001.
Wo beginnt OOP? Ist das eine rhetorische Frage?
Natürlich ist nicht alles Gold was glänzt - viele schauen nicht mal nach ob das was glänzt Gold sein könnte. Es wird nicht so heiß gegessen, ja, aber viele essen nicht mal kalt.
Und manche fallen auf der andere Seite des Pferdes wieder runter (bin ich auch schon öfters). Andere steigen erst gar nicht auf.

TDD wurde schon genannt. Ich hatte am Anfang grosse Mühe damit. Inzwischen verwende ich es immer wo ich kann. Wenn es geht habe ich erlebt bin ich schneller fertig und damit schneller beim Kunden. Wenn es nicht geht liegt es meist daran,
1. dass nicht klar ist, was das Ding überhaupt können muss, oder
2. dass der Code an dem ich was ändere gar nicht testbar ist
Beides ist jedoch kein Mangel an TDD selber.

[dummzeuch]

Zitat von jfheins:

Was natürlich nicht passieren darf ist "ich ändere das mal so und so, um dem Bug zu fixen, und dann schau ich welche Tests kaputt sind um die dann auch anzupassen" - das ist sinnfrei und kein TDD.

Auch das kann legitim sein, wenn sich z.B. herausstellt, dass die Tests nicht korrekt die Anforderung wiedergaben oder selbst fehlerhaft waren. Tests sind schließlich auch nur Code und der kann Bugs enthalten.

[Uwe Raabe]

Zitat von dummzeuch:

Auch das kann legitim sein, wenn sich z.B. herausstellt, dass die Tests nicht korrekt die Anforderung wiedergaben oder selbst fehlerhaft waren. Tests sind schließlich auch nur Code und der kann Bugs enthalten.

In dem Fall würde man aber erst die Tests korrigieren und danach, wenn die dann fehlschlagen, den eigentlichen Code.

Leider fallen viele Anwender von TDD in die Rot-Grün-Falle: Der Code wird solange angepasst, bis alle Tests grün sind. Dann geht es schon weiter zum nächsten Bug/Feature/Test. Der TDD-Zyklus ist damit aber noch gar nicht abgeschlossen, denn er besteht aus drei Schritten: write the test - write code to make the test green - refactor the code to make it clean. Der letzte Schritt wird leider viel zu oft übersprungen, da er leider sehr zeit-intensiv ist und einen guten Überblick über das Gesamtprojekt erfordert. Übrigens: Das Postulat schreibe nie mehr Code als nötig ist, um den Test grün zu machen ist hierzu kein Widerspruch. Wir schreiben ja nicht mehr Code, sondern ändern lediglich den vorhandenen. Dabei nutzen wir den grünen Test als Hinweis, daß wir beim Refactoring nichts kaputt gemacht haben.

[dummzeuch]

Zitat von Uwe Raabe:

Zitat von dummzeuch:

Auch das kann legitim sein, wenn sich z.B. herausstellt, dass die Tests nicht korrekt die Anforderung wiedergaben oder selbst fehlerhaft waren. Tests sind schließlich auch nur Code und der kann Bugs enthalten.

In dem Fall würde man aber erst die Tests korrigieren und danach, wenn die dann fehlschlagen, den eigentlichen Code.

Was voraussetzt, dass man weiß, dass die Tests fehlerhaft sind. Wenn man das aber erst sieht, weil sie nach einer Änderung am Code fehlschlagen, dann kann man sie auch erst dann anpassen.

[freimatz]

Äh, Nein.
Wenn man einen Code zu ändern hat, dann sucht man bei TDD erst den dazugehörigen Test und ändert dann erst den. Und danach dann den produktiven Code.

[Uwe Raabe]

Zitat von freimatz:

Äh, Nein.
Wenn man einen Code zu ändern hat, dann sucht man bei TDD erst den dazugehörigen Test und ändert dann erst den. Und danach dann den produktiven Code.

Nein, eben nicht! Es ist auch bei TDD nicht nur üblich, sondern auch erwünscht, daß der Code geändert wird. Der Test ist ja gerade dazu da, daß man diese Änderung durchführen kann, ohne die Funktionalität des Codes zu verändern. Nirgendwo steht, daß man den Code nicht mehr ändern darf, sobald der Test auf grün steht. Das wäre genau das Gegenteil von dem, was man mit TDD erreichen will.

In dem Zusammenhang kann es auch vorkommen, daß ein Test verworfen, ersetzt oder verändert wird - z.B. weil er fehlerhaft ist.

[freimatz]

Hm, vermutlich habe ich Euch falsch verstanden. Ich dachte bei den Änderungen vom Code ginge es Änderungen weil das Programm nicht das tut was der Anwender erwartet.
Dass man den produktiven Code refaktorisiert darf und soll ohne die Tests anzupassen ist für mich klar.

[dummzeuch]

Zitat von freimatz:

Hm, vermutlich habe ich Euch falsch verstanden. Ich dachte bei den Änderungen vom Code ginge es Änderungen weil das Programm nicht das tut was der Anwender erwartet.
Dass man den produktiven Code refaktorisiert darf und soll ohne die Tests anzupassen ist für mich klar.

Es ging darum, dass nach den Anpassungen für eine neue Anforderung (für die zuerst Tests geschrieben wurden) ein anderer Test fehlschlägt und sich dann herausstellt, dass dieser Test fehlerhaft war.

In diesem Fall ist es natürlich korrekt, den Test anzupassen statt den Code so anzupassen, dass zusätzlich zu der neuen Anforderung auch der fehlerhafte Test wieder funktioniert.

twm