Softwareentwicklung zwischen Forschungscode und Industriereleases
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 60 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/42500 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
6
13
21
25
41
53
00:00
Computer programmingModal logicData analysisAtomic nucleusSoftwareEckeComputer animation
00:22
Computer programmingAtomic nucleusPredictionLecture/ConferenceComputer animation
01:13
Computer programmingLetterpress printingPhysical quantityComputer animation
01:34
Computer programmingAtomic nucleusMathematicsCodeFile formatCodePredictionScripting languageSystems <München>Run-time systemInterface (computing)Computer programmingInterface (computing)Software developerContext awarenessNetwork topologyExecution unitSoftware developerComputer animation
05:23
CodeAtomic nucleusAutomationPredictionAutomationMathematicsCodePAPComputer animation
06:11
CodeAtomic nucleusAutomationComputer programmingWeb pageSoftwareComputer scienceWalkthroughCodePredictionSocial classFRAMEWORK <Programm>Generating functionConfluence (abstract rewriting)Service PackRandAutomationInstanz <Informatik>Interface (computing)Sound effectTwitterVariable (mathematics)Run-time systemServer (computing)Local ringPredictionMittelungsverfahrenRow (database)Computer animation
12:01
Atomic nucleusPredictionRobotCodeRevision controlCodeRobotSoftwareDatabaseChecklistInterface (computing)Git <Software>Instanz <Informatik>iPadDatabaseConfiguration spaceInternetServer (computing)ReliefPhysical quantityPredictionMoment (mathematics)Programming languageComputer animation
17:51
Stress (mechanics)Grand Unified TheoryFormatiererPredictionSoftwareCodeDirection (geometry)TypMathematicianLengthFunction (mathematics)PROBE <Programm>Interface (computing)CompilerSocial classMilitary rankPrint <4->MathematicsLoop (music)PAPNormal (geometry)Computer animationLecture/Conference
Transcript: German(auto-generated)
00:01
Ja, ich komme vom Zusehinstitut, das ist hier gleich um die Ecke quasi in Berlin und bin Teil des Forschungscampus Modal und arbeite dort im Gaslab. Ich wollte euch ganz kurz erzählen, was das Gaslab macht, wie wir so sind und danach, wie wir so mit trial und error herausgefunden haben, wie man Software entwickelt oder eben noch nicht.
00:20
Also das Gaslab besteht aus Leuten, die in Berlin sitzen, das sind hauptsächlich Forscher und Forscherinnen, ein Professor und dann haben wir einen großen Industriepartner, das ist die Open Grid Europe, die war mal irgendwie die Ruhr AG oder hat mal zur RWI gehört und die betreiben den größten Teil des westdeutschen Gasnetzes.
00:40
Für uns interessant sind ungefähr 50.000 Kilometer aus diesem Gasnetz, da haben wir so 1.500 Ein- und Ausspeiseknoten, 10.000 Knoten in der Mitte und dann gibt es noch einen Partner, das sind Softwareentwicklungsunternehmen, die bereiten zum einen Daten für uns auf und schicken uns die und zum anderen entwickeln die eine GUI, die unseren Prototyp bei dem
01:02
Industriepartner eben anzeigen kann. Und was unser Projekt machen möchte, sind im Wesentlichen zwei Dinge, zwei Ziele, das eine ist eine Prognose. Wir wollen für die nächsten 24 Stunden vorhersagen, wie viel Gas speisen wir ein und aus an all diesen Ein- und Ausspeiseknoten. Das sind Knoten an Ländergrenzen, das sind Kraftwerke, Stadtwerke, Industriebetriebe
01:24
und wir wollen eine Empfehlung geben, wie man verschiedene Netzelemente steuern kann. Also große Kompasserstationen, ganze Industrieanlagen, riesige Hallen bis zu kleinen Ventilen. Da wollen wir Vorschläge machen, das wollen wir eben mit mathematischer Optimierung machen, weil wir aus dem LP-Emitbereich kommen.
01:44
Wir wollen nicht direkt das umsetzen, also wir wollen nicht direkt auf deren Steuerungssysteme zugreifen, sondern Vorschläge machen, die dann von den Dispatchern, also den Leuten, die das Gas nicht steuern, bewertet werden können. Ja und was wir dafür haben, sind alle diese Menschen, plus minus eins, zwei,
02:02
weil das ja im Wissenschaftskontext immer sich ein bisschen ändert, wer da ist und vier von uns forschen tatsächlich nicht, sondern sind als reine Admins und Entwickler und Entwicklerinnen da. Das heißt aber, dass die ganz viele von denen da Forschungscode schreiben. Wie das eben ist, die haben diese Daten, die wollen da irgendwas rausfinden, die wollen für die Prognose wissen, wie kann ich da jetzt was vorhersagen,
02:22
was muss ich da miteinander korrelieren und dann schreiben die ihren Code, Python, Arda, Java, alles Mögliche und ihre Skripte und haben überhaupt keine Absicht, das in dem Sinne zu veröffentlichen und an Industriepartner auszuliefern. Wir aber müssen ab und zu Releases machen, also wir haben vorgegebene Releases und manche, die wir auch machen wollen und die laufen beim
02:42
Dispatcher. Das heißt, die laufen auf den Systemen von einem Gasunternehmen und haben entsprechend Vorlaufzeiten. Wir releasen ungefähr alle vier Monate und dann dauert das ungefähr vier Wochen bei denen, bis sie das durch drei Systeme durchgespielt und getestet haben, was eben hauptsächlich Sicherheitsaspekte sind. Also obwohl wir nur was anzeigen, dürfen wir da natürlich nicht kaputt
03:01
machen. Das heißt aber auch, wir wollen, dass unser Code stabil ist. Wenn wir ein Bug-Fix machen wollen, dann müssen wir da auch selber wieder testen. Bei uns ist eine Sprint Umgebung schon, die müssen das alle wieder testen. Das kostet Geld, Zeit und Nerven. Das heißt, wir wollen gerne stabile Releases haben. Unser Projekt hat Anfang 2015 so richtig angefangen und geht jetzt
03:22
noch bis Ende September. Und wir haben heute, die eine Kollegin hat heute noch mal released und wir werden noch mal ein großes Release jetzt im August machen. Während dieser ganzen Projektdauer hatten wir 15 produktive Schnittstellen-Versionen, das heißt 15 Varianten von XML und HTTP-Schnittstellen, die wir definiert haben mit unserem
03:41
Industriepartner, in denen Daten gekommen sind. Unheimliche Mengen Daten, Gasflüsse, Wetter, Netzwerktopologie, Bestellungen von Gas, alle solche Sachen. Und für uns als Entwickler und Entwicklerinnen ist das relativ schwierig. Diese Daten ändern sich, was da drin steht. Und die Forscher und Forscherinnen wollen die gern benutzen. Und die wollen nicht nur von der letzten Schnittstelle das
04:01
benutzen, sondern alles. Wenn wir das Gasnetz vorhersagen wollen, wollen wir erst in fünf Jahren Daten benutzen. Die kommen jetzt aber in 14, 15 verschiedenen Formaten. Das heißt, wir als Entwickler und Entwicklerinnen müssen das entweder transformieren oder irgendwie Tools zur Verfügung stellen, sodass man die aus verschiedenen Schnittstellen einlesen kann. Hier sind unsere Releases, 14 Releases.
04:21
Und dann hatten wir, wir haben drei oder vier Releases gemacht bis Mitte 2016. Und dann kam plötzlich eine Kaskade von Hotfixes auf uns zu. Einhergehend mit Überstunden, mit Tagen, wo wir wirklich bis abends saßen, weil bis 12 Uhr muss released werden. Das muss jetzt fertig werden. Und da haben wir verschiedene Sachen versucht, um das in den
04:42
Griff zu kriegen und unsere Leute zu entlasten. Unsere Forscher und Forscherinnen hatten noch keine Zeit mehr. Die mussten da mit uns irgendwas programmieren und uns ihre Anforderungen sagen. Ja, und dann, ich erzähle jetzt gleich, was wir da alles so ausprobiert haben und wie das funktioniert hat oder nicht. Diese Releases sind, wie gesagt, sehr aufwendig. Nicht nur, dass wir die planen und auch mit den Industriepartnern und dem Softwareunternehmen abstimmen
05:01
müssen. Wir müssen ja dann irgendwann implementieren, testen, dokumentieren, also Release Notes, Handbücher für den Industriepartner und so weiter. Ja, und das dauert dann alles ein bisschen länger. Gut, also wir wollen stabile Releases. Bitte, bitte keine Bugfixes, bitte möglichst selten ausliefern.
05:21
Es soll schnell sein. Unsere Prognose läuft jede Stunde einmal dort. Das heißt, die soll auch bitte so in 10 bis 20 Minuten fertig sein, damit die da was davon haben, was für nächste Stunde vorhergesagt wird. Und unser Navi, also das Empfehlungstool, soll in einer halben Stunde laufen, wenn es geht, vielleicht auch in einer Viertelstunde und diese Handlungsempfehlungen vorhersagen für die nächsten Minuten.
05:41
Und gleichzeitig möchten wir jetzt unser Forschungsteam auch noch davon entlasten, dauernd mit uns programmieren zu müssen. Die brauchen Zeit zum Forschen und ihre Paper zu schreiben und so weiter. So, dann haben wir uns verschiedene, na tatsächlich im Nachhinein eher in verschiedene Bereiche unterteilt, wo wir versucht haben, da irgendwas besser oder anders zu machen, damit das für alle stressfreier wird. Als erstes eben Code Qualität
06:02
angucken und dann gleich nochmal Automatisierung, Dokumentation und was wir sonst so gemacht haben. Bei Code Qualität haben wir angefangen, wir kommen fast alle aus der Mathematik. Eine Elektrotechnikerin, einen Informatiker gehabt und wir wissen gar nicht, wie wir Code schreiben. Man kann das vielleicht lernen im Mathestudium. Die meisten tun das, glaube ich, nicht.
06:22
Und was ist eigentlich mit der Code? Also haben wir angefangen, bei gutem Code zu diskutieren. Das war sehr schön. Witzige Diskussionen mit den Theoretikern und Theoretikerinnen. Und dann schreiben die aber irgendwas. Also ich kann sagen, das hilft nicht, darüber zu reden und ihnen zu sagen, benennt eure Variable sinnvoll. Sagen alle, ja, ja, ja. Macht aber keiner. Dann haben wir denen so Tools zur Verfügung gestellt,
06:41
denen man alles Mögliche sehen kann. Man kann sehen, hier ist eure Testabdeckung. Das ist nicht abgedeckt, was da in rot ist. Da habt ihr eure Coverage. Da habt ihr, wie viele Kommentare fehlen. Da habt ihr, hier habt ihr uneindeutige Integer bei uns. Dann haben wir das, oh, das ist aber schön. Aber da hat keiner Zeit für. Also vielleicht wollten die da sogar was besser machen. Aber Paperschreiben ist eben wichtiger für Leute, die gerade promovieren.
07:02
Freutlich haben wir, also diese schönen Tools gibt es alle. Kann man sich angucken. Macht aber keiner. So. Okay. Und was wir dann gemacht haben und was tatsächlich geholfen hat, auch unsere Bugfixes zu reduzieren, ist, Dinge verpflichten zu machen. Wir haben nur noch erlaubt, Code in den Master zu merchanten,
07:22
wenn jemand anders das reviewed hat. Das geht einfach nicht mehr. Das war ziemlich effizient. Dadurch wurden ziemlich viele Bugs gefunden. Und das hat den Code auch wesentlich wartbarer gemacht, weil sehr oft Leute gefragt haben, was machst du hier eigentlich? Was passiert sehr schnell im Code? Und wenn dann da jemand drauf antwortet, wurde das üblicherweise auch direkt in den Code getan, weil die Erklärung scheinbar notwendig war.
07:41
Dann haben wir eine kleinere statische Code-Analyse jetzt, die mitkommodiert werden muss. Also sie wird automatisiert ausgeführt oder eben lokal. Und alle Warnings, die da rauskommen, müssen mitkommittet werden. Das heißt, der Reviewer sieht, was hier schlechter geworden ist. Da ist die Code-Komplexität gestiegen, zum Beispiel um zwei oder drei in der Klasse. Und dann wird das eben mitreviewt.
08:01
Vielleicht ist es in manchen Fällen erlaubt und okay. Aber meistens verzichtet man da drauf und refaktort eher seinen Code, als sowas zu kommitten. Wir führen die Code-Analyse auch immer zyklisch durch. Also Warnings erlauben wir, aber Fehler aus gewissen Klassen erlauben wir einfach nicht.
08:20
Und dann kann einfach nicht gemerged werden, wenn es Fehler in gewissen Bereichen gibt. Ganz großer Bereich, das für uns auch sehr entspannt gemacht hat, ist einfach alles zu automatisieren, was zu automatisieren gilt. Das erste ist Regressionstests. Also die Forscher und Forscherinnen haben da irgendwie so ein bisschen Testart, mit denen sie erst mal ihren Code
08:41
überprüfen. Und die muss man denen dann klauen und mit in ein Test Framework einbauen und die jedes Mal laufen lassen. Bei jeder Veränderung im Code muss eben noch mal eine neue Prognose gemacht werden. Eine Prognose gemacht werden, in der Netzwerkdaten fehlen. Eine Prognose gemacht werden, in der das Wetter schlecht ist oder wo alle schon Gas vorbestellt haben und eigentlich schon klar ist, was nächste Stunde passiert.
09:03
Wir haben einen kleinen Testdatensatz, den wir quasi bei jedem Merge oder jeder Veränderung in der Code-Basis laufen lassen. Und wir haben einen großen Testbereich, der so zwei, drei Stunden bei uns auf dem Plaster läuft, den wir nächtlich laufen lassen. Lassen wir auch für die Code-Analyse laufen.
09:22
Und so ein bisschen am Rande. Wir haben eine einheitliche Code-Formatierung. Das haben wir relativ früh eingeführt. Und das war eine sehr, sehr gute Sache. Also das kann ich euch nur ein ins Herz legen. Macht das so automatisiert, wie es geht. Sonst ist eure ganze Git-History voll mit Formatierungsänderungen. Weil irgendwer in Python doch lieber Tabs als Leerzeichen benutzt. Ja, und dann sieht man da nicht mehr durch.
09:44
Diese Regressionstests, die da immer laufen, die kriegt man in schönen Pipelines angezeigt. Das heißt, immer wenn man so ein Merge-Request anliegt, ist entweder alles grün oder irgendwas ist rot. Und wenn rot ist, dann geht nichts zum Mergen. Und auch diese, ja, lass mal so stehen.
10:00
So, Automatisierung, mehr Automatisierung. Wir müssen diese Releases erzeugen. Wir müssen dauernd irgendwelche Releases machen. Und das ist relativ aufwendig. Da sind irgendwie relativ viele Schritte zu tun. Das muss irgendwie alles kompiliert werden und getestet werden und gepackt werden. Irgendwelche Dokumentation muss dazu getan werden. Und das haben wir dann schlussendlich irgendwann mal endlich automatisiert.
10:21
Also Release-Archiv mit packen, mit kompilieren, mit testen, mit Dokumentationen dazutun. Diese Dokumentation, die da automatisiert erzeugt wird, enthält unter anderem einen Testbericht. Das da ist so ein kleiner Ausschnitt. Das war ursprünglich auch die Aufgabe von einer von
10:42
Mitarbeiterinnen, die Entwicklerin ist. Und das hat drei, vier Stunden gedauert, einen so einen Testbericht zu machen. Das dauert lange, das läuft auch tatsächlich lange. Aber drei, vier Stunden Handarbeit ist auch keine schöne Sache. Und jetzt erzeugen wir den einfach jede Nacht. Und wenn da irgendwas nicht in Ordnung ist, dann merken wir das jetzt und nicht einen Tag, bevor wir das Release ausliefern müssen.
11:04
Wir haben eine Sprintumgebung eingeführt, wo der Software-Partner testen kann. Da läuft bei uns auf einem Server, auf einem Red Hat, das sehr ähnlich ist zu dem Industriepartner-Umgebung, eben eine Instanz von unserer Software und da testet das Software-Unternehmen, zum Beispiel die neuen Schnittstellen und so weiter.
11:20
Und das tatsächlich hat auch weiter geholfen. Und da haben wir noch automatisiert, dahin zu deployen. Das heißt, es gibt irgendwie zwei Klicks und dann kommt der neue Master einfach kompiliert auf diese Sprintumgebung. Dokumentation. Bei der Dokumentation hatten wir so mittelfiel Wahl.
11:41
Wir haben ein Wiki, das von Confluence und das entsprechende Ticket-System, Jira, das gibt es bei uns im Institut und wir verwenden das auch. Das Ticket-System ist eine gute Form mit dem Software-Entwickler zu kommunizieren, weil die sehr klare Vorstellungen haben, welche Features die wollen. Ist aber für so Forschungsfragen nicht so eine schöne Kommunikationsform.
12:01
Ja, wir müssen immer wieder Release-Notes schreiben. Wir müssen eine Design-Dokumentation schreiben. Also eine, wie ist all unser Code aufgebaut, was arbeitet wie, mit was zusammen. Und das war ein sehr aufwendiges Unterfangen, das wir sehr spät angegangen haben. Und das hat zum einen keinen Spaß gemacht und zum anderen nicht so richtig was gebracht. Der Industriepartner hat es nämlich dann doch nicht gelesen, weil der interessiert sich gar nicht
12:21
für die Code-Interner. Und wir wussten die schon. Wir hatten ja vorher schon den Code geschrieben. Also wenn ihr das vermeiden könnt, dann lasst das. Oder schreibt es eher vorher als Planung, wie ihr was aufbauen wollt. Was sehr geholfen hat mit der ganzen Fluktuation von Mitarbeitern und Mitarbeitern war,
12:41
How-To-Artikel zu schreiben. Was muss man alles tun, wenn man was releasen will? Ich muss irgendwelche Versionen im Git checken. Ich muss irgendeinem Industriepartner Bescheid sagen. Ich muss auf irgendeinem Meeting dieses Release ankündigen. Das sind alles kleine Schritte. Die alle sind trivial. Aber irgendwas vergisst man da doch immer. Auf jeden Fall diese Checklist. Ich darf die irgendwie aus rechtlichen Gründen
13:00
nicht im vollständigen Text zeigen, hat meine Chefin gesagt. Es gibt eine sehr, sehr lange Checklist, was man alles tun muss in den vier Wochen vor so einem Release. Das hat gut geholfen. Was wir noch haben ist für unser Interface eine mehr oder weniger grafische Web-Ansicht. Die benutzen wir, um mit dem Industriepartner und dem Softwareunternehmen zu reden. Das funktioniert wesentlich besser,
13:20
als wirklich die reine Definition, die Schema tatsächlich anzugucken. Dann gibt es ein paar Sachen, die wir ausprobiert haben, die ich nicht so richtig technisch einordnen kann. Wir hatten vorher, haben alle alles gemacht, gefühlt. Und das hat so halb gut funktioniert. Und dann hat unsere Arbeitsgruppenleitung
13:41
irgendwann gesagt, wir teilen das jetzt hier auf. Wir haben ein Prognoseteam, wir haben ein Navi-Team und wir haben hier das Backend- oder Release-Team. Und hat die Leute auch in entsprechenden Räumen zusammengesetzt und durchaus entsprechende Meetings auch gemacht. Und das hat sehr, sehr gut funktioniert. Ab dem Moment, wo sich Leute für das Release verantwortlich gefühlt haben und auch eine einzelne Person durchaus dafür benannt war. Wir machen jetzt hier,
14:00
du bist Release-Management, du sorgst dafür, dass das läuft, hat das wesentlich besser funktioniert, als am Anfang, wo wir so mit zwölf Leuten versucht haben, das jetzt noch schnell auf die neue Schnittstelle hochzuheben und nie so richtig klar war, wer muss das jetzt alles noch machen. Release-Meetings waren verschieden erfolgreich und verschieden nervig. Ich weiß nicht, ob irgendwer
14:21
mal in der Wirtschaft war und sowas Agiles gemacht hat mit Stand-ups und so. Und man muss nicht stehen, man kann trotzdem kurze Meetings haben. Und diese Release-Meetings funktionieren sehr gut, wenn wir die nach Bedarf machen. Also kurz vor den Releases häufiger und sonst eher sehr selten. Und wenn dann nicht das Forschungsteam da ist, also wir haben sowieso einen Arbeitsgruppen-Treffner,
14:40
können wir mit denen diskutieren, wenn wir das brauchen. Und die sind aber sehr genervt davon, wenn wir jetzt unsere Details über irgendwelche Web-Server-Konfigurationen mit denen auch noch mitbesprechen. Und dann hat unser Prof zweimal jemanden wirklich von einer professionellen Arda-Firma eingeladen, der mit uns eine Woche Workshop gemacht hat. Das war auf jeden Fall sehr hilfreich,
15:02
neue Sachen über die Programmiersprache, die wir alle vorher nicht kannten, zu lernen und die sinnvoller zu verwenden. Ja, zu den Tools. Wir haben so eine witzige Programmiersprache, Arda. Kennt das jemand? Habt ihr schon mal jemand benutzt? Oh, ich bin überrascht. Und auf der anderen Seite haben wir Python-Code.
15:21
Der wird nur zur Forschung benutzt, der darf nicht ausgeliefert werden. Das heißt, manchmal müssen wir Python-Code übersetzen. Es gibt auch Teile, die das Software, andere Software-Unternehmen wieder übersetzen, Arda oder NC. Zur Versionskontrolle benutzen wir Git. Da gibt es nicht viel zu diskutieren. Und ja, wir haben Jenkins laufen, um eben diese ganzen Tests und Merges abzudenken,
15:41
zusammen mit einem GitLab. Zum Testen benutzen wir Robot und PyTest. Das kombiniert sich ganz gut und lässt sich super über Jenkins einbinden. Um den Arda-Code dann zu checken, benutzen wir von Arda-Core eben so verschiedene Gnatt-Tools für statische Code-Analyse zum Code-Formatieren.
16:00
Und für sehr große Testinstanzen benutzen wir Rubberband mit iPad. Aber da gibt es in der nächsten Session von Franziska Schlösser und Matthias Mittenberger noch einen Talk zu. Das ist eine Web-Ansicht, Datenbank und Framework, mit dem man verschiedene Rechenlaufe anstößen kann und die Ergebnisse gegeneinander auswerten.
16:21
Also die benutzen das, um sehr große LP-Instanzen zu vergleichen. Und wenn sie ihren LP-Solver aktualisieren, rauszufinden, ob jetzt Instanzen schneller geworden sind für richtig große Datenbanken. Das benutzen wir auch für unsere Navi-Instanzen. Jetzt kann ich glaube ich schlussendlich sagen, was richtig, wirklich geholfen hat, sind Code-Reviews,
16:40
also mit einer anderen Person über den Code zu sprechen. Da lernt man auch Dinge über schönen Code schreiben, über verständlichen Code schreiben. Die automatischen Regressionstests. Damit haben wir so viele Fehler gefunden, so viele Bugs, die wir nie ausgeliefert haben. Und dann Sachen automatisiert machen, die lange dauern und nervig sind. Sobald sich irgendwas nervig anfühlt, automatisieren.
17:01
Was tatsächlich nicht geholfen hat und was für mich überraschend war, war eben mit anderen Leuten direkt darüber zu reden, was guter Code ist. Oder wie wir Code-Wart mal machen. Oder sich diese freiwegen Code-Analysetools anzusehen. Und dann eine Design-Doku über den Aufbau unserer Software zu schreiben. Da habe ich auch bisher kein Nutzen gesehen.
17:20
Vielen Dank. Ja, gut, wieder Zeit aufgeholt. Dankeschön nochmal für den Vortrag. Aber gibt es denn noch Fragen? Ja, da gibt es viele. Ich glaube, da ganz hinten. Joachim, mal als erstes. Diskussion über guten Code
17:41
ist unwirksam. Andererseits gemeinsame einheitliche Formatierung ist nützlich. Wie kommt man denn dahin? Muss man nicht erst diskutieren? In welchem Stil codieren wir, bevor man es vereinheitlicht? Okay, ja. Zum Formatieren gab es Diskussionen verschieden viel.
18:01
Bei Ada gibt es die bieten ein Tool an. Gnatt ist ein Pretty Printer. Und da gibt es eben irgendwie 50 Sachen einzustellen. Und da sind wir die Liste durchgegangen, was wir da abweichend für den Stein einstellen können. Dann für Python gibt es eigentlich einen Standard PEP8, glaube ich. Das wäre der Standard, den man benutzen sollte. Unser Team mag den nicht so. Und auch da haben wir uns
18:21
auf einen anderen Formatierer geeinigt und da unsere Abweichung demokratisch ausgewählt. Das wäre gut gewesen, das früher zu machen. Also bei Python haben wir das irgendwie zu spät gemacht. Ja, ich weiß nicht. Also vielleicht ein bisschen gemein zu sagen, guter Code-Vorträge helfen nicht.
18:40
Ich glaube, es ist einfach nur in den Hintergrund gerückt gegenüber all dem anderen Stress, der da war, zu releasen und Paper zu schreiben und zu forschen. Es war einfach, ist den Mathematikern und Mathematikerinnen hinten runtergerutscht. Also die wissen das schon. Die sagen auch, ja, ich weiß, eigentlich sieht das nicht gut aus, wenn man die da auch anschaut.
19:03
Was ist denn ein Beispiel für ein No-Go bei einer statischen Code-Analyse? Was da als Fehler geschmissen wird? Zyklomatische Komplexität ist, glaube ich, mein Lieblingsbeispiel. Also verschiedene Komplexitätstypen werden untersucht. Die zyklomatische wird bei uns irgendwie am meisten gerissen
19:20
und bei uns ist irgendwie 10 erlaubt. Die sind das irgendwie, ist das ein normaler Programm? Durchlauf hat eine 1. Für jedes if oder fall Unterscheidungen darf man noch mal 1 oder drauf addieren und für den loop auch ganz grob. Länge von Funktionen zum Beispiel einfach oder von gesamten Klassen. Dann ist Ader relativ typensicher.
19:41
Das heißt, unsere statische Code-Analyse meckert, weil man einfach nur integer oder sowas benutzt. Dann möge man bitte gleich also einen Typen für definieren, für was man da überhaupt so zählt. Wenn man uneindeutige Ranges hat, das wird analysiert, ob das ist nicht mehr statisch. Ja, es meckert zum Beispiel an, wenn zu wenig Kommentare da sind.
20:13
Ganz viele Fragen, aber eine, die mir wirklich auf der Seele wird, ist so ein bisschen die Frage, das ist ja ein Zwiespalt,
20:21
glaube ich. Ich habe das noch nicht so ganz verstanden. Auf der einen Seite wird geforscht, auf der anderen Seite machen sie eine Industrie. Das ist Auftragsforschung oder so. Ist das wie? Also die Frage für mich ist an der Stelle, wie kommen Sie eben mit diesem Zwiespalt möglicherweise klar? Oder ist das kein Zwiespalt? Fällt die Industriearbeit quasi so ab? Aber das ist ja auch nicht so, weil da gibt es ja eben
20:40
jemand, der dann offensichtlich nochmal Schnittstellenteste durch diese Komponenten, die da gemacht werden, eben halt dann auch nochmal geguckt werden. Das kann ja sehr orthogonal sein, was man da dann macht für die Industrie, also für den Industriepartner einerseits und eben halt das, was dann für die Forschung irgendwie dann abfällt oder so. Das ist ja nicht immer die gleiche Richtung, die da gegangen wird.
21:00
Wie gehen Sie damit um? Das sind sehr unterschiedlich. Oder wie wird damit umgegangen, sagen wir mal so? Ja, genau. Wir gehen da sehr unterschiedlich mit um. Also für die Prognose haben wir sehr viel von dem Forschungscode released und den nach und nach ausgebessert und umstrukturiert. Und zwar also das Forschungsteam hat den ursprünglich geschrieben, auch in Ada, und eben das Release-Team hat den dann aufgeräumt,
21:21
sagen wir mal so. Und für das Navi ist das völlig anders gelaufen. Die programmieren halt einfach in Python und es gibt ein Softwareunternehmen, die deren Paper tatsächlich in eine neue Software übersetzen. Der Code wird gar nicht benutzt, sondern wird komplett neu geschrieben, und zwar nur das, was wirklich dann verwendet wird. Ok, das heißt, an der Stelle gibt es da
21:41
auch eine klare Trennung von dem Industrieteil und dem Forschungsteil an der Stelle, oder? Ja, es gibt eine klare Trennung. Also ja, es gibt eine eindeutige Übertragung. Eine kleine Frage, vielleicht nur sei erlaubt. Wer ist auch die Idee, Ada gekommen, Ada zu nehmen oder so? Das war unser Professor.
22:01
Ah, ok. Also ich hatte mal von einem Projekt gehört nach dem Motto, das muss ungefähr so und so. Ich meine, das wäre auch so dieser Kontext gewesen. Und die erste Sache, da muss man Ada nehmen und dann geht das alles ganz gut. Aber das war also das war das war so eine strategische Entscheidung, die jemand anders gefällt hat, sagen wir mal so. Also mehr oder weniger ein Webserver oder Restful API in Ada geschrieben.
22:22
Das ist nicht so schön, dass ja, dass vielleicht auch eine Lesson lernt, die Tools ein bisschen nach der Funktion auszusuchen. Ok, danke. Ok, danke.