einen wunderschönen guten morgen isabelle drost from erzählt uns heute wie man mit software software testet danke everyone speaking german hier geht

dann machen wir in deutsch weiter warum werde ich was zum thema software testing erzählen erstens software engineer bei elastic search wer von euch erkennt elastic search die hälfte zum zweiten langzeit mitglied der

software foundation dort auch software entwickelt entsprechend auch tests entwickelt co gründer von der patchy mahut dort den spaß gehabt verteilte software die auf herdup läuft testen zu können das möglichst in parallel so

dass die tests auch in einer vernünftigen zeit durchlaufen unabhängig davon gründer der berlin buzzwords kennt jemand berlin buzzwords wer von euch eine ausrede braucht damit der arbeitgeber die reise nach berlin im juni bezahlt die konferenz könnte eine ausrede sein geht um alles zum thema suche skalierbarkeit datenanalyse von kassandra über hat

du bis hin zu elastic search ok wir alle schreiben natürlich tests idealerweise bevor wir den test den kod schreiben hände hoch also ansonsten kriege ich bitte von jedem der keine task schreibt hinterher ein kleines gimmick

wer von euch missen die test coverage es traut sich keiner mehr ich habe vorhin das mikro umgegeben zu denen die die hände hoch halten ich mach das nicht noch mal ihr könnt die hände hoch halten bei wem sind die tests natürlich so dass sie automatisch durchlaufen sie ein irgendjemand

kommt das können die so wenig sein ehrlich also bei denen die jetzt zum schluss noch die hände hoch halten sollte alles alles grün und im bereich und alles total cool sein er findet keine box bei kunden oder nix ok nehmen wir uns mal ein beispiel ganz einfache funktion in java wir

generieren uns random input genau da generieren wir uns einfach in random integer machen mad abs drauf üblicherweise sollte das was rauskommt irgendwie positiv sein haben wir bei apache losin ausprobiert mal da integer

minival urine stopfen kommt am ende eine negativer zahl raus das heißt egal wie wir unsere tests schreiben es ist relativ wahrscheinlich dass irgendeine randbedingung trotzdem noch durchschlüpft das heißt das was wir unseren tests angucken das sieht wenn die realität ein ball ist vermutlich eher so aus ist es eine approximation und es gibt an vielen

stellen so eine ecken und kanten wo man nicht wirklich an die realität rankommen das was wir jetzt probieren wollen bei elastic search ist näher an die realität ranzukommen und zwar nicht indem wir entwicklungszeit da investieren sondern indem wir das automatisiert machen wer vorhin in meinem open source vortrag gewesen ist der hat

gesehen dass ich ein kleines kind habe so kleine kinder sind machen total viel spaß fressen aber auch ziemlich viel zeit das heißt am liebsten möchte ich zu hause alles was so lästige aufgaben sind weg automatisieren unsere familie hat sich dafür entschieden dass so was wie

staubsaugen bitte nicht mehr in unseren alltag gehört es gibt einen kleinen robot der kümmert sich darum und er guckt sich den fußboden an und macht den automatisch sauber genau das gleiche prinzip möchte ich jetzt anwenden auf das schreiben von tests der ganze vortrag basiert auf ist eine bibliothek ist im losin umfeld entstanden die ideen selbst stammen

aber nicht von losin wenn ihr das thema fuzzing kennt wenn ihr das thema intrusion detect automated intrusion detection kennt kommt ja eine klein in kommt ja an ganz ähnliche ideen das heißt es werden daten automatisch

generiert mit denen wird ein service oder ein interface befeuert und dann wird geguckt was kaputt geht in dem fall wollen wir gucken dass das was wo die daten hingehen natürlich ganz bleibt was erlaubt mir carry search carry search gibt mir funktionen mit denen ich zufallszahlen generieren kann hat nichts mit kryptographisch sicheren zufallszahlen zu tun ist

