Hi,
schließlich gehe ich immer mehr in die Richtung von higher order functions wie map, reduce, currying und so.
... und schon wieder diese Buzzwords, unter denen man sich als traditioneller Softwareentwickler und Programmierer nichts vorstellen kann
Schwierig, ich finde als Programmierer sollte man diese Begriffe zumindest schon mal gehört haben so dass man sie durch kurzes googeln auch nachvollziehen kann, denn das sind Grundbegriffe wenn man sich über funktionales Programmieren unterhalten möchte.
deswegen sagte ich ja: Die Konzepte, die dahinterstecken, sind vermutlich vielen bekannt. Aber eben nicht unter diesen Modebegriffen.
Aus verschiedenen Gründen, einer ist zum Beispiel Testbarkeit von Einzelschritten.
Das ist ein Argument; dafür kann man ja während der Entwicklungsphase diese Schritte isolieren. Im fertigen Code sollte die Granularität aber nicht mehr unbedingt so fein wie möglich sein, sondern nur so fein, wie man das Problem "üblicherweise" auch im Kopf gliedern würde.
Hm moment, wie testest du denn deinen code dass du ihn vor dem ausliefern noch mal umschreiben willst?
Klar, warum nicht? Wenn ich Einzelschritte mal validiert und hinreichend getestet habe, kann ich sie auch wieder zu sinnvollen Einheiten kombinieren, so dass sie auch einen Sinn ergeben.
Natürlich bleiben die Schritte so wie sie sind damit man jeder zeit seine Unittests (oder was man auch immer für ein Testframework benutzt) duchlaufen lassen kann.
Nö. Das mach ich doch nicht immer wieder und wieder, sondern nur während der Entwicklung eines Moduls oder einer Funktion. Irgendwann gilt das Ding als hinreichend getestet und "okay" innerhalb der Spezifikationen.
Ciao,
Martin
Die letzten Worte des Neandertalers:
Möchte doch zu gern wissen, was in der Höhle ist ...
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(