Anspruchsvolle Software entwickeln — Jonathan Kelley, Dioxus Labs & Cognition
AAI Engineer
컴퓨터/소프트웨어창업/스타트업
스크립트
00:00:00Hallo, mein Name ist Jonathan Kelly, und heute sprechen wir darüber, was es bedeutet, ambitionierte
00:00:18Software im Zeitalter der KI zu entwickeln. Vor fünf Jahren habe ich den allerersten Commit für ein Projekt
00:00:25namens Dioxys gemacht. Ich nutzte den letzten Sommer meines Bachelorstudiums und statt eines Praktikums
00:00:31bei Google oder KI-Forschung, wie viele meiner Freunde damals, verbrachte ich ihn damit, eine Idee
00:00:37für ein plattformübergreifendes App-Framework in der Programmiersprache Rust zu erforschen. 2021 war Rust
00:00:45noch ziemlich Nische, aber das Ökosystem wuchs, die Tooling-Landschaft verbesserte sich, und das Versprechen von nativer
00:00:51Leistung, einem soliden Typsystem und einfacher Kreuzkompilierung hat mich absolut überzeugt. Es ist extrem
00:00:57nerdig. Die Idee hinter Dioxys war unkompliziert: Was wäre, wenn wir ein tatsächlich gutes plattformübergreifendes
00:01:05App-Framework hätten? Statt mich durch Dutzende Toolchains, Programmiersprachen und IDEs zu wühlen,
00:01:11was wäre, wenn wir all unsere Apps einfach in Rust schreiben und HTML sowie CSS als Auszeichnungssprache nutzen würden? Das war
00:01:19damals im Jahr 2021, als React Native ruckelig war, Flutter zu langsam und keines von beiden gut mit
00:01:25nativen APIs funktionierte. Auf der anderen Seite konnten wir mit Rust native Apps direkt ohne VM, ohne IPC und ohne JavaScript bauen, und wenn wir ein wenig HTML und CSS für das UI verwendeten und uns
00:01:40von React für die Reaktivität inspirieren ließen, konnten wir riesige Mengen an Webkomponenten und Web-Tools wiederverwenden. Das Ziel war ein extrem leistungsstarkes App-Framework, das dem durchschnittlichen Entwickler dennoch vertraut vorkam.
00:01:52Klingt einfach, oder? Nun, wie man so schön sagt, wir beschließen, ein App-Framework von Grund auf zu entwickeln, nicht weil es einfach ist, sondern weil wir dachten, es wäre einfach. In Wirklichkeit ist es extrem ambitioniert, React Native und Flutter herauszufordern. Im Jahr 2021 gab es nur sehr wenige vorgefertigte Komponenten. Im Jahr 2021 gab es nur sehr wenige vorgefertigte Komponenten. Im Jahr 2021 gab es sehr wenige
00:02:09vorgefertigte Komponenten, die man zum Aufbau von Dioxys nutzen konnte. Alles von der Reaktivität über das Font-Rendering bis hin zu Hot Reloading und Application Bundling musste von Null auf aufgebaut werden. Es gab nichts, was wir verwenden konnten.
00:02:21Für uns waren Aufgaben wie das Bauen eines Webbrowsers einfach notwendige Schritte auf diesem Weg.
00:02:29Heute, im Jahr 2026, hat Dioxys seine ursprüngliche Mission erreicht und weit übertroffen. Wir unterstützen alle Funktionen, die wir uns ursprünglich vorgenommen hatten – von plattformübergreifender Unterstützung über natives Rendering bis hin zu Rust Hot Reload und Bundle Splitting. Wir haben im Grunde den gesamten App-Entwicklungs-Stack neu erfunden und verbessert.
00:02:49Nutzer können eine leistungsstarke Full-Stack-Webanwendung in genau derselben Codebasis veröffentlichen und Komponenten mit ihren iOS- und Android-Apps teilen.
00:02:59Das Dioxys-Projekt zählt mittlerweile fast 37.000 Sterne auf GitHub und Millionen von Downloads. Mit Dioxys erstellte Apps sind weltweit im Einsatz, mit einer geschätzten kumulierten Summe von über 200 Millionen Endnutzern.
00:03:13Nutzer haben Dinge wie KI-Assistenten, Abstimmungssoftware, Data-Science-Tools und sogar Antikollisionssysteme für Satelliten im Weltall entwickelt.
00:03:23Wir haben enorm viel Arbeit hineingesteckt, um Dioxys so benutzerfreundlich wie möglich zu machen.
00:03:29Weniger Dateien, einheitliches Build-Tooling, Hot Reloading, Asset-Optimierung – alles, was man für eine einfache plattformübergreifende Veröffentlichung braucht.
00:03:37Da Dioxys-Apps in Rust geschrieben sind, sind sie strukturell sehr einfach gehalten.
00:03:41Man muss nur selten auf plattformspezifischen Code zurückgreifen.
00:03:45Da alle Rust-Projekte ähnlich aufgebaut sind, fällt es Entwicklern leicht, sich in ein neues Projekt einzuarbeiten.
00:03:50Man kann lästiges Setup des Build-Systems komplett überspringen.
00:03:54Alles, was man für den Start braucht, ist eine main.rs.
00:03:58Eines unserer ambitioniertesten Ziele für Dioxys war es, unsere eigene schlanke, aber voll ausgestattete HTML- und CSS-Rendering-Engine namens Blitz herauszubringen.
00:04:08Wir haben die CSS-Engine auf Browser-Niveau aus Firefox extrahiert, unser eigenes HTML und DOM gebaut und eine hybride GPU-Rendering-Pipeline entwickelt.
00:04:16Im Vergleich zu Electron-Apps, die echte RAM- und Speicherfresser sind, sind Blitz-Apps leichtgewichtig mit Paketgrößen von unter 5 Megabyte und verbrauchen zur Laufzeit weniger als 50 Megabyte RAM.
00:04:28Und sie sind ziemlich cool.
00:04:29Man kann eigene Komponenten schreiben, rotierende Würfel erstellen und den Browser nach Belieben anpassen.
00:04:33Es ist ein wirklich cooles Projekt.
00:04:35Wir haben auch an einem Tool namens SubSecond gearbeitet, unserer universellen Hot-Reload-Engine für Rust, C und C++.
00:04:42SubSecond überwacht den Code auf Änderungen, kompiliert geänderte Teile neu und patcht die laufende App an Ort und Stelle – und das in nur 100 Millisekunden.
00:04:51Das war eine unglaublich schwierige technische Herausforderung und ist die einzige Hot-Reload-Engine für nativ kompilierten Code mit einer so breiten
00:04:58Sprach- und Laufzeitunterstützung.
00:05:00Sie funktioniert auf allen gängigen Betriebssystemen und sogar im Web, wo Rust zu WebAssembly kompiliert wird.
00:05:04Das hat vor uns noch niemand gemacht.
00:05:06Ich erwähne das, weil diese Projekte, an denen wir in den letzten fünf Jahren gearbeitet haben, unglaublich ambitioniert sind und das Resultat eines kleinen, aber fähigen Teams aus genialen Ingenieuren.
00:05:18Wir haben akribisch auf Qualität geachtet, jede Zeile Code mit eigenen Augen gelesen und einen zügigen, aber ambitionierten Release-Takt eingehalten.
00:05:27Das Faszinierendste daran: Jede Codezeile in Dioxys wurde bis vor Kurzem mühsam von Hand geschrieben.
00:05:35Warum sage ich bis vor Kurzem?
00:05:38Nun, falls Sie es noch nicht mitbekommen haben: Softwareentwicklung und -design haben sich in den letzten sechs Monaten drastisch verändert.
00:05:45KI-Coding-Agenten sind wirklich verdammt gut geworden, und vor allem sind sie verdammt gut in Rust geworden.
00:05:51Unser Team – eine Truppe eingefleischter Rust-Entwickler – stand KI lange Zeit sehr skeptisch gegenüber.
00:05:58Wir hatten sozusagen noch keine AGI gespürt und nutzten KI definitiv nicht in unserer täglichen Arbeit.
00:06:05Wir dachten, diese beiden Dinge seien unvereinbar: qualitativ hochwertigen Code schreiben und agentenbasierte Coding-Tools verwenden.
00:06:11Zu sehen, wie gut sie darin wurden, Rust zu schreiben, war eine Riesenüberraschung für uns, und schließlich waren wir begeistert.
00:06:18Mit dieser neu entfachten Begeisterung fingen wir an zu bauen.
00:06:21Unser Team reizte seine Cloud-Code-Abos voll aus, spulte Zehntausende Zeilen Rust herunter
00:06:25und baute alle möglichen Funktionen, die wir uns schon lange gewünscht hatten.
00:06:28Leider erfüllte nur ein Bruchteil dieses Codes unseren Qualitätsstandard für die Frage: Sollten wir das mergen?
00:06:35Tausende Zeilen neuer Features, Bugfixes und Integrationen, die wir uns jahrelang gewünscht hatten,
00:06:41lagen dort als Entwurf und blieben auch dort liegen.
00:06:45Wir wussten definitiv nicht, wie man diese Werkzeuge richtig einsetzt,
00:06:48und es war viel zu leicht, zu dem zu werden, was wir eine „Schrottkanone“ nennen.
00:06:54Also haben wir etwas nachgedacht und analysiert, was funktionierte und was nicht.
00:07:00Uns wurde klar, dass wir über all die Jahre enorm viel Mühe investiert hatten, um
00:07:04Dioxys extrem entwicklerfreundlich zu gestalten.
00:07:07Leicht zu lesen, leicht zu schreiben, gute Tools, gute Fehlermeldungen.
00:07:11Die Coding-Agenten schert das im Allgemeinen herzlich wenig.
00:07:14Wir hatten versucht, Rust für Menschen einfach zu machen, aber im Grunde spielte das keine Rolle.
00:07:18Coding-Agenten zeichnen sich bei Dioxys glücklicherweise trotzdem aus, weil Rust schwerer zu schreiben ist.
00:07:24Die Coding-Agenten nehmen Ihnen die Entwicklungslast ab,
00:07:27sie kümmern sich um Edge Cases und kämpfen mit dem Borrow Checker, womit sie Sie von der kognitiven Last befreien,
00:07:32Rust-Apps zu schreiben. Die Lernkurve, die wir abzuflachen versuchten, ist nun ein Feature.
00:07:40Während des Prozesses, Coding-Tools für die Arbeit an Dioxys zu adaptieren,
00:07:45haben wir eine Vielzahl von Lektionen gelernt. Viele Dinge, die Coding-Agenten heute wirklich gut machen,
00:07:51und bei vielen anderen sind sie einfach noch nicht so weit. In den nächsten Folien möchte ich also über
00:07:56einige unserer Erkenntnisse sprechen und darüber, was es bedeutet, ambitionierte Softwareprojekte im Zeitalter von Agenten zu bauen.
00:08:02Es ist wichtig, zunächst darüber zu sprechen, was es bedeutet, ein ambitioniertes Softwareprojekt umzusetzen.
00:08:11Es gibt viele verschiedene Arten von Software da draußen. Es hängt davon ab, was man täglich ausliefert.
00:08:17Man betreibt vielleicht Forschung, und die Qualität des Codes ist dabei nicht das Wichtigste.
00:08:22Man schreibt möglicherweise Prototypen-Code, bei dem schnelles Iterieren und rasches Vorankommen zählen.
00:08:27Man baut vielleicht Anwendungen, bei denen die Leute den internen Code nicht sehen,
00:08:30sondern nur, wie sie von außen aussehen. Aber für uns und für Dioxys
00:08:37zählen ein paar andere Dinge. In erster Linie ist uns natürlich wichtig, dass unser Code funktioniert
00:08:43und das immer, und dass wir ihn bei einem Ausfall leicht reparieren können. Ich denke, das ist etwas, worüber
00:08:48die Leute heutzutage nicht genug nachdenken: Man muss weiterhin leicht wartbaren Code schreiben,
00:08:53und die Geschwindigkeit, mit der man liefert, baut auf diesem Fundament auf, das man errichtet hat. Wenn dieses Fundament
00:08:59nicht gut ist, wird nichts, was man darauf aufbaut, gut sein. An zweiter Stelle liegt uns das Ausliefern neuer Funktionen am Herzen.
00:09:07Unsere Roadmap ist wirklich lang, sie reicht weit in die Zukunft. Es gibt Dutzende von Features, die wir für Dioxys
00:09:14noch entwickeln müssen, und wir wollen diese schnell ausliefern, um mit der Zeit zu gehen, aber wir wollen auch
00:09:20die Qualität wahren. Bei einem großen, ambitionierten Projekt wie Dioxys herrscht ein ständiger Spagat zwischen
00:09:27schnellem Ausliefern, dem Hinzufügen neuer Features und der Sicherstellung, dass man nichts kaputt macht und dass man
00:09:32in einem Patch-Release keine APIs zerstört, auf die sich Millionen von Menschen verlassen. Bei einem Projekt, auf das Anwender
00:09:39ihre Unternehmen gründen, liegt die Messlatte für Releases außerdem sehr hoch. Wir müssen die hohe Qualität unserer
00:09:46Dokumentation, unserer Beispiele, unserer Tests und unserer Benchmarks aufrechterhalten. Wenn auch nur etwas nicht stimmt,
00:09:52merken die Leute das ziemlich schnell.
00:09:56Daher schätzen wir Coding-Agenten sehr als hervorragenden Assistenten bei extrem schwierigen technischen
00:10:03Problemen. Coding-Agenten bringen eine Geduld und ein massives Wissen mit, das man als Einzelperson,
00:10:10die an einem sehr großen Softwareprojekt arbeitet, nur schwer aufbringen kann. Viele Probleme in Dioxys sind Wissensprobleme.
00:10:16Unser Team kann unmöglich jedes Detail über jedes Build-System, jede Laufzeit, jedes Betriebssystem,
00:10:23jede Programmiersprache, jede API und jede Eigenheit kennen. Zum Glück ist genau das die Stärke der Coding-
00:10:30Agenten. Sie können Tausende Seiten Dokumentation blitzschnell durchsuchen, alle maßgeschneiderten APIs lesen,
00:10:38in Binärdateien eintauchen und APIs reverse-engineeren. Sie besitzen so viel mehr Geduld als ein einzelner Entwickler.
00:10:46Wir waren in der Lage, Kotlin- und Swift-Plugins für Dioxys zu implementieren, die tief in unser
00:10:52Build-System integriert sind – was ein wirklich schweres Feature ist. Wer React Natives Turbo Modules kennt, weiß, dass diese Dinge
00:10:59von Entwicklern, die sie von Hand schreiben, über viele Jahre entwickelt wurden. Wir konnten das in etwa
00:11:05zwei bis drei Wochen mit Coding-Agenten ausliefern, und wir hätten wahrscheinlich noch schneller sein können. Ich glaube, die
00:11:08Implementierung war am ersten Tag erledigt und wir haben zwei Wochen damit verbracht, Testfälle zu bauen und auf
00:11:13Und bei Blitz, dem Ding auf der rechten Seite, unserer eigenen Web-Engine, haben Web-Agenten das Debuggen schwieriger
00:11:22CSS-Styling- und Layout-Probleme für uns beschleunigt. Die Agenten kennen die CSS-Spezifikation außergewöhnlich gut. Man schreibt vielleicht eine
00:11:28Zeile Code, die versucht, irgendein Render- oder Layout-Problem zu lösen, und die Agenten können
00:11:33sofort genau abrufen, wie Google Chrome und Safari das machen, dir den richtigen Weg zur Handhabung für
00:11:39dein Problem nennen, und du musst nicht den WebKit-Quellcode öffnen, der tief irgendwo in
00:11:45Apples Git-Repositories verschachtelt ist. Wir können Zeit investieren, um Dinge auf die richtige Art zu tun, nicht auf die schlampige,
00:11:54was interessanterweise eine Wende im Vergleich zu früher darstellt. Wir haben ein Projekt immer nach
00:12:00seiner Komplexität bemessen und neigten als Menschen dazu, Abkürzungen zu nehmen, um Dinge schneller auszuliefern, aber nicht auf einem hohen
00:12:06Qualitätsniveau. Coding-Agenten geben uns also die Möglichkeit, die Qualität zu halten und die Dinge richtig zu machen,
00:12:12was sehr interessant ist. Eine weniger aufregende Anwendung von Coding-Agenten für ambitionierte Projekte ist tatsächlich
00:12:20das Erledigen extrem eintöniger Aufgaben. Unser Team ist sehr klein. Wir haben drei Kernentwickler, die an
00:12:26Dioxys arbeiten. Jede Zeit, die wir damit verbringen, zu überprüfen, ob sich das Tarball in die richtige Verzeichnisstruktur entpackt,
00:12:33ist vertane Zeit, in der wir über die Architektur und die schwierigen Probleme unserer Software nachdenken könnten.
00:12:39Dioxys ist ein großes Projekt und es war eine Herausforderung, ein hohes Qualitätsniveau über die gesamte
00:12:44Codebasis hinweg und bei jedem Release zu halten. In einem Release fügen wir vielleicht eine Erweiterung für einen neuen Editor wie Zed hinzu.
00:12:50Wir können diesen Editor vielleicht nicht jedes Mal testen, wenn wir ein Patch-Release machen, und es ist leicht, das
00:12:55zu beschädigen. Agenten auf dieses Problem anzusetzen, erlaubt es uns tatsächlich, viele dieser schwierigen, eintönigen Aufgaben zu automatisieren,
00:13:00die zuvor unzählige Stunden gedauert hätten. Und für uns ist der Code das Produkt.
00:13:07Die Leute laden den Code herunter, bauen darauf auf, Benutzer interagieren mit ihren APIs, sie lesen unsere Dokumentation
00:13:12und bauen auf unserer Architektur auf. Jede Nachlässigkeit in der Codequalität oder den SDKs, die wir an
00:13:18Benutzer ausliefern, übersetzt sich direkt in eine schlechtere Entwicklererfahrung, und die Leute sind entweder verärgert,
00:13:24ihre Geschäfte stocken oder sie springen vom Produkt ab. Coding-Agenten waren also
00:13:30hervorragend darin, Aufgaben wie das Verifizieren von Release-Checklisten zu pflegen, Bugfixes auf stabile
00:13:36Releases zu backporten und sicherzustellen, dass unsere Dokumente und Unterlagen von extrem hoher Qualität sind. Wir schreiben zwar nach wie vor
00:13:43viele Doc-Kommentare selbst, aber es ist sehr einfach, den Agenten die Aufgabe zu geben, sicherzustellen, dass alles ordnungsgemäß dokumentiert ist,
00:13:48alles ein Beispiel hat und alles tatsächlich genau das dokumentiert, was es sagt
00:13:53und auf die Art und Weise, wie es das sagt. Als Menschen bearbeitet man eben den Code, aber man bearbeitet nicht den Kommentar. So
00:13:59sind viele deiner Kommentare mit der Zeit tatsächlich veraltet und alles wird sehr unübersichtlich.
00:14:04Und wenn man sich einfach die Zahlen anschaut, haben wir in unserer jüngsten Dioxys-Version
00:14:08mehr Patch-Releases ausgeliefert als jemals zuvor. Wir konnten also einen wöchentlichen oder mehrmals wöchentlichen
00:14:13Release-Rhythmus für ein großes, ambitioniertes Stück Software aufrechterhalten, auf eine Art und Weise, vor der wir früher bei einem
00:14:18Release zurückgeschreckt wären. Wovon ich noch nicht zu 100 % überzeugt bin – wir hatten da unterschiedliche Erfolge –, ist
00:14:28die Nutzung von KI zum Schreiben von Tests. Oder zumindest das blindlings Schreiben von Tests. Ein Bereich, in dem wir mit
00:14:35Dioxys gekämpft haben, ist das Testen. Es kann sehr schwer sein, fundamentale Software zu testen, besonders End-to-End
00:14:41für komplexe Systeme. Es ist schwer zu testen, ob sich deine Erweiterung in Zed installiert und so funktioniert, wie du
00:14:46es möchtest, ohne Zed buchstäblich zu öffnen und die Erweiterung zu nutzen. Die Coding-Agenten kämpfen
00:14:53hier bis zu einem gewissen Grad ebenfalls. Sie neigen auch dazu, etwas schlampige Tests zu schreiben. Man gibt
00:15:00ihnen einen Konstruktor und dann testen sie den Konstruktor, und das ist kein sehr interessanter Test.
00:15:03Sie können zwar leicht Tests für jede beliebige API schreiben, aber genau wie Menschen scheitern sie daran, die richtigen
00:15:10Tests zu schreiben. Also zählen wir Testbedingungen weiterhin manuell auf, erstellen Test-APIs selbst
00:15:18und handhaben Test-Runner. Aber es ist manchmal ein toller Sparringspartner, um auf Testideen
00:15:24für eine bestimmte Sache zu kommen, bei der man sicherstellen will, dass sie abgedeckt ist, und dann die Rand-
00:15:29bedingungen aufzulisten. Aber ein Bereich, in dem wir die Nutzung von Coding-Agenten fürs Testen wirklich genossen haben, ist
00:15:34das Bauen von Test-Harnesses. Fuzzing ist also ein kritischer Teil beim Bau von Software in Produktionsqualität,
00:15:42was bedeutet, deine Anwendung zu nehmen und sie Millionen verschiedener Eingaben auszusetzen, und recht oft
00:15:48auch adversarialen Eingaben, im Grunde fehlerhaften Eingaben oder Arten der Softwarenutzung, die Benutzer eigentlich nicht
00:15:55anwenden sollten, es aber tun können. Und Coding-Agenten sind hervorragend darin, diese Testumgebungen zu bauen.
00:16:03Eine Sache, die wir festgestellt haben: Code-Architektur ist nach wie vor eine Kunst.
00:16:10Coding-Agenten ermöglichen es dir, mit außergewöhnlich hoher Geschwindigkeit zu liefern. Ich erwähnte das vorhin.
00:16:15Wenn die Grundlage, auf der der Code deines Agenten landet, schlecht ist, werden auch seine Beiträge schlecht sein.
00:16:21Anders als ein menschlicher Engineer haben Coding-Agenten typischerweise keine Angst davor, sich freiwillig auf ein riesiges Refactoring
00:16:26eines Systems einzulassen oder die Architektur neu zu entwerfen, wenn ein Feature nicht ganz passt. Sie liefern meist einfach aus.
00:16:32Ein Großteil unserer Entwicklungszeit fließt inzwischen tatsächlich in das Nachdenken über Softwarearchitektur,
00:16:36darüber, welche Features wir in Zukunft wollen und wie sich das System entwickeln wird.
00:16:40Genau wie menschliche Ingenieure Spaghetticode schreiben können, können das auch die Agenten, nur eben schneller.
00:16:46Ich muss allerdings sagen, dass bei Tools auf Fable-Niveau die eigentliche Codequalität so hoch ist,
00:16:51vorausgesetzt, du kommunizierst deine Absicht richtig, dass die ordnungsgemäße Softwarearchitektur in Zukunft wahrscheinlich
00:16:57die allermeiste Zeit beanspruchen wird. Das eigentliche Schreiben von Code eher weniger.
00:17:03Eine Sache, die wir für Dioxys tun – die ihr vielleicht immer noch tut oder auch nicht –, ist, dass wir jeden PR Zeile für Zeile überprüfen.
00:17:11Wir nutzen definitiv KI-Reviews, um Bugs im Voraus zu erkennen, aber wir lesen nach wie vor gerne den Code, den wir ausliefern.
00:17:18Wir erhalten tatsächlich viele, viele PRs von Fremden. Dioxys ist ein großes Open-Source-Projekt,
00:17:24und nicht jeder PR ist gleich. Wir stellen fest, dass Benutzer ziemlich schlecht darin sein können, ihre Absicht
00:17:30den Modellen zu vermitteln. Contributor denken für gewöhnlich nicht tiefgründig darüber nach, wie sich die Codebasis im Laufe der Zeit
00:17:34entwickeln sollte. Sie wollen einfach ihren Bugfix oder ihr Feature drin haben. Und viele Lösungen werden reingeklebt.
00:17:39Wir sind also noch nicht an dem Punkt, an dem Coding-Agenten unsere Gedanken lesen können, weshalb wir nach wie vor
00:17:45durch das Medium Text eingeschränkt sind. Und so lächerlich es klingt, Prompt Engineering ist absolut real.
00:17:50Die Qualität einer Implementierung kann stark von dem Prompt abhängen, den man dem Modell gibt.
00:17:56Aber in gewisser Weise hat sich eigentlich nichts geändert. Das Lesen von Code war schon immer wichtiger als das Schreiben von Code.
00:18:02Vielleicht nicht am Anfang, aber mit der Zeit, während sich das Projekt entwickelt, auf jeden Fall.
00:18:07Meine Schlußgedanken zur Nutzung von Coding-Agenten beim Bau ambitionierter Software lauten also, dass Code inzwischen günstig ist,
00:18:14Qualität jedoch nicht. Die Aufgabe eines Softwareingenieurs bestand eigentlich nie darin, Zeilen Code auf den Bildschirm zu bringen.
00:18:22Sie bestand darin, elegante Lösungen für komplexe Probleme zu entwerfen, zehn Schritte voraus zu denken über
00:18:28die Entwicklung eines Systems, und Flexibilität angesichts sich ändernder Anforderungen zu bewahren.
00:18:34Diese Tatsachen haben sich nicht geändert, und die Messlatte für Software Engineering liegt höher denn je.
00:18:41Wenn du an den Tools der nächsten Software-Generation arbeiten möchtest: Cognition, die Leute, die
00:18:46Dioxys übernommen haben, stellen ein. Das Dioxys-Team hat sich Cognition angeschlossen, um Teil der Zukunft zu sein,
00:18:51und hoffentlich tust du das auch. Vielen Dank.
00:19:01Das Dioxys-Team hat sich Cognition angeschlossen.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기