einfach nur java jute random zufallszahl es gibt mir möglichkeiten alle arten und unarten von strings zu generieren es können asky strings sein das können unicode strings sein das können unicode nur printable zeichen sein das können unicode nur nur üblicherweise

in text vorkommende zeichen sein warum gibt es so viele funktionen um strings zu generieren das ganze kommt aus dem losin umfeld losin ist eine text suchmaschine um eine text suchmaschine zu testen brauchen wir jede menge text in unterschiedlichsten facetten es gibt funktionen um daten in nunem spezifischen character set zu generieren

es gibt möglichkeiten tests mit unterschiedlichen locales laufen zu lassen wer von euch hatte schon mal den spaß mci in production und auf dem def rechner unterschiedliche locales debacken zu dürfen war nie so spaßig oder ich hörte wenn man zwei es gehts ich glaube spaßig

ist trotzdem noch ein bisschen anders ok wann macht das sinn so eine randomized test zu schreiben die dinger sind reproduzierbar dank eines spezifischen seeds das heißt die laufen durch immer mit anderen daten in dem moment wo was fehlschlägt habe ich den seed in der

hand und damit exakt die daten unter denen der test fehl geschlagen ist jeder testdurchlauf läuft prinzipiell auf einem anderen datensatz datensatz ich habe support für test timeouts ich habe support für die erkennung von leaking threads ich habe das randomized testing in

apache mahut irgendwann mal aktiviert das erste wo ich reingerannt bin ist das randomized testing mir gesagt hat übrigens da sind schrätz die laufen noch ein paar davon waren testrätts das ist nicht ganz so schlimm sie sind weg in dem moment wo die test jvm weg ist ein paar davon waren echte production test thread leaks die wir gefunden haben

wer von euch hatte schon mal den spaß in seiner test suite einige tests drin zu haben die unglaublich lange laufen eins zwei drei doch einige es gibt einen abgesehen davon dass man die schneller machen sollte gibt es auch die möglichkeit die als nightly zu annotieren so dass sie potenziell nur in sie einlaufen nur unter

bestimmten bedingungen laufen wann nach wann ist es sinnvoll random test data zu verwenden variante eins ist es billiger das resultat zu überprüfen ob es korrekt ist im vergleich dazu das resultat tatsächlich zu berechnen das heißt ich kann zum beispiel

eine sortierfunktion schreiben eingabe sind integers mein eigentlicher kurz sortiert die wie auch immer aufwendig wie auch immer schnell im testcode kann ich dann einfach random daten reinstecken und

prüfen am ende ob das was rauskommt tatsächlich sortiert ist sein fall wo das überprüfen billiger ist als die wirkliche berechnung dessen was als resultat erwartet wird wo es so was noch der fall bei elastic search haben wir letzten sommer sehr viel arbeit investiert um die queries die reingeschickt werden in die interne repräsentation zu

überführen die sehr realisierbar ist wie kann man so was billig testen ich kann roundtrip machen ich sehr realisieren einmal nach jason einmal wieder ins objekt wieder zurück nach jason gucken dass die beiden jason objekte tatsächlich identisch sind jetzt gleiche für die interne repräsentation ich mache einfach einmal den roundtrip und

gucken dass das was sich vorne reinstecken am ende wieder rauskommt wo es noch sinnvoll zufällige daten zu verwenden in dem moment wo ich einen langsameren aber sehr viel einfacheren algorithmus benutzen kann um zum gleichen ergebnis zu kommen hatte ich oft während meiner desortation oder mal während meiner zeit als

wissenschaftlicher mitarbeiter an der hu wir haben machine learning algorithmen implementiert die streckenweise relativ umfangreich waren es war trotzdem hilfreich einen algorithmus zu haben der nach dem gleichen der das gleiche resultat hat aber nicht genauso durch optimiert ist und dann zu gucken dass tatsächlich das gleiche noch

rauskommt wo es noch sinnvoll in dem moment wo ich eine billiger zu rechnende obere oder untergrenze angeben kann das heißt wenn ich eine funktion habe die a und b zusammen addiert dann sollte das resultat was dabei rauskommt entweder so so groß also entweder genauso groß wie die

größte zahl oder größer sein aber definitiv nicht kleiner sonst habe ich irgendwas falsch gemacht gucken wir uns das im java code an das ist ganz normaler j unit code wir haben ganz normal die testannotation carry search kommt mit einer repeat annotation dadurch dass wir immer mit

anderen testtaten das ganze initialisieren können wir auch sagen ok wir lassen das diesen test 100 mal durchlaufen ist an der stelle sinnvoll weil wir halt immer an reingabendaten haben wir haben hier die möglichkeit eine länge zu generieren indem wir eine funktion aufrufen random in between können wir an der stelle so aufrufen weil wir

weiter oben in der die testklasse haben von random test erben lassen deswegen haben wir die funktion da drin können hier wieder random short aufrufen machen hier ein array sort und die assertion guckt dann einfach nur ob das resultat tatsächlich sortiert ist das heißt das was carry search mir gibt ist die repeat annotation mit den iterationen plus

die zufällige datengenerierung hier haben wir noch ein paar mehr annotationen drin wir haben hier an der stelle straddlek detection drin wir können carry search sagen ok wenn du schon

mal strats detektierst die noch lebendig sind warte mal bitte so und so viele millisekunden bis du mir tatsächlich sagst da sind noch strats übrig so dass sie potenziell noch zeit haben aufzuräumen bevor der hammer zuschlägt was haben wir an der stelle noch wenn wir jetzt die ganzen tests haben durchlaufen lassen für die leute

übrigens die dahinten noch stehen hier sind vorne noch plätze speaker weiß nicht gerne reinkommen so wenn wir uns jetzt vorstellen wir lassen das

ganze durchlaufen über nacht über mehrere iterationen dann kann es durchaus sein dass wir ein paar von den edge cases plötzlich treffen wir wollen aber eigentlich sicherstellen dass genau dieser edge case vielleicht in der nächsten implementierung sehr viel eher ausgeführt wird was wir

für die diesen anwendungsfall haben ist dass wir hier ein sieht festsetzen können und können sagen ok wenn der testdurchlauf läuft diesen sieht möchte ich immer mit abdecken und zum beispiel eine geo applikation vorstellen dann wollen wir zum beispiel sowas wie null merit ja meridian oder tagesgrenzen oder notpol und südpol in jedem testdurchlauf

mit durchlaufen lassen wenn der irgendwann mal schief gegangen ist sowas würden wir an der stelle mit dem sieht festsetzen und der iterations haben wir jetzt hier haben wir es drin die iterationen entsprechend hochsetzen so dass mehr als nur dieser edge case durchgelaufen wird wie sieht das in der idee aus es gibt

entsprechende eclipse plugins die generieren dann hier unter tests so dass man die wieder ausführen kann ähnliches gibt es für intelliJ die siehts kann man mit gradle maven what have you genauso wieder reinstopfen das ist das gradle beispiel das ist aus dem elastic build da wird einfach nur der test sieht mit reingeben das heißt für

irgendwas was in sie schief gegangen ist kann man den test sieht mit reingeben und den entsprechenden aufruf reproduzieren so jetzt haben wir das auf dem unit testlevel wir haben an der stelle also zufälligen input

mit einem fixen sieht um den suchraum zu vergrößern wir haben sie aufgesetzt lassen die tester durchlaufen um die coverage entsprechend zu erhöhen können wir noch ein stück weitergehen bisher haben wir quasi nur aufs unit testlevel geguckt können wir mehr

machen naja wenn man den verteilte systemen haben so wie es elastic search eins ist können wir zum beispiel die anzahl der knoten variieren auf dem unsere tests laufen wir können die anzahl der prozesse auf den knoten variieren wir können anfangen jwm optimierungs parameter zu variieren wir können verschiedene jwm distributionen nutzen

um zu testen wer macht so ein quatsch naja losin solar mindestens elastic search tun das uns läuft das folgendermaßen pro commit läuft ein smoke test drüber der guckt dass das ganze überhaupt baut dann die

aber unit und integration tests und zum schluss haben wir rest tests die tatsächlich gegebenen installationen auf die installation drauf gucken abschicken daten indizieren und gucken ob das was rauskommt das ist was ich erwarte warum machen wir das auch auf restebene wir wollen sich erstellen dass alle unsere clients über eine stabile rest schnitt stelle mit uns kommunizieren können deswegen gucken wir auch da dass die API

stimmt das ganze läuft sowohl in der cloud als auch auf so genannten bare metal hetzner server einfach nur ganz normal installiert läuft auf unterschiedlichen plattformen wir unterstützen windows und du debian centers es gibt eine support matrix die support das was in der support

matrix angeklickt ist ist genau das auf dem wir unsere tests laufen lassen jenkins ist public das heißt ihr könnt auch hergehen und euch die installation entsprechend angucken und die testläufer angucken inklusive allen bilds die ich und meine kollegen gebrochen haben wir gehen noch ein schritt weiter wir garantieren nämlich backwards

zwischen spezifischen versionen das heißt wir gehen auch her lassen die gleichen tests auf dem mix cluster laufen und gucken bzw lassen tests von der neuen version auch gegen eine alte version laufen so alles

so alle total happy von den entwicklern bei uns nicht ganz wenn wir sowas ausrollen dann hat das eine gewisse implication auf die entwicklungskultur was wir brauchen ist eine entwicklungskultur in der test fehler möglichst schnell gefixt werden weil nix ist schlimmer als in

zii zu haben was nennt sich flickering ist nämlich mal grün mal rot mal grün mal rot mal grün mal rot weil in dem moment wo ich einchecke und das war vorher schon ständig flickering habe ich keine ahnung ob ich das ding kaputt gemacht hat das heißt das was der impact auf die entwickler ist auf das team ist ist das über die zeit keiner sich mehr um sie kümmern wird zwei geschichten dazu zwei extreme

extrem nummer eins so apache con 2009 waren wir zum abendessen mit den losin kommentaren irgendjemand sieht sein handy guckt darauf guckt relativ verwirrt bild kaputt die unterhalten sich so es

stellt sich schnell raus wer den bild kaputt gemacht hat es war als gemeint kein bier mehr für genau den entwickler ich nenne den namen jetzt nicht stellte sich tatsächlich raus nachdem das abendessen vorbei war garantiert schon mit der nacht durch hat der typ sein den bild gefixt man das ist das noch wirklich balance also ich will mindestens das andere leute

das tun das andere extrem bei einem ex arbeitgeber von mir der bild läuft über stunden nicht den morgens ansetzt dann sind alle läufe garantiert irgendwann durch wenn ich schon feierabend habe wozu führt das keiner kümmert sich um den bild keiner checkt mehr ein weil jeder hat

angst dass er irgendwas kaputt macht ist also auch nicht gerade das was wir wollen das was wir wollen ist dass der bild relativ schnell durchläuft sich zügig feedback bekommen sich das ganze team verantwortlich fehlt für das was da passiert warum ist es mit dem verantwortlich vielen bei random test so ein problem üblicherweise wenn ihr jetzt

ausgerollt habt kommt das tutor läuft durch was ist kaputt naja vermutlich was der letzte der eingecheckt hat das heißt er geht her und guckt in dem set ab ganz durchaus sein dass letzte woche oder vor letzte woche jemand quatsch eingecheckt hat irgendeine boundary condition nicht überprüft hat und wochen später der test festschlägt das heißt ich brauche team übergreifend eine

verantwortlichkeit dafür dass der bild möglichst grün ist in dem moment wobei elastics randomized testing eingeschaltet wurde hat wochen und monate getauert bis der bild einigermaßen stabil war stabil heißt alles was schief geht sind nur noch fehler die nicht reproduzierbar

sind jedenfalls nicht einfach irgendwelche race conditions irgendwelche timing conditions et cetera im worst case irgendwelche jwm box ja auch so was finden wir das heißt wir brauchen eine gewisse disziplin um wenigstens reproduzierbare fehler zu fixen

wir brauchen ein commitment of a management dass das ganze zeug gefixt wird wir brauchen eine disziplin damit tests möglichst einfach reproduzieren so race conditions im test sind nicht so cool wir hatten auch eine überprüfung folgendermaßen testdaten gehen rein entwickler

überprüft dass das ergebnis nicht sortiert ist naja die sortierung ist zufällig wenn wir 1000 affen 100.000 affen haben die da auf dem keyboard klimpern dann wird irgendein output irgendwann mal sortiert sein nie so gut das heißt der test musste irgendwie anders formuliert sein das heißt wir müssen den entwicklern auch beibringen wie wir

test schreiben die einfache produzieren auch in diesem set up es kann durchaus vorkommen wenn wir das so durchziehen dass wir box in unserer umgebung finden ich habe schon den fall erwähnt von jwm box

ihr könnt in die losin-geschichte mal reingucken es gibt durchaus viele jwm box die dort gefunden wurden in das ex-server und auch losin empfiehlt spezifische jwm versionen bis runter zur meiner version weil in vielen versionen oder in anderen versionen box gefunden wurden die zu datenverlust führen können eine warnung renomize testing ist keine

sogenannte silver bullet ist großartig um dass den test sind der test suite hinzuzufügen er werdet aber trotzdem noch ganz normale konventionelle traditionelle unit tests brauchen die bekannte boundary

conditions überprüfen er werdet feste rennung siehts hinzufügen um gefundene boundary conditions abzuprüfen wenn ihr rennung testing

einführt braucht ihr eine gewisse disziplin um die test zu fixen dieses fixen von den tests kostet natürlich zeit im umkehrschluss kosten diese fixes natürlich auch geld das heißt ich muss mir am anfang überlegen wie breit will ich das ganze aufstellen will ich wirklich

alle will ich wirklich auf windows auf debian auf ubuntu und auf fedora laufen oder weiß ich dass meine applikation in produktion nur auf ganz bestimmten system laufen wird wenn ich das weiß dass es sowieso nur in dem bestimmten umfeld laufen wird kann es durchaus sinnvoll sein die

entscheidung zu treffen betriebssystem war ihr euch nicht genauso mit locale wenn ich weiß dass ich nur in eine bestimmte locale reingebläuen möchte dann kann es durchaus sinnvoll sein sich eher darum zu kümmern dass alle mann die gleiche locale konfiguriert haben und gute das heißt für uns macht es sinn diese komplette renomisierung

durchzuziehen weil wir ein produkt sind beziehungsweise auch ein open source projekt sind was in unterschiedlichsten umgebungen eingesetzt wird es gibt leute die installieren die lässt sich auf ihre windows maschine nur lokal mit ganz wenig daten es gibt leute die machen das mit ganz vielen daten es gibt leute die machen das mit unterschiedlichsten

jwm versionen es gibt leute die machen das auf hunderten von wir wollen natürlich sich erstellen dass unsere support leute möglichst wenige wirkliche box bei kunden entdecken wir wollen sich erstellen dass die nutzer unserer software möglichst wenig datenverlust haben aufgrund von box die vermeidbar gewesen werden deswegen stellen wir

uns so breit auf es kann durchaus sein dass das in dem anderen projekt set-up reicht wenn man sich sehr viel weniger breit aufstellt der vortrag ist extra kurz gehalten dass ich von euch noch fragen bekommen wenn ich von euch keine bekommen habe ich ein paar hier für euch fragen bezüglich des coverage ist das reines code coverage oder das

functional coverage nur code coverage weil sonst könnte man ja auf die seats verzichten und anhand des functional coverages quasi das rückgekoppelt machen wie es jetzt zum beispiel im hardware entwurf gemacht wird ist das noch geplant dass irgendwie zu machen oder ist macht es keinen sinn oder in der stelle also was einige was ein oder

zwei entwickler mal ausprobiert haben ist so was wie mutation testing zu machen weiß nicht ob dir das was sagt ich gehe her mutiere zufällig den source code und gucken ob tatsächlich meine tests fehlen schlagen ist aber bis jetzt noch nicht durchgezogen durch durchgesickert also jetzt ist es

wirklich reine code coverage und bis jetzt finden wir noch genug gab's bei code coverage uns um alles andere noch kennen man weiß halt nie von wo man gekommen ist man weiß halt bloß dass man sehen wir mal wegen der zeile war also code coverage ist nett in dem moment wo du siehst dass du null coverage hast hast du ein problem in dem moment wo du 100 prozent coverage hast kann es sein dass alles gut ist es kann aber auch

sein dass deine tests einfach mal nur durchlaufen du hast ja erwähnt dass man auch mit annotation sagen kann es soll genau der in der seat laufen und hat es als beispiel dafür den null meretian genannt nun scheint

mir es eher unwahrscheinlich dass ich den seat für den null meretian finde oder kann man das irgendwie so von vornherein würdest du natürlich spezifische tests für diese edge cases schreiben aber folgende folgende anekdote dazu ich habe für eine firma gearbeitet die maps produkt hat man sollte annehmen dass der code total super getestet ist ich habe

einfach nur eine funktion rausgesucht keine ahnung was die gemacht hat irgendwie entfernungen berechnet oder was weiß ich hab dort randomized testing eingeführt zufälliger latitude longitude wert siehe da dass diese funktion nach ein paar tagen hat sich rausgestellt die funktion

hatte bei der dateline ein problem in dem moment wo du würdest das mit dem sieht festsetzen entweder übersetzt du das was du gefunden hast in expliziten test oder du nimmst den sieht und sagst ok das ist ein edge kisten habe ich an dem moment nicht bedacht und hängst den sieht oben an den test ran das ist also nichts was du von vornherein

machst in dem moment wo du jetzt den quelco schreibst und denkst aha ich möchte den null meretian oder die dateline testen würde ich zumindest das explizit hinschreiben und alles ist gut in dem moment wo die tests aber schon ein paar tage durchgelaufen sind und du hast festgestellt oder es ein problematischer sieht hast du die

ich pack den sieht oben ran und alles ist gut jetzt nichts wo du aktiv nach dem siehts suchst um genau diesen test zu machen das nie weitere fragen ich

könnte mir vorstellen dass die versuchung ziemlich groß ist einfach noch mal auf rie ranzudrücken wenn man da so ein fehl geschlagen test hat wie seid ihr damit umgegangen dass da nicht der entwickler einfach sagt scheiß drauf ich krieg einfach noch mal und dann läuft kannst du gerne machen übermorgen nacht wird das ding in sie ein fehlschlagen und

du hast wieder jemanden der an deine tür klopft noch mehr fragen zu den verschiedenen betriebssystem lockt ihr dann dementsprechend was für eine version progama auf dem betriebstem laufen ansonsten wird euch ein patch alle tests rot werden lassen also das wird

drauf aufgepasst nicht das heißt hier es war es doch bestimmt du hast den letzten kommet nee es ist wirklich so in dem also der der den letzten kommet gemacht hat der passt üblicherweise auf wie der bild hinterher aussieht ob der grün aussieht wenn der irgendwann dann rot

aussieht gibt es bei uns wir sind relativ viele entwickler pro tag ein der für sogenannte testrayage verantwortlich ist und der verantwortlich dafür ist dass sich um diesen fehler gekümmert wird was macht der der geht nicht einfach nur zum letzten kommeter sondern der guckt sich an wer hat in dem test was gemacht wer hat in dem quellcode was gemacht der guckt sich den quellcode genau an der

nach ob sich an der installation was geändert hat mein schmerz ist dass ich oft meine runtime test auf spezial hat weil machen muss zum beispiel auf gpu so ähnlichem brutalisierte die irgendwie oder wer die überhaupt support das ist wir alle bis auf das was auf hetzner läuft ist alles in der

cloud ist alles durch virtualisiert also ohne jetzt werbung machen zu wollen aws cloud ganz traditionell einfach nur jetzt die zwei instanzen hoch inzwischen auch durchpapiert ist ja ich habe auch eine frage und zwar das

waren jetzt nur ziemlich simple datentypen also wie ist denn das wenn man zufällige objekte erstellen will oder händisch genau okay also da unterstützt dann das framework nicht mehr händisch du kannst im elastic search 3 mal nach den query bilder tests gucken das sind sachen

kollega und ich geschrieben haben es wird schnell eklig noch mehr fragen mich würde mal interessieren wenn du meinst es gibt dann jemand der ist verantwortlich der guckt wer hat als letztes den test und die getesteten

funktionen angefasst gibt es da nicht als letztes sondern überhaupt aber überhaupt da gibt es dann tooling was sagt dieser test hat gerade diese fahre genommen und daher zeige ich an die und die personen haben als noch nicht okay das ist vielleicht noch ein schönes projekt mal für später kann sein das problem hier ist dass es nicht der letzte gewesen sein muss

es kann durchaus sein dass vor zehn wochen jemand was eingecheckt hat der irgendein edge case nicht beachtet hat es kann auch sein dass es irgendein seiteneffekt ist aber du hast recht das ist eine herangehensweise um das noch zu vereinfachen das was erzählt hat es

so ein bisschen idealisiert für projekte die entwickelt werden aber wie steht sein mit legacy projekten wo einfach die datenstruktur und die architektur das nicht hergeben ja so mal eben ein unit test zu

schreiben wie geht ihr damit um habt ihr das problem oder man sollte meinen wir haben das problem nicht den flüchen meiner kollegen nach zu urteilen ich weiß nicht ob du den xkcd kennst mit der tür mit den beiden türen wie man rauskriegt ob den kod review für guten kod oder schlechten haben wir auch bei uns auch wenn das wenn wenn der kod nicht

entsprechend alt ist ich kann dir nur den hinweis geben stück für stück refakturieren verbessern auseinandernehmen es gibt ein schönes buch nennt sich working effectively with legacy code was darum geht einfach dependencies auseinander zu ziehen anders geht es nicht wir was du dafür brauchst meiner meinung nach ist jede menge bei in von der

management seite business seite weil das kostet zeit das und die tiefgreifenden refaktorings das heißt immer so naja das machst du doch nebenbei aber tiefgreifende architekturelle änderungen machst du nicht mal eben nebenbei dafür brauchst du zeit

das query refactoring was wir gemacht haben es ging um 50 queries plus aggregations plus sorting ungefähr ein halbes jahr drei leute das ist nicht nebenbei dafür brauchst du business by in es gibt netten blog artikel zum thema wie kriegst du das bei in üblicher weise wenn neue

features reinkommen von management kann sein dass dieses feature einen kodfahrt betrifft der zu refektern ist was das ganze teuer macht versuche so sichtbar wie möglich zu machen was die wirklichen kosten sind und wo sie herkommen worauf ich genau es heute ist mal

angenommen das management und alle beteiligten spielen mithalten und hast ja trotzdem das problem dass du kod hast den du nicht testen kannst und den ziehst du auseinander ohne einen back abzuhaben und ohne netz und doppelten boden arbeitest du halt in dem moment das was wir an unserer stelle gemacht haben ist sehr hochlevelige test zu schreiben

wirklich daten rein stecken und gucken dass das was am ende rauskommt noch das ist was vorher rauskommt also zum beispiel rest test okay das macht noch mehr fragen wünsche anregungen nein dann danke ich