Moderne Softwareentwicklung

[Gausi]

Zum Thema Blockchain: Gibt es überhaupt jemanden, der diesen Begriff ernsthaft verwendet, also nicht ironisch? D.h. abgesehen von

• Crypto-Währungs-Jüngern, also BitCoin und allen anderen, die alles noch "besser" machen als BitCoin, um auch was von dem Schneeballsystem abgreifen zu können?
• Politiker, die schlaue Sachen sagen wollen, um zu verbergen, dass sie bei "Browser" an das Ding an der Dusche denken, wo das Wasser rausbraust?
• hippe Startup-Unternehmen, die damit übereifrigen Investoren Geld aus der Tasche ziehen wollen?
• Grundlagen-Forschern, die sich damit beschäftigen

Als kleine Anekdote: Zur Vorbereitung zu meiner Doktorprüfung (theoretische Informatik, Bereich Algorithmen und Datenstrukturen) meinte mein Prof auf dem Weg in die Mensa, ich solle unbedingt was zu Blockchain lernen. Wir haben dann beide kurz gelacht, kurz noch über "Cyber machine learning in der Cloud" gefaselt, und das Thema war vom Tisch.

Das Thema Blockchain ist sicherlich nicht uninteressant, gerade auch als Forschungsbereich. Es hat aber in der Praxis längst nicht den Einfluss oder Nutzen, der seitens Medien und Politik herbeifantasiert wird, und wird es imho auch nie haben. Ich vergleiche das gerne mit der Verwendung der Zahl "2000" in den 80er und 90er Jahren. Was früher die "Wunderharke 2000" war, ist aktuell die "Cyberharke Blockchain".

Ansonsten zur Auflistung: Da werden ja einige Konzepte durcheinander gewürfelt. Clean Code z.B. ist sicherlich auch mit prozeduraler Programmierung möglich, und Unit-Tests geht bestimmt auch irgendwie bei Assembler. Dinge wie MVVM beschreiben ja im Wesentlichen die Trennung von Logik und Darstellung (stark vereinfacht). Dass das jemand nicht beachtet, merkt man dann bei Anfängerfragen im Forum, die so anfangen: "Wie kann ich machen, dass X passiert, wenn man auf einen Button klickt ...?"

[TiGü]

Passend zu den ersten Teil von Gausis Post:

Fefes neuster Vortrag zum Thema Hype-Tech:

http://ptrace.fefe.de/hype2/#0

Viel Spaß!

[dummzeuch]

Zitat von Gausi:

Zum Thema Blockchain: Gibt es überhaupt jemanden, der diesen Begriff ernsthaft verwendet, also nicht ironisch?

Es war also trotz fehlender Ironie-Tags erkennbar? Ich machte mir schon Sorgen. Und dabei habe ich sogar extra noch AI als Prefix verwendet.

[p80286]

Zitat von dummzeuch:

Es war also trotz fehlender Ironie-Tags erkennbar? Ich machte mir schon Sorgen. Und dabei habe ich sogar extra noch AI als Prefix verwendet.

Es gibt so viele Wortgeklingel-Säue die durchs Dorf getrieben werden, da hat auch daß mich nicht gewundert.


Gruß
K-H

[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?

[p80286]

Zitat von UntoterGeist:

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

Naja ich hab versucht mich mit dem "TestDriven" auseinander zu setzen. Letztlich geht es darum sich im Vorfeld darüber klar zu werden was schief gehen kann, und dementsprechend daran orientiert das eigentliche Programm zu schreiben.

Wie sagte mal ein Kollege vor ein paar Jahren "Nur Vollidioten glauben, daß alles so läuft wie der Programmierer es wünscht. Grundsätzlich mußt Du vom schlimmsten ausgehen und Dein Programm daran orientieren."

Der Spruch ist älter als Testdriven und OOP zusammen.

Gruß
K-H

[jfheins]

Moin

Zitat von p80286:

Zitat von UntoterGeist:

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

Naja ich hab versucht mich mit dem "TestDriven" auseinander zu setzen. Letztlich geht es darum sich im Vorfeld darüber klar zu werden was schief gehen kann, und dementsprechend daran orientiert das eigentliche Programm zu schreiben.

Halte ich so für unrichtig.

Test driven sagt ja erstmal, dass die die Anforderungen die du bekommt erst in einen Test gießen sollst und dann umsetzen.
Ergebnis sollte ein Programm sein, dass die Business-Logik nicht nur gemäß den Anforderungen umsetzt, sondern dies (mehr oder weniger beweisbar) tut. Alle Tests grün = alle Anforderungen erfüllt.

Der Benefit ist nun, dass du nach Änderungen (Refactorings, Features, Bugfixes) die Tests laufen lassen kannst und relativ sicher sein kannst, dass die keine neuen Bugs erzeugt hast. Wenn doch, dann war das entweder eine Spezifikationslücke (und deshalb gab es keinen Test) oder der Test hat die Spec nicht ausreichend abgedeckt.

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.

[p80286]

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.

Nun, gerade um solche cleveren Lösungen zu unterbinden werden wohl Methoden wie TDD propagiert. Das diese dann vom Hilfsmitel zur Quasireligion mutieren nunja.....

Gruß
K-H

[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.

[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.