WEBVTT 00:00:18.080 --> 00:00:23.040 Hallo und herzlich willkommen zu Binärgebitter Talk West Coast Edition. 00:00:23.520 --> 00:00:26.480 Ich bin der Flighty aus dem schönen Seattle. 00:00:26.640 --> 00:00:28.560 Bei mir ist unter anderem auch der Markt. 00:00:28.800 --> 00:00:31.440 Guten Tag aus dem schönen Menlo Park. 00:00:31.680 --> 00:00:33.120 Ja, ich bin der Lukas. 00:00:33.360 --> 00:00:35.520 Ich sende aus Stuttgart. 00:00:35.760 --> 00:00:39.520 Ist jetzt nicht so ganz die West Coast, aber ich hoffe, das wird vollziehen. 00:00:40.800 --> 00:00:41.680 Westdeutschland. 00:00:41.840 --> 00:00:47.200 Westdeutschland ist auch quasi eine Küste. 00:00:48.000 --> 00:00:49.600 Norddeutschland hat eine Norddeutsch-Küste. 00:00:50.480 --> 00:00:53.680 Aber das ist ja das Schöne, man ist immer im Westen von irgendwas. 00:00:56.080 --> 00:00:59.600 Ja, steht gerade die Neckar-Küste, würde ich behaupten. 00:01:00.880 --> 00:01:02.160 Könnte man so sagen, ja. 00:01:02.400 --> 00:01:04.240 Da gibt es bestimmt auch eine Küste im Westen. 00:01:04.880 --> 00:01:05.680 Stuttgarter Westen. 00:01:05.840 --> 00:01:06.480 Ja, richtig. 00:01:07.040 --> 00:01:07.760 Herrlich. 00:01:08.080 --> 00:01:13.440 Ja, zudem lebt der Lukas ja quasi in unserer Zeitzone und schläft zu komischen Zeiten, 00:01:13.520 --> 00:01:16.400 deswegen ist er jetzt halt auch wach, während uns alle unsere Hörer. 00:01:16.880 --> 00:01:21.520 Also ich schätze jetzt einfach mal über einen Kamm, ich behaupte jetzt einfach mal, 00:01:21.600 --> 00:01:23.200 alle unsere Hörer schlafen bereits. 00:01:24.960 --> 00:01:26.640 Wobei es ist, wie viel? 00:01:26.880 --> 00:01:27.360 Elf Uhr? 00:01:27.680 --> 00:01:28.320 Ja, so ungefähr. 00:01:28.400 --> 00:01:30.400 Ich glaube, das ist schon noch der ein oder andere wach. 00:01:34.480 --> 00:01:38.800 Aber das Gute ist, dass nach elf ist, können wir jetzt ja auch über Schmuddelkram reden. 00:01:39.120 --> 00:01:44.880 Alles geht, ohne dass es ja die Landespodcast, 00:01:44.960 --> 00:01:48.160 äh, das Landespastministerium auflauert. 00:01:50.080 --> 00:01:52.240 Das Landespodcastministerium. 00:01:52.640 --> 00:01:55.280 Ich habe keine Ahnung, wie ich da jetzt eine Überleitung hinkriege, 00:01:55.360 --> 00:02:01.040 aber in so einem Schmuddelkram, wir hatten scheinbar auf der letzten Sendung auch irgendwie ein blödes Echo 00:02:01.040 --> 00:02:07.520 auf der Aufnahme, was ungünstigen Zuständen geschuldet ist. 00:02:07.680 --> 00:02:14.240 Und zwar aus irgendwelchen Gründen hat die Aufnahme von Marc auch noch teilweise meine 00:02:14.240 --> 00:02:18.720 Stimme mit aufgenommen und wir sind überhaupt nicht sicher, wie das technisch überhaupt möglich ist, 00:02:18.800 --> 00:02:19.760 aber es war so. 00:02:20.000 --> 00:02:24.640 Und wir hatten noch ein zweites Problem, dass unsere Tonspuren dermaßen auseinandergelaufen sind, 00:02:24.800 --> 00:02:29.600 dass nach dieser über dreistündigen Sendung die eine Tonspur, 00:02:29.680 --> 00:02:35.520 ich glaube, sechs oder sieben Sekunden länger war als die andere, was das ganze Schneiden dann mehr oder 00:02:35.520 --> 00:02:39.200 weniger sehr anstrengend gemacht hat und sehr lange gedauert hat. 00:02:39.440 --> 00:02:45.680 Wir hatten dann die Hoffnung, dass dieses Orthonic Crossgate-Feature das Echo größtenteils eliminieren kann, 00:02:45.760 --> 00:02:47.520 was es scheinbar auch getan hat. 00:02:47.920 --> 00:02:52.960 Wir haben trotzdem noch Feedback bekommen, dass es irgendwie teilweise ein Echo gibt. 00:02:53.120 --> 00:02:55.760 Wir entschuldigen uns hierfür damit dafür. 00:02:57.760 --> 00:02:59.440 Wir versuchen unser Setup irgendwie ein bisschen. 00:02:59.760 --> 00:03:04.080 Ja, wir garantieren nichts, aber wir versuchen daran zu arbeiten, dass es besser wird. 00:03:04.240 --> 00:03:04.640 Richtig. 00:03:05.120 --> 00:03:10.880 Wir werden dann sehen, welche schrecklichen Audio-Artefakte in dieser Folge da sein werden. 00:03:11.040 --> 00:03:15.360 Es ist quasi wie ein Weihnachtskalender, nur dass statt Schokolade Audio-Artefakte gibt. 00:03:15.680 --> 00:03:16.400 Ja, natürlich. 00:03:16.480 --> 00:03:21.680 Also ich meine, man weiß, vielleicht wollen die Hörer auch nicht unbedingt genau wissen, was sie bekommen. 00:03:21.760 --> 00:03:25.200 Vielleicht mögen die auch, das sind nämlich Artisanal Artifacts. 00:03:25.520 --> 00:03:28.160 Richtig, das ist ein handgeklöppelter Podcast. 00:03:28.640 --> 00:03:32.960 Ja, genau, das ist handgekloppelt, äh, handgekloppelte Bits und darum mögen. 00:03:33.200 --> 00:03:34.960 Vielleicht mögen das ja die Hörer auch. 00:03:35.360 --> 00:03:37.760 Solltet ihr es mögen, könnt ihr es uns ja wissen lassen. 00:03:40.000 --> 00:03:46.480 Ja, ansonsten haben wir jetzt gar nicht so viel und könnten eigentlich direkt ins Thema 00:03:46.480 --> 00:03:47.440 einspringen. 00:03:48.080 --> 00:03:49.440 Oho, ein Thema. 00:03:50.080 --> 00:03:54.000 Ja, also wir haben ausnahmsweise haben wir, keine Ahnung, ich weiß jetzt gar nicht, 00:03:54.080 --> 00:03:57.120 ob ausnahmsweise überhaupt der richtige Ausdruck ist, weil das erst die zweite Sendung ist, 00:03:57.200 --> 00:03:58.240 die wir hier so machen. 00:03:58.720 --> 00:04:01.600 Wir haben ein Thema gefunden, über das wir reden könnten. 00:04:01.680 --> 00:04:04.400 Und darum haben wir unter anderem auch den Lukas eingeladen. 00:04:04.480 --> 00:04:06.080 Es geht nämlich um Code-Reviews. 00:04:08.240 --> 00:04:08.960 Richtig, Lukas. 00:04:09.840 --> 00:04:11.440 Review ist sogar den Fly-Design-Code. 00:04:11.520 --> 00:04:14.560 Das ist einer der Hauptgründe, warum ich jetzt hier bin, um einfach euch mal zu erzählen, 00:04:14.640 --> 00:04:16.560 was für schlimm Code der FlyDy schreibt. 00:04:16.640 --> 00:04:21.600 Nee, das ist tatsächlich nicht so ganz wahr, aber tatsächlich sind der FlyDy und ich ja Kollegen und deswegen 00:04:21.600 --> 00:04:24.480 reviewen wir unseren Code gegenseitig. 00:04:24.640 --> 00:04:31.360 Und irgendwie haben wir in den letzten Wochen immer öfter anders 00:04:31.360 --> 00:04:36.560 verspürt, über Code-Review an sich zu sprechen und irgendwie, 00:04:36.880 --> 00:04:43.520 weil es da bei uns halt firmen intern so größere und kleinere Problemchen gab und das war irgendwie ein ganz 00:04:43.520 --> 00:04:47.600 guter Grund, da mal so auf einem bisschen einem größeren Level drüber nachzudenken. 00:04:47.680 --> 00:04:52.880 Und dann, wie das halt so ist, wenn man mal anfängt, dann läuft es irgendwie und ja. 00:04:54.480 --> 00:04:56.080 Es ist leicht eskaliert. 00:04:58.000 --> 00:05:04.800 Also das ist im positiven Sinne eskaliert in der Form von, wir wollten mal eine kurze Guideline schreiben für 00:05:05.760 --> 00:05:11.120 was können denn Leute tun, damit ihr Code schneller durchs Review kommt und das ist dann irgendwie so ein 00:05:11.120 --> 00:05:16.880 2300-Worte-Text geworden, der so von vorne bis hinten mal versucht 00:05:17.360 --> 00:05:20.960 darzustellen, wie denn ein gutes Review auszusehen hat. 00:05:21.760 --> 00:05:27.040 Ich hoffe, ich kann den Text, der da daraus entstanden ist, irgendwann mal hier verlinken. 00:05:27.120 --> 00:05:31.280 Ich muss das erst nochmal mit Management abklären, da das während der Arbeitszeit passiert ist, 00:05:31.360 --> 00:05:33.280 ob ich das irgendwo mal veröffentlichen darf. 00:05:34.000 --> 00:05:39.680 Ansonsten können wir halt einfach mal so über unsere Dinge reden, die uns dabei aufgefallen sind oder Dinge, 00:05:39.840 --> 00:05:46.160 Problemchen, die uns da so in unserem Arbeitsalltag begegnet sind und so weiter und so fort. 00:05:46.400 --> 00:05:52.160 Kann einer von euch von euch einfach mal erklären, also wir haben ja unsere Hörer sind ja zur Hälfte Leute, 00:05:52.240 --> 00:05:57.760 die Haskell programmieren, wo du ja keine Code-Views brauchst, weil der Compiler das ja alles regelt, 00:05:57.840 --> 00:06:01.680 und zur anderen Hälfte OpenSSL-Entwickler, die auch keine Code-Views machen, 00:06:02.480 --> 00:06:03.280 aus Gründen. 00:06:03.680 --> 00:06:04.560 Aus Sicherheitsgründen. 00:06:07.360 --> 00:06:10.720 Richtig, es ist geheim, deswegen darf man da auch nicht so drauf schauen. 00:06:10.800 --> 00:06:14.000 Nee, kann einer von euch mal erklären, was denn ein Code Review ist? 00:06:15.920 --> 00:06:20.080 Ja, ich weiß nicht, ob ich das jetzt so aus dem Stand definieren kann, 00:06:20.320 --> 00:06:25.600 aber also wir so als Softwareentwickler, wir haben ja als Hauptaufgabe und das, 00:06:25.760 --> 00:06:31.520 wofür wir bezahlt werden, ist zu einem großen Teil Source-Code zu produzieren. 00:06:31.920 --> 00:06:38.480 Und weil auch der gemeine Softwareentwickler nun leider nicht perfekt und fehlerfrei ist, 00:06:39.760 --> 00:06:46.480 macht es Sinn, diesen Code nicht einfach so in ein Produkt einzufügen und in die Welt 00:06:46.480 --> 00:06:51.600 hinaus zu schicken, sondern da sollte vielleicht nochmal jemand vorher drüber gucken. 00:06:51.920 --> 00:06:57.360 Und diesen Prozess, den kann man jetzt entweder so locker flockig beschreiben, 00:06:57.520 --> 00:07:02.400 wie ich das mache, oder man definiert den eben ein bisschen strukturierter vielleicht. 00:07:02.640 --> 00:07:09.440 Und da gibt es, glaube ich, so in der Softwareentwicklungsbranche verschiedenste 00:07:09.440 --> 00:07:14.080 Formen, Farben und Ausprägungen, wie Code-Review eigentlich genau aussieht. 00:07:14.240 --> 00:07:18.480 Aber ich würde sagen, so vom Grundprinzip ist es, jemand schreibt Code, 00:07:18.800 --> 00:07:25.120 tut den irgendwo hin, wo ihn andere Leute sehen können und die anderen Leute gucken ihn an und sagen Daumen 00:07:25.120 --> 00:07:28.160 hoch oder Daumen runter oder hier muss man nochmal. 00:07:29.600 --> 00:07:36.480 Ja, also im Endeffekt, ich würde mal ganz, ohne dass man da jetzt auf irgendwelche speziellen Tools 00:07:36.480 --> 00:07:40.720 eingeht oder dass man, also ganz generisch gesehen ist es halt, 00:07:41.280 --> 00:07:47.040 man hat bestimmte Features, bestimmte Requirements, die man implementieren will, 00:07:48.080 --> 00:07:54.960 und man gibt diese Änderungen in irgendeiner Form und an seine Kollegen weiter, 00:07:55.120 --> 00:08:00.400 damit sie sich diese Änderungen, die man da implementiert hat, mal angucken, 00:08:00.960 --> 00:08:05.520 um bestimmte Dinge, wie soll man sagen, bestimmte Dinge damit zu tun. 00:08:05.680 --> 00:08:10.480 Also ich meine, da gibt es halt so den Faktor, man will vielleicht auch Wissen weitergeben. 00:08:10.640 --> 00:08:17.040 Sowohl über wie soll denn die Software funktionieren oder was für ein Problem versucht man denn da gerade zu 00:08:17.040 --> 00:08:22.240 lösen, als auch so Sachen wie, sind Coding-Standards eingehalten worden? 00:08:23.200 --> 00:08:30.160 Ist die Formatierung richtig, passt es in die restliche Architektur von dem Projekt und 00:08:30.160 --> 00:08:31.200 so weiter und so fort. 00:08:31.440 --> 00:08:35.840 Vielleicht auch, dass jemand noch so ein bisschen den Code im Kopf mit durchdenkt und dann irgendwelche 00:08:35.840 --> 00:08:40.800 Fehlerfälle aufzeigt, die der Autor noch nicht bedacht hat und so weiter und so fort. 00:08:40.960 --> 00:08:45.920 Ja, also ich finde, da stellen sich schon direkt so einige interessante Fragen, 00:08:46.000 --> 00:08:52.800 weil ich würde jetzt zum Beispiel behaupten, dass aus der Sicht eines Arbeitgebers oder einer Firma oder 00:08:52.960 --> 00:08:59.600 es kann ja auch irgendwie ein Hobbyprojekt sein, die häufigste oder so die 00:08:59.600 --> 00:09:04.320 Ursprungsmotivation schon ist, möglichst wenig Fehler zu haben. 00:09:04.800 --> 00:09:10.880 Dass es dann schon nochmal jede Menge andere mehr oder weniger Nebeneffekte gibt, 00:09:11.760 --> 00:09:15.360 die sowohl für denjenigen, der den Code geschrieben hat, als auch für den, 00:09:15.680 --> 00:09:19.040 der ihn dann letztlich reviewed, positiv sind. 00:09:19.840 --> 00:09:24.480 Ist irgendwie ein Nebeneffekt, aber ich glaube, so ganz ursprünglich ist die Idee schon, 00:09:24.720 --> 00:09:30.320 man will möglichst verhindern, dass fehlerhafter Code in ein Softwareprodukt wandert. 00:09:30.480 --> 00:09:34.560 Ein anderer interessanter Aspekt, der mir gerade noch eingefallen ist, wäre der Bus-Faktor. 00:09:34.720 --> 00:09:38.320 Also das heißt, da gibt es auch als Truck-Faktor oder als andere Sachen, 00:09:38.640 --> 00:09:44.480 das ist so mehr oder weniger definiert, als wie viele Leute im Team können vom Bus überfahren werden, 00:09:44.560 --> 00:09:49.120 ohne dass das Projekt komplett den Bach runtergeht, weil sie die einzigen waren, 00:09:49.200 --> 00:09:50.480 die wissen, was los ist. 00:09:50.640 --> 00:09:57.040 Und ich finde, da ist bei so Code-Reviews auch Wissenstransfer ein sehr interessanter Aspekt, 00:09:57.120 --> 00:10:01.760 dass man halt sagt, okay, indem Leute meinen Code-Reviewen, 00:10:02.080 --> 00:10:08.800 lernen sie mehr über die Funktionsweise des Codes und was ich dann versuche zu machen und 00:10:08.800 --> 00:10:14.160 wissen ungefähr auch, wo sie gucken müssen, wenn sie bestimmte Sachen suchen. 00:10:15.120 --> 00:10:20.640 Und sagen wir mal, das hilft ja auch im Zweifelsfall mir, wenn ich mal im Urlaub bin oder wenn ich mal 00:10:20.640 --> 00:10:26.080 irgendwie, keine Ahnung, aus irgendwelchen Gründen gerade nicht erreichbar bin und jemand versucht, 00:10:26.160 --> 00:10:30.960 meinen Code zu debuggen, dann ist es halt im Zweifelsfall im Zweifelsfall auch von Vorteil, 00:10:31.200 --> 00:10:34.560 wenn mehrere Leute Bescheid wissen, weil ich will vielleicht jetzt nicht, 00:10:34.640 --> 00:10:38.320 wenn ich gerade im Urlaub am Strand lieg, irgendwie angerufen werden, 00:10:38.400 --> 00:10:43.440 ey, kannst du mir mal beim Debuggen helfen, weil ich weiß nicht, wo du das und das machst. 00:10:44.480 --> 00:10:48.400 Ich denke auch, je nachdem, wie ein Softwareprojekt Release-Zyklen hat, 00:10:48.480 --> 00:10:52.560 also ob es entweder continuous ist und das Zeug einfach so rausgeht und auch deployed wird, 00:10:52.720 --> 00:10:57.600 oder ob man halt irgendwie zweimal pro Woche deployt und dann mehrere Commits zusammen macht. 00:10:58.240 --> 00:11:03.280 Es hilft Leuten auch, gerade wenn sie automatisiert so irgendwelchen Code-Reviews hinzugefügt werden, 00:11:03.680 --> 00:11:09.680 hilft ihnen auch zu wissen, was denn innerhalb der letzten drei, vier Tage so an Neuerungen hinzugekommen ist, 00:11:09.760 --> 00:11:13.840 wenn ein Release fehlschlägt, dass die eine grobe Übersicht haben, ja, 00:11:13.920 --> 00:11:15.600 wer hat denn jetzt alles committet? 00:11:15.840 --> 00:11:20.880 Und eventuell auch eine, in einem Code-Review ist ja, also normalerweise der Code, 00:11:20.960 --> 00:11:25.120 das DIF selber, aber normalerweise ist bei den meisten Tools auch noch eine Erklärung dabei, 00:11:25.200 --> 00:11:28.240 wo du irgendwie die Description reinstecken musst, wo du sagst, ja, 00:11:28.560 --> 00:11:34.720 wir fügen das jetzt ein, damit XY schneller wird oder weil es Probleme gab mit, 00:11:34.800 --> 00:11:38.320 keine Ahnung, System Z müssen wir das jetzt so machen. 00:11:38.640 --> 00:11:45.600 Du bekommst halt einfach auch automatisch Kontext um deine Commits herum hinzu und wenn es dann schief geht, 00:11:45.760 --> 00:11:51.200 dann ist die Chance, dass du einfach kurz drüber lest, wie das denn getestet wurde und was denn der Sinn 00:11:51.200 --> 00:11:54.480 dahinter ist, ist wesentlich einfacher, wenn die Leute gezwungen werden, 00:11:54.640 --> 00:11:59.200 sowas zu schreiben, anstatt dass es nur in der Commit-Message eventuell so halbweg drin steht. 00:11:59.600 --> 00:12:06.560 Ja, also ich glaube, wenn man das richtig macht, dann kann man halt auch später Codereviews wieder mit 00:12:06.560 --> 00:12:12.880 Releases korrelieren und dann im Zweifelsfall einfach über die Liste der akzeptierten 00:12:12.880 --> 00:12:17.120 Codereviews drüber gucken, um zu schauen, was hat sich denn da wo geändert, 00:12:17.360 --> 00:12:21.280 ohne ein komplettes Diff des kompletten Releases angucken zu müssen. 00:12:21.360 --> 00:12:23.760 Also ich glaube, das ist halt auch ein wichtiger Faktor, dass wenn man sagt, 00:12:23.840 --> 00:12:28.560 okay, ich habe jetzt gerade ein neues Release veröffentlicht und es gibt plötzlich irgendwelche Probleme, 00:12:28.800 --> 00:12:33.680 dann kann ich mal auf einem High-Level, ohne mir den kompletten Code angucken zu müssen, 00:12:34.080 --> 00:12:39.760 kann ich da auch mal einfach drüber gucken, um zu schauen, okay, wo wurde denn was gebaut und 00:12:40.720 --> 00:12:45.680 welche Änderung könnte denn dafür verantwortlich sein, im Gegensatz dazu, 00:12:45.760 --> 00:12:48.720 dass ich dann vielleicht tausende von Zeilen von Code, der sich geändert hat, 00:12:48.800 --> 00:12:49.360 reviewen muss. 00:12:49.520 --> 00:12:54.480 Ja, und gleichzeitig siehst du dann natürlich auch direkt, wer sich mit diesem Stück Code vielleicht schon mal 00:12:54.480 --> 00:13:01.280 auseinandergesetzt hat und eventuell auch irgendwie, was für Gedanken zu bestimmten Aspekten und 00:13:01.280 --> 00:13:02.640 so eingeflossen sind. 00:13:02.960 --> 00:13:07.600 Es gibt, wenn man das quasi so nachträglich anschaut, auf jeden Fall direkt nochmal Kontext. 00:13:07.840 --> 00:13:13.040 Also das ist, würde ich sagen, sind so die wichtigsten Punkte, warum man das macht. 00:13:13.680 --> 00:13:20.160 Ich würde sagen, okay, um Coding-Standards einzuhalten, braucht man halt auch noch andere Voraussetzungen oder 00:13:20.160 --> 00:13:24.160 für bestimmte Voraussetzungen, die wir jetzt gerade, für bestimmte Dinge, 00:13:24.240 --> 00:13:27.120 die wir gerade erzählt haben, braucht man auch noch andere Voraussetzungen. 00:13:27.280 --> 00:13:30.080 Zum Beispiel, wenn man jetzt irgendwelche Coding-Standards einhalten möchte, 00:13:30.160 --> 00:13:34.400 dann sollten die halt auch irgendwo mal vorhanden und irgendwie dokumentiert sein, 00:13:34.560 --> 00:13:41.200 dass man sagt, okay, wir legen Wert auf das und das und unsere Architektur sieht so und so aus und unser Code 00:13:41.200 --> 00:13:43.040 soll so und so formatiert werden. 00:13:43.280 --> 00:13:46.800 Damit das überhaupt irgendwie funktionieren kann, muss man dann halt auch sagen, 00:13:46.880 --> 00:13:53.280 okay, es gibt eine Kommunikation im Voraus, wie denn so die Erwartungshaltung aussieht, 00:13:53.360 --> 00:13:56.160 weil ansonsten ist es halt auch ein bisschen schwierig, würde ich sagen. 00:13:56.400 --> 00:14:01.280 Ja, es ist halt quasi aus Maintainer-Sicht derjenige, 00:14:01.360 --> 00:14:07.280 dem das Projekt sozusagen gehört, irgendwie ein bisschen arschig im Nachhinein, 00:14:07.360 --> 00:14:11.200 wenn jemand anderes da Code einreichen möchte, dann zu sagen, ja, nee, 00:14:11.280 --> 00:14:14.880 nee, mach das jetzt nochmal neu, weil wir erwarten jetzt hier, dass, 00:14:15.680 --> 00:14:22.400 weiß ich, wir wollen unbedingt, dass der jedes Zeichen irgendwie in einer Teile ist und keine 00:14:22.480 --> 00:14:27.280 Ahnung, irgendwelche absurden Regeln durchsetzen, ist halt irgendwie kacke. 00:14:27.440 --> 00:14:34.000 Es wäre schon besser, wenn jemand, der da dazu beitragen möchte, vielleicht bevor er anfängt Code zu 00:14:34.000 --> 00:14:40.720 schreiben, weiß, was von ihm erwartet wird und was letztlich auch potenziell später im Code-Review bemängelt 00:14:40.720 --> 00:14:41.360 werden könnte. 00:14:41.680 --> 00:14:46.480 Ja, und normalerweise also gerade sowas kann halt auch sehr leicht automatisiert werden, 00:14:46.560 --> 00:14:52.480 dass der Maintainer gar nicht erst zu diesem halbwertigen Code seine Zeit verbringt, 00:14:52.560 --> 00:14:56.720 sich da reinzulesen und halt jede zwölfte Zeile irgendwie anklickt und sagt, 00:14:56.880 --> 00:15:02.320 hier 80 Zeichen pro Zeile bitte oder ach, hier benutzt doch, keine Ahnung. 00:15:02.560 --> 00:15:06.080 Versuch mal nicht so auf dieses Attribut zuzugreifen, sondern anders. 00:15:06.480 --> 00:15:09.680 Da gibt es dann auch viel Tooling dafür, dass das halt automatisiert auch, 00:15:09.840 --> 00:15:15.360 jeweils in welchem Tool man das auch immer anschaut, sich automatisiert darüber beschwert und dem Antenner 00:15:15.360 --> 00:15:16.640 dann die Arbeit abnimmt. 00:15:17.600 --> 00:15:19.440 Ja, das hat direkt mehrere Aspekte. 00:15:20.080 --> 00:15:26.000 Du kannst einerseits sind Menschen irgendwie halt super schlecht, so kleine Dinge wie jetzt irgendwie, 00:15:26.160 --> 00:15:29.760 weiß nicht, Leerzeichen oder so zu finden und zu sehen. 00:15:30.160 --> 00:15:36.960 Und andererseits ist es für viel einfacher, von irgendwie einem Computer 00:15:37.200 --> 00:15:41.760 angemeckert zu werden, als halt von einem Menschen, weil es direkt irgendwie so zwischenmenschliche Spannungen 00:15:41.760 --> 00:15:42.240 rausnimmt. 00:15:42.320 --> 00:15:45.440 Das ist halt der blöde Roboter und von dem kann man auch genervt sein, 00:15:45.520 --> 00:15:49.520 wenn der einem dann irgendwie sagt, nee, ist jetzt rot, du darfst nicht vorbei, 00:15:49.680 --> 00:15:52.320 weil mach mal hier noch irgendwie die Leerzeile weg. 00:15:52.560 --> 00:15:57.600 Auf der anderen Seite muss man halt auch schon sagen, okay, Menschen sind dann öfters auch in der Lage, 00:15:57.760 --> 00:16:01.760 diese Indirektion zu durchbrechen und dann den Maintainer zu hassen, 00:16:02.080 --> 00:16:06.720 der sein Tool zu scharf konfiguriert hat. 00:16:07.040 --> 00:16:08.160 Kann auch passieren. 00:16:08.240 --> 00:16:14.000 Also ich glaube, da muss man dann halt so ein bisschen abwägen, inwiefern man dann halt automatisiert Regeln 00:16:14.560 --> 00:16:16.080 enforcement oder nicht. 00:16:16.800 --> 00:16:21.760 Ich glaube, wo wir gerade bei Tools waren, vielleicht könnte man noch da einen Schritt zurückgehen und mal zu 00:16:21.760 --> 00:16:24.400 Tools fürs Code-Review an sich kommen. 00:16:25.040 --> 00:16:27.440 Also was kann man dann denn so benutzen? 00:16:28.640 --> 00:16:34.160 Also bei uns in der Firma, wir benutzen Pull Requests, was man so aus GitHub kennt, 00:16:34.320 --> 00:16:40.560 was mittlerweile auch viele andere Plattformen anbieten, funktioniert letzten Endes so, 00:16:40.720 --> 00:16:46.720 dass man in Git eine Feature-Branch macht, indem man kontinuierlich seine Änderungen committet, 00:16:47.280 --> 00:16:54.240 die irgendwann als Pull-Request gegen einen bestimmten Branch einreicht und 00:16:55.200 --> 00:17:01.840 da zu dem Zeitpunkt findet dann ein Code-Review statt und wenn dann Leute dieses Codereview 00:17:01.920 --> 00:17:08.000 oder diese Änderung akzeptieren, dann werden die in den entsprechenden Branch, 00:17:08.080 --> 00:17:10.960 gegen den man da den Pull-Request aufgemacht hat, gemercht. 00:17:12.400 --> 00:17:16.240 Das war jetzt wahrscheinlich sehr viel Git-Jargon, was ich da benutzt habe. 00:17:16.320 --> 00:17:18.480 Ich hoffe, man versteht das einigermaßen. 00:17:18.720 --> 00:17:20.160 Ja, ich denke schon. 00:17:21.600 --> 00:17:23.360 Facebook benutzt Fabricator. 00:17:23.440 --> 00:17:29.680 Also Fabricator ist Open Source, aber wurde damals bei Facebook entwickelt und da 00:17:30.320 --> 00:17:36.320 Diffusion ist auch ein wunderbares Code-Review-Tool, das auch die Möglichkeit bietet, 00:17:36.480 --> 00:17:37.920 eigene Plugins einzubinden. 00:17:38.000 --> 00:17:42.560 Also wenn ihr euer irgendwie Python in PEP 8 haben wollt, 00:17:42.640 --> 00:17:45.760 dann gibt es da auch die Möglichkeit, Linter vorher laufen zu lassen, 00:17:45.840 --> 00:17:51.200 die dann quasi auf jede Zeile kommentieren, die da problematisch ist. 00:17:51.520 --> 00:17:58.320 Gibt es für Pull Requests bei GitHub auch, aber da sind es meist irgendwelche Services, 00:17:58.800 --> 00:18:03.920 CodeHound war, glaub einer, können wir mal verlinken, der dann quasi für dich kommentiert, 00:18:04.000 --> 00:18:07.120 jede Zeile, wo er sagt, hier, das ist aber falsch. 00:18:07.360 --> 00:18:13.840 Ja, es gibt mehrere Tools, die so Sachen automatisiert können für jetzt speziell GitHub. 00:18:13.920 --> 00:18:17.840 Es gab auch noch solche Dinge wie Code Climate, was glaube ich auch so ähnliche Sachen macht. 00:18:17.920 --> 00:18:24.560 Die haben so eine Suite von automatisierten Codemetriken, die man gegen seine Pull-Requests laufen 00:18:24.560 --> 00:18:25.360 lassen kann. 00:18:26.160 --> 00:18:31.120 Es gibt auch Tools, die so Sachen wie Test Coverage auswerten, dass man zum Beispiel sagt, 00:18:31.280 --> 00:18:36.640 okay, ich möchte jetzt nicht, dass durch Änderungen, die ich in meinen Code mit reinnehme, 00:18:36.720 --> 00:18:43.600 die Test-Coverage sinkt, was letzten Endes bedeutet, da ist Code in den Änderungen 00:18:43.600 --> 00:18:47.200 mit drin, der ungetestet ist und der keine automatisierten Tests hat. 00:18:48.320 --> 00:18:52.080 Ich glaube, das ist dann halt die Sache von den entsprechenden Maintainern, 00:18:52.320 --> 00:18:54.400 ob die sowas haben wollen oder nicht. 00:18:54.480 --> 00:18:59.920 Also es gibt da ein Ökosystem um dieses ganze Pull-Request-Zeug außenrum. 00:19:00.800 --> 00:19:04.000 Es gibt sehr viele Open Source Tools, die man sich installieren kann. 00:19:07.120 --> 00:19:11.520 Ich würde auch sagen, es gibt so zwei Ebenen von diesen Pull-Requests. 00:19:11.680 --> 00:19:18.640 Also GitHub ist so die Barebones-Ebene, dass irgendjemand macht in einem Projekt einen Pull-Request auf und 00:19:18.640 --> 00:19:22.640 dann werden halt alle benachrichtigt, die da irgendwas mit zu tun haben, 00:19:22.960 --> 00:19:27.680 die in diesem Repo Administrator sind oder sich da irgendwie subscribed haben. 00:19:28.080 --> 00:19:33.120 Wenn du gerade in größeren Firmen, keine Ahnung, Google, Facebook, Microsoft, 00:19:33.440 --> 00:19:36.000 gibt es dann meist noch ein bisschen mehr Tooling drumherum. 00:19:36.080 --> 00:19:40.240 Also gerade Fabricator hat einige Systeme, wie zum Beispiel Herald, wo du 00:19:40.730 --> 00:19:44.810 dich quasi subscribe kannst, also du sagst dann, ich will entweder für jedes Mal, 00:19:44.970 --> 00:19:48.970 wenn eine dieses Repo ein Code-Review aufstellt, will ich mich automatisch hinzufügen. 00:19:49.130 --> 00:19:52.410 Du kannst aber auch per irgendwie Racket Expression Matching sagen, 00:19:52.570 --> 00:19:56.490 hey, mich interessiert nur diese eine Datei, oder du kannst sagen, hey, 00:19:57.050 --> 00:20:02.490 wenn jemand irgendwie, keine Ahnung, du baust ein neues Tool, irgendwie einen ORM, 00:20:02.570 --> 00:20:06.170 keine Ahnung, mapst da deine Datenbank, dann kannst du sagen, jedes Mal, 00:20:06.250 --> 00:20:11.450 wenn einen Review macht, das diesen Klassennamen beinhaltet, wenn den einer neu hinzufügt, 00:20:11.530 --> 00:20:12.890 würde ich gerne drüber schauen. 00:20:13.370 --> 00:20:18.650 Also da helfen Code-Veviews auch gewissermaßen deine Aufmerksamkeit zu skalieren, 00:20:18.730 --> 00:20:22.330 dass du nicht jedes Code-Review in der kompletten Codebase dir durchlesen musst, 00:20:22.490 --> 00:20:26.730 sondern dass dann halt automatisch, hey, wenn einer diese Klasse anfasst, 00:20:26.890 --> 00:20:32.250 das ist recht neu, da will ich drüber Bescheid wissen, kannst du dich quasi automatisch da hinzufügen. 00:20:32.410 --> 00:20:37.930 Und andersrum geht es auch, dass du dir, dass du nicht nur automatisch hinzugefügt wirst, 00:20:38.010 --> 00:20:43.290 dass du auch sagen kannst, hey, ich bin ein Owner, also du sagst hier für dieses Projekt, 00:20:43.450 --> 00:20:48.810 da muss ich oder einer von den anderen fünf Leuten oder eine Gruppe ihr OK geben, 00:20:48.890 --> 00:20:50.250 bevor das committed werden kann. 00:20:50.330 --> 00:20:55.770 Also das Code-Review bietet in dem Fall auch ein bisschen, ja, 00:20:56.730 --> 00:21:02.650 diese Komponente von Ownership von Code, dass du sagst, ja, theoretisch kann jeder überall Code modifizieren, 00:21:02.970 --> 00:21:07.290 aber gerade in diesem Bereich, weil es eventuell direkt automatisch ins Deployment geht, 00:21:07.450 --> 00:21:10.970 verlangen wir, dass unser Team da das letzte Ja oder Nein drüber hat. 00:21:11.130 --> 00:21:17.450 Also das ist ja, geht dann quasi über dieses pure das Div anschauen und kommentieren noch ein oder zwei 00:21:17.450 --> 00:21:24.410 Schritte weiter und kann da quasi so eine Engineering Organization auch skalieren lassen. 00:21:24.730 --> 00:21:26.170 Was ganz cool ist. 00:21:27.050 --> 00:21:31.530 Das ist ein interessanter Punkt, den du da gerade ansprichst, weil so wie es sich das für dich anhört, 00:21:31.690 --> 00:21:36.890 für mich gerade anhört oder so wie ich es auch über Facebook als Engineering-Organisation oft gehört habe, 00:21:37.050 --> 00:21:41.530 benutzen die ein großes Repository für sehr, sehr viele Projekte. 00:21:42.090 --> 00:21:45.050 Ich weiß jetzt nicht, ob du das kommentieren darfst oder nicht. 00:21:46.090 --> 00:21:49.210 Ja, es ist, glaube ich, öffentlich bekannt. 00:21:49.770 --> 00:21:53.770 Es gibt nicht nur eins, es gibt so vier oder fünf, aber die sind alle, 00:21:53.850 --> 00:21:59.370 ja, schon alle groß genug, dass da tausende von Leute dran arbeiten. 00:22:00.410 --> 00:22:03.370 Ja, bei uns ist das nämlich genau das Gegenteil der Fall. 00:22:03.530 --> 00:22:07.450 Also wir in unserem Team jetzt konkret, wir sind ein Team mit, glaube ich, 00:22:07.530 --> 00:22:11.690 acht Leuten, davon sind, glaube ich, sechs Engineers oder so oder fünf. 00:22:13.130 --> 00:22:18.410 Und wir haben, ich glaube, sechs Repositories allein in unserem Team. 00:22:18.490 --> 00:22:24.010 Also wir haben sehr viele kleine Projekte, die dann vielleicht mal ein bisschen Shared Code haben in Form von 00:22:24.010 --> 00:22:29.370 irgendwelchen Libraries oder so, aber zum größten Teils ist es abgeschlossener Code und für diese Repositories 00:22:29.610 --> 00:22:34.170 hat man dann vielleicht ein, zwei oder drei Maintainer, 00:22:34.250 --> 00:22:40.330 die dafür verantwortlich sind, die da quasi als Gatekeeper dafür dienen oder 00:22:41.450 --> 00:22:47.770 quasi entscheiden, ob Code reingenommen wird oder nicht oder ob sich was ändern muss oder nicht. 00:22:48.090 --> 00:22:52.490 Und auch ganz interessant, GitHub hat vor kurzem ein Feature hinzugefügt, 00:22:52.650 --> 00:22:57.930 dass man die machen Recommendations für Leute, 00:22:58.090 --> 00:23:00.730 die man in Code-Reviews mit einladen kann. 00:23:00.890 --> 00:23:07.770 Also das heißt, sie merken sich so, okay, du hast schon öfters in diesem Projekt Code 00:23:07.770 --> 00:23:12.650 eingereicht, welche Leute waren denn da an den Reviews beteiligt, für welche Dateien? 00:23:12.890 --> 00:23:16.330 Und dann schlagen die dir, wenn du das Code, wenn du den Pull-Request aufmachst, 00:23:16.490 --> 00:23:22.410 schlagen sie dir quasi vor, welche Leute du denn da jetzt einladen könntest, 00:23:22.650 --> 00:23:25.610 um da zu kommentieren, was ich auch ganz nett finde. 00:23:26.650 --> 00:23:30.410 Ja, ich glaube, die machen das sogar noch ein bisschen klüger und schauen sich an, 00:23:30.730 --> 00:23:36.250 wer die Dateien, die betroffen sind, in der Vergangenheit selber bearbeitet hat. 00:23:36.490 --> 00:23:39.210 Und das ist halt, also ist im Prinzip eigentlich kein neues Feature, 00:23:39.290 --> 00:23:42.570 es ist jetzt nur neu, dass es halt bei GitHub direkt eingebaut ist. 00:23:43.050 --> 00:23:48.330 Früher gab es es aber auch schon von, ich weiß nicht, ob das ein Facebook oder ein GitHub-Projekt war, 00:23:48.410 --> 00:23:55.290 der Menschenbot, wo man dann wiederum, das muss man eben als separaten Service irgendwie laufen 00:23:55.290 --> 00:24:02.250 haben, der dann bei neuen Pull Requests benachrichtigt wird, sich dann die Dateien anschaut und dann über die 00:24:02.570 --> 00:24:08.410 Git-History eben schaut, welche Leute jetzt hier potenziell interessant sind, 00:24:08.810 --> 00:24:13.450 weil sie eben die Files, die verändert wurden, kennen, weil sie die in der Vergangenheit selber schon 00:24:13.450 --> 00:24:14.330 bearbeitet haben. 00:24:14.570 --> 00:24:20.650 Was jetzt auch gerade bei so großen Projekten super hilft, weil man eben nicht alle 100 Leute, 00:24:20.730 --> 00:24:25.610 die da mal jemals irgendwie was beigetragen haben, benachrichtigen will, 00:24:25.690 --> 00:24:31.050 weil die sich jetzt vielleicht auch mit dem konkreten Subset von Änderungen auskennen. 00:24:32.490 --> 00:24:39.130 Aber stattdessen halt eben selektiver macht und somit bei größeren Projekten dieses ganze Thema ein bisschen 00:24:39.130 --> 00:24:40.490 besser skalieren kann. 00:24:41.530 --> 00:24:44.970 Ja, ja, ist auch interessant, wie man denn den Code dann einreicht, 00:24:45.050 --> 00:24:47.610 ob man da irgendwelche Feature-Branches macht. 00:24:47.690 --> 00:24:52.010 Also was, glaube ich, generell recht bekannt ist, ist dieses Git Flow, 00:24:52.650 --> 00:24:59.210 was halt so, wie soll man das sagen, das ist so eine Richtlinie für wie kann man denn neue Features 00:24:59.210 --> 00:25:00.010 implementieren. 00:25:00.170 --> 00:25:04.330 Man macht einen Feature-Branch, man hat dann quasi einen Development-Branch, 00:25:04.410 --> 00:25:06.330 einen Release-Branch und so weiter. 00:25:06.490 --> 00:25:13.290 Und Git Flow ist dann quasi eine Richtlinie vorerst mal mit 00:25:13.290 --> 00:25:17.450 einem bisschen Tooling außenrum, wie man sowas halt, sagen wir mal, 00:25:17.690 --> 00:25:20.090 ein bisschen formaler definieren kann. 00:25:20.170 --> 00:25:25.290 So wie haben denn Feature-Branches auszusehen, wie sollen die benannt sein, 00:25:25.450 --> 00:25:29.050 welchen Branch mergelt man zu welchem Zeitpunkt wohin und so weiter. 00:25:30.010 --> 00:25:36.650 Ist jetzt nicht unbedingt direkt nicht unbedingt direkt was mit 00:25:36.650 --> 00:25:41.050 Code-Reviews zu tun, aber ist halt so eine Art und Weise, wie wir das machen. 00:25:42.650 --> 00:25:42.970 Ja. 00:25:43.690 --> 00:25:45.930 Ich weiß jetzt nicht, wie sieht es bei dir aus, Marc. 00:25:47.370 --> 00:25:51.770 Komischerweise, die ganzen Silicon Valley-Firmen, 00:25:51.850 --> 00:25:56.170 also die ich so kenne hier, machen alle Trunk-Based Development. 00:25:56.410 --> 00:26:02.170 Bedeutet, es gibt keine langlebigen Feature-Branches, es gibt selten irgendwelche Release-Branches wirklich, 00:26:02.330 --> 00:26:08.250 sondern du nimmst einfach, was auch immer gerade in Trunk ist und du machst dann halt einen, 00:26:08.890 --> 00:26:15.530 Mercurial heißt es einen Bookmark oder halt einen Branch, aber der wird einfach zurück nach Master direkt 00:26:15.530 --> 00:26:18.810 gemerkt, ohne dass man da irgendeine Development-Branch oder sonst was hat. 00:26:18.970 --> 00:26:23.690 Aber das geht halt auch nur, wenn du sehr gute, ich sag mal, 00:26:24.170 --> 00:26:28.490 Release-Möglichkeiten hast und sehr gute Testabdeckung. 00:26:29.690 --> 00:26:34.650 Aber du nimmst im Grunde jedes Mal, wenn du eine neues Release baust, nimmst du alles, was im Master drin ist. 00:26:34.730 --> 00:26:40.170 Und du darfst halt nichts, was nicht, erstmal wenn es die Tests nicht passt, darfst du es nicht merchen. 00:26:40.570 --> 00:26:46.650 Und wenn es nicht released werden sollte, dann hat es auch nichts im Master zu suchen. 00:26:46.890 --> 00:26:51.770 Ja, ist eigentlich eine ganz schöne Praxis eigentlich, so dieses, 00:26:52.730 --> 00:26:57.930 dieser Grundsatz, quasi alles, was nicht bereit ist, jetzt sofort deployed zu werden, 00:26:58.650 --> 00:27:01.930 darf halt auch nicht in Master werden oder für die lohnt es sich gar nicht, 00:27:02.010 --> 00:27:05.530 jetzt irgendwie ein Pull-Request oder wie auch immer man das jetzt konkret nimmt, 00:27:06.250 --> 00:27:06.970 aufzumachen. 00:27:07.050 --> 00:27:12.250 Weil ja, es gibt dann irgendwie verschiedene Möglichkeiten, das umzusetzen und durchzusetzen, 00:27:12.490 --> 00:27:19.290 aber es, ich habe das Gefühl gehabt bisher, dass es so die Softwareentwickler in 00:27:19.290 --> 00:27:24.090 ein ganz gutes Mindset versetzt, wie sie Code schreiben. 00:27:25.130 --> 00:27:29.610 Ja, also es gibt ja zum Beispiel auch noch, so, ich weiß jetzt nicht, 00:27:29.690 --> 00:27:34.330 ob das generell darauf rausläuft, was der Markt jetzt beschrieben hat, 00:27:34.410 --> 00:27:39.210 aber es gibt ja halt auch noch so diese Herangehensweise, dass man sagt, 00:27:39.530 --> 00:27:45.370 ich release auch unfertigen Code und verstecke den dann halt hinter FeatureFlex zum Beispiel. 00:27:45.610 --> 00:27:51.610 Dass man halt sagt, okay, ich kann Code committen, ich kann den auch relativ schnell wieder in meinen Branch 00:27:51.610 --> 00:27:56.410 zurückmerchen, der wird dann mitreleased und ich sorge einfach über ein Konfigurationssystem dafür, 00:27:56.490 --> 00:27:58.730 dass der in der Produktion nicht läuft. 00:27:59.050 --> 00:28:04.570 Oder ich release den und schalte ihn nur zum Beispiel für meine nächsten Kollegen frei, 00:28:04.650 --> 00:28:06.250 damit die den mal testen können. 00:28:07.050 --> 00:28:12.010 Oder aber ich sage, okay, ich möchte das Feature jetzt komplett releasen, 00:28:12.330 --> 00:28:16.250 habe aber die Möglichkeit, das komplett wieder abzuschalten, wenn ich merke, 00:28:16.330 --> 00:28:17.530 irgendwas stimmt nicht. 00:28:17.770 --> 00:28:23.610 Also das sind halt auch so Sachen, okay, man braucht dann auch eine gewisse Infrastruktur beim Releasen, 00:28:23.930 --> 00:28:30.010 wenn man denn sagt, okay, man möchte jetzt halt nur auf einem Branch arbeiten und diese Feature-Branches, 00:28:30.170 --> 00:28:31.130 die leben nur sehr kurz. 00:28:31.290 --> 00:28:34.250 Also möchte ich auch dazu sagen, dieses GitFlow, was wir da benutzen, 00:28:34.490 --> 00:28:41.210 im Normalfall, wenn jemand bei uns einen Pull-Request einreicht, 00:28:41.530 --> 00:28:45.290 dann hängt der da selten länger als ein, zwei Tage. 00:28:45.370 --> 00:28:49.930 Dann gibt es vielleicht nochmal eine Zeit, wo dann irgendwie hin und her diskutiert wird oder hier gibt es mal 00:28:49.930 --> 00:28:56.650 einen Vorschlag und dann wartet man noch ein paar Stunden, bis dann der Autor die Änderung eingebaut 00:28:56.650 --> 00:28:56.970 hat. 00:28:57.690 --> 00:29:00.570 Aber im Normalfall passiert es dann relativ schnell. 00:29:01.130 --> 00:29:04.730 Gut, da kann man sich noch die Frage stellen, möchte man noch ein extra Development, 00:29:04.810 --> 00:29:06.410 ein extra Release-Branch haben? 00:29:07.770 --> 00:29:13.690 Ich glaube, da spricht nicht, also für sehr viele Branches, 00:29:13.770 --> 00:29:17.770 die man pflegen muss, spricht eigentlich sehr wenig, außer dass man das Tooling braucht, 00:29:17.850 --> 00:29:20.730 um das Ganze zu managen, wenn irgendwas schief geht. 00:29:21.610 --> 00:29:27.210 Also gerade so Sachen wie Feature Flags und so weiter sind da halt wichtig, 00:29:27.370 --> 00:29:32.090 dass man die hat, um im Zweifelsfall reagieren zu können, wenn es Probleme gibt. 00:29:32.250 --> 00:29:36.010 Ja, und ich glaube auch viel, gerade bei diesen großen Belly-Firmen, 00:29:36.090 --> 00:29:42.650 ist halt auch das Problem, dass diese Gedanke, dass du eine Development-Branche und eine Release-Branch hast, 00:29:42.810 --> 00:29:47.610 ist halt funktioniert irgendwann nicht mehr, wenn dein Code auf, 00:29:47.690 --> 00:29:54.490 keine Ahnung, 500.000 Server deployed werden muss, weil die zwei Branches müssen 00:29:54.490 --> 00:29:58.410 kompatibel sein, weil allein durch die ganze Physik, die da involviert ist, 00:29:59.210 --> 00:30:03.530 werden beide Code-Artefakte gleichzeitig laufen. 00:30:03.690 --> 00:30:06.970 Und eventuell werden die auch miteinander gleichzeitig reden. 00:30:07.370 --> 00:30:11.050 Also das ist halt eine Sache, die du dann, du hast dann keine Branches, 00:30:11.130 --> 00:30:16.330 die das für dich managen, aber du musst Vor- und Rückwärtskompatibilität halt immer in deinem Code einbauen, 00:30:16.650 --> 00:30:18.810 weil er halt entsprechend released wird. 00:30:18.970 --> 00:30:22.570 Und da sind auch diese ganzen Datenformate irgendwie, keine Ahnung, 00:30:22.890 --> 00:30:28.810 Thrift oder Avro oder so, da wird auch kein Feld gelöscht, 00:30:28.970 --> 00:30:34.810 weil während einem Release halt dieses Feld von der Hälfte deiner Server noch erwartet wird, 00:30:34.890 --> 00:30:41.050 dass es da ist, es wird dann halt deprecated und nach vorne quasi einfach wieder mitgenommen, 00:30:41.210 --> 00:30:45.450 obwohl es halt niemand benutzt und dann eventuell in einem halben Jahr kannst du es eventuell mal wegmachen, 00:30:45.690 --> 00:30:49.450 aber ist das Mindset ein bisschen anders, als wenn du, keine Ahnung, 00:30:49.530 --> 00:30:54.810