Strg-Alt-Entf: Lernen, Legacy-Code zu lieben

Was haben Star Wars, die Tatu-Gruppe und die Strg-Alt-Entf-Kombination mit dem Legacy-Code zu tun? Was tun, wenn Sie zu einem großen Projekt kommen und auf einen Abgrund unverständlichen alten Codes stoßen? Und wie ist es effizienter, den Behörden mitzuteilen, dass sich die Arbeitskosten zur Beseitigung der technischen Schulden auszahlen?

Dylan Beattys Berichte sind nicht ohne Witze, aber diese Witze begleiten ziemlich ernsthafte Diskussionen über die wichtigsten Entwicklungsprobleme. Dies ist gut für das Ende der Konferenz geeignet: Wenn das Publikum bereits viel Hardcore gehört hat und keine Code-Folien mehr wahrnehmen kann, ist es Zeit für allgemeinere Fragen und eine helle Präsentation. Und als unsere DotNext 2018 Moscow .NET-Konferenz mit Dylans Rede über den Legacy-Code abgeschlossen wurde, gefiel es dem Publikum am besten.

Deshalb haben wir jetzt für Habr eine übersetzte Textversion dieser Rede erstellt: für Spender und für alle anderen. Zusätzlich zum Text befindet sich unter dem Schnitt eine original englischsprachige Videoaufnahme.





Hallo, ich heiße Dylan Beatty. Das Gesprächsthema liegt mir sehr nahe und ist meiner Meinung nach für alle, die an der Entwicklung von Software beteiligt sind, äußerst wichtig: Wir werden über Legacy-Code sprechen.

Zuerst werde ich ein paar Worte über mich selbst sagen. Ich habe 1992 in prähistorischen Zeiten begonnen, Websites nach den Maßstäben unserer Branche zu entwickeln. Jetzt bin ich CTO der Londoner Firma SkillsMatter. Ich habe dieses Jahr dort angefangen zu arbeiten und damit die Codebasis geerbt: 75.000 Codezeilen, die nicht von mir geschrieben wurden, wurden zu meiner Verantwortung. Ein Teil meines Berichts basiert auf dieser Erfahrung. Außerdem bin ich Microsoft MVP und Leiter der Londoner .NET-Benutzergruppe.



Was haben Doctor Who, die modernen Star Wars, Sherlock und Paddington gemeinsam? Bei der Arbeit wurde ein Legacy-Code verwendet. Ich weiß das, weil ich 15 Jahre bei Spotlight gearbeitet habe. Dies ist ein in London ansässiges Unternehmen, das ein Online-Tool für professionelle Schauspieler bietet, die in Filmen und im Fernsehen auftreten. Die von mir und meinem Team geschriebene Software wurde bei der Arbeit an allen genannten und vielen anderen Projekten verwendet.

In den neuen Star Wars mochten einige die Schauspieler nicht, andere mochten die Handlung nicht. Aber niemand kam mit den Worten "Ich mag es nicht, dass der klassische ASP für die Kreation verwendet wurde!" Aus dem Kino.

Weil es keine Rolle spielt. Diese Codebasis ist seit sehr langer Zeit in Produktion, und ja, es gibt einen klassischen ASP-Code - Code, der älter als das gesamte .NET ist -, der noch heute beim Casting für Filme und TV-Shows verwendet wird. Es ist notwendig, die Betonung richtig zu setzen: Es sind diese Filme und Fernsehsendungen, die wichtig sind, und der Code existiert nur, um Probleme zu lösen. Bis Sie es ausführen, bedeutet der Code selbst nichts. Wert entsteht nur, wenn Sie es starten und etwas damit machen. Dafür bezahlen die Leute - Netflix oder DVD. Das Problem ist, dass es sehr leicht ist, es zu vergessen.

Im Allgemeinen möchte ich heute unter anderem meine langjährigen Erfahrungen mit derselben Codebasis mit Ihnen teilen. Ich habe beobachtet, wie es sich entwickelt hat und wie andere es kennengelernt und gelernt haben, wie man es benutzt. Und die andere Seite dieser Gleichung ist meine neue Arbeit, die es mir ermöglichte, den gleichen Prozess von der anderen Seite aus zu sehen, als ich selbst den Code eines anderen kennenlernen musste.

Aber lassen Sie uns zunächst darüber sprechen, wie schnell sich die Dinge in der IT ändern.



Schauen Sie sich das allererste iPhone an - heute sieht es völlig uralt und sperrig aus. Und dieses Modell ist erst 11 Jahre alt, es erschien 2007 und kostete dann 800 Dollar. Wenn Sie 2007 eine Waschmaschine, eine Gitarre oder ein Fahrrad gekauft haben, können Sie diese heute noch benutzen. Aber das erste iPhone funktioniert nicht mehr - selbst wenn Sie eine Kopie mit einem Akku und einem Ladegerät finden, funktionieren all die Dinge, die das Smartphone zu einem so erstaunlichen Gerät gemacht haben, nicht darin.

Sie können die Karte nicht öffnen, da die Kartenserver nicht mehr vorhanden sind. Sie können nicht zu Twitter wechseln, da für die neuesten Versionen der Twitter-Anwendung eine iOS-Version erforderlich ist, die nicht auf dem iPhone 1 installiert werden kann. Der Twitter-Client antwortet Ihnen einfach: "Endpunkt nicht gefunden". Im Wesentlichen haben Sie ein Fossil in Ihren Händen. Und das einzige, was darin funktioniert, ist die Funktion eines normalen Telefons. Sie können es trotzdem anrufen. Denn in diesem Bereich haben sich im Gegensatz zur IT die Standards seit 11 Jahren nicht geändert.

Nehmen wir uns eine kleine Zeitreise. Erinnerst du dich an diesen?



Erinnerst du dich, in welchem ​​Jahr es war? Tatu trat 2003 beim Eurovision Song Contest auf. Und 2003 habe ich ASP-Code geschrieben, der heute noch in der Produktion verwendet wird.

Es scheint uns, dass dies sehr lange her ist, aber dieser Code funktioniert immer noch. Die Hersteller von Mobiltelefonen haben es geschafft, alle zwei Jahre ein neues Telefon zu kaufen, damit sie es sich leisten können, alte Entwicklungen loszuwerden, APIs, Endpunkte und Dienste zu deaktivieren. Viele Unternehmen haben jedoch keine solche Gelegenheit und unterstützen daher weiterhin den Code, der geschrieben wurde, als Tatu bei Eurovision auftrat. Dieser Code ist wichtig, da er immer noch wichtige Funktionen ausführt und Einnahmen generiert - das heißt, es handelt sich um einen Legacy-Code.

Und obwohl wir uns alle einig sind, dass Legacy existiert, bleibt die Frage: Was genau ist das? Hier ist ein Beispielcode:



Schauen Sie, denken Sie: Ist es Vermächtnis oder nicht? Was denkst du?

Ich habe das Gerät erfunden, das ich nächstes Jahr verkaufen möchte. Sie stecken es in den USB-Anschluss, wählen einen Code aus und das Gerät teilt Ihnen mit, ob es sich um ein Legacy handelt oder nicht!



Der Code, den Sie gerade gesehen haben, ist kein Vermächtnis. Es wurde vor vier Tagen von Andrey Akinshin ( DreamWalker ) geschrieben. Dies stammt aus BenchmarkDotNet.

Tatsache ist, dass es unmöglich ist, durch einfaches Betrachten festzustellen, ob der Code Legacy ist. Darüber hinaus hat der Code selbst nichts damit zu tun. Wichtig ist, was um ihn herum passiert: Menschen, Kultur, Prozesse, Tests und so weiter.

Wenn Sie den Artikel "Legacy-Code" in der englischsprachigen Wikipedia öffnen, können Sie Folgendes lesen: "Dies ist der Quellcode für das Betriebssystem oder eine andere Computertechnologie, deren Unterstützung oder Produktion eingestellt wurde." Wir sagen: "Okay." Und dann steht geschrieben: "Dieser Begriff wurde zuerst von George Olivetti in Bezug auf einen Code verwendet, der von einem Administrator unterstützt wird, der diesen Code selbst nicht geschrieben hat."



Am Ende dieses Satzes befindet sich ein Link zum Blog eines bestimmten Samuel Mullen. Wir denken: "Interessant, wir werden sehen." Aber wenn wir den Beitrag öffnen, werden wir sehen, dass sich dieser Mullen wiederum auf Wikipedia bezieht!



Und anscheinend weiß niemand sonst, wer dieser George Olivetti war. Es sieht also so aus, als sollten wir nach einer besseren Definition suchen.

Eine der beliebtesten Definitionen in der Branche wurde von Michael Faethers gegeben: „Legacy ist einfach Code ohne Tests.“ Und Michael hat ein ganzes Buch zu diesem Thema geschrieben, damit er definitiv weiß, wovon er spricht. Trotzdem stimme ich seiner Definition nicht ganz zu.

Daher verwende ich meine Definition seit mehreren Jahren: "Geerbter Code ist Code, der zu beängstigend zum Aktualisieren, aber zu profitabel zum Löschen ist."



Später stellte sich heraus, dass eine sehr ähnliche Definition bereits unabhängig von mir gegeben wurde: "Ein sehr profitabler Code, den wir nicht ändern können." Ich frage mich, woher diese Angst kommt. Was ist mit Tests, die Code ohne sie in Legacy verwandeln?

Eines der ältesten Geschäftstools der Welt ist ein doppeltes Buchhaltungssystem. Es ist viele hundert Jahre alt und darin wird jede Transaktion einer Bank oder eines Unternehmens zweimal gezählt: In einer Spalte schreibe ich auf, wie viel Geld ich bezahlt habe, und in der anderen - den Wert, den ich für sie erhalten habe. Darüber hinaus sollten die Summen beider Spalten gleich sein. Wenn eine Diskrepanz besteht, wird irgendwo ein Fehler gemacht.



Es scheint mir, dass die Grundidee dieses Ansatzes sehr wichtig erscheint: Alle Entscheidungen, die wir treffen, wirken sich zweimal aus, und wenn Sie eine Sache ändern, werden Sie an einem anderen Ort definitiv auch Änderungen haben, die überwacht werden müssen. Dieser doppelte Ansatz kann auf Code und Tests oder auf Code und ein Überwachungssystem oder auf Code und Dokumentation angewendet werden.

Viele Systeme, die wir als Legacy betrachten, existieren auch in zwei Versionen, aber dies sind Versionen "im Code und im Kopf von jemandem". Und hier liegt meiner Meinung nach eine unserer Hauptschwierigkeiten.

Ich erinnere mich an den einseitigen Comic "Deshalb sollten Sie einen Programmierer nicht unterbrechen." Der Entwickler betrachtet eine einfache Codezeile und beginnt sofort in seinem Kopf darüber nachzudenken, was jetzt im Navigationsmenü neu geschrieben werden muss, wie sich dies auf den Debugger auswirkt, der dann im Code geändert werden muss. Jemand kommt auf ihn zu und fragt: „Hast du meinen Brief erhalten?“ Und dann fliegt mir all dieser komplexe Bearbeitungsbaum aus dem Kopf.

Wenn wir arbeiten, treten wir in einen veränderten Bewusstseinszustand ein, unser Gehirn baut komplexe Modelle auf, die erklären, wie der Code funktioniert. Wenn der Code von einer Person geschrieben wird (z. B. in einem Startup- oder Open Source-Projekt), gibt es häufig außer dem Modell im Kopf und dem Modell im Code nichts. So können Sie sehr schnell arbeiten - Sie übersetzen einfach das, was Sie in Ihrem Kopf haben, in Code. Das Modell im Kopf ist korrekt. Wenn also etwas im Code nicht stimmt, schauen Sie es sich an, vergleichen Sie es mit dem im Kopf, und der Fehler wird sofort sichtbar. Und wenn Sie einen Fehler finden, zeigt dies Ihnen oft, dass Sie nicht genug über einen Aspekt nachgedacht haben, und Sie aktualisieren zuerst das Modell im Kopf und dann den Code.

Es gibt einen wunderbaren Beitrag von Jessica Kerr , in dem sie unter anderem sagt, dass Erfindung darin besteht, einen Berg hinunterzulaufen, und Analyse darin, einen Berg zu besteigen. Wir schreiben gerne Code, es ist interessant und einfach: Sie fangen bei Null an und erfinden etwas Neues, lösen Probleme, schreiben Algorithmen, Methoden und Klassen. Aber das Lesen des Codes ist schwierig - von Anfang an gibt es eine große Auswahl an Code eines anderen, und dies ist ein völlig anderes Zeichen.



Daher können Sie in vielen Organisationen ein Phänomen beobachten, das Alberto Brandolini als „Dungeon-Meister“ bezeichnet hat: Dies ist die Person, die die erste Version des Systems geschrieben hat. Ich war diese Person in Spotlight - ich habe einen wesentlichen Teil der ersten Version allein geschrieben und sie auf einem klassischen ASP geschrieben, ohne Dokumentation und ohne Komponententests. Sie haben angefangen, Filme mit diesem Tool zu machen, haben Star Wars gemacht, wir haben Geld bekommen und alles war großartig. Aber dann stellten wir neue Mitarbeiter ein, die zunächst nicht herausfinden konnten, wie das alles funktionierte, und zwei bis drei Monate lang mussten sie sich mit dem System vertraut machen.

Bald wurde darüber gesprochen, das System auf .NET zu portieren, da der klassische ASP nicht zuverlässig genug und nicht schnell genug ist. Solche Gespräche werden immer stattfinden - egal welchen Code Sie schreiben, jemand wird darauf bestehen, dass er neu geschrieben werden muss. Dies geschieht, weil diese Person Ihren Code nicht versteht und das Schreiben von neuem Code interessanter ist, als sich mit dem alten zu befassen. Programmieren ist ein Job, der Freude macht, wir mögen ihn wirklich. Daher ist es ganz natürlich, dass wir uns bei einer Auswahl für die faszinierendere Option entscheiden werden.

Der Besitzer des Dungeons ist eine Person, die alle Fallstricke im Code kennt. Er kennt die Taste, die nicht gedrückt werden kann, da sonst die Anwendung abstürzt. die, an der TODO von 2014 hängt, an die niemand ihre Hände erreicht hat. Wir in unserer Branche haben gelernt, solche Systeme nicht mehr zu entwickeln. Aus diesem Grund liebe ich Ereignisse wie DotNext, Benutzergruppe, Community und StackOverflow: Wenn Sie ein neues Projekt starten, wird Ihnen auf jeden Fall gesagt, dass Sie Tests schreiben, Spezifikationen anhand von Beispielen, Integration und Überwachung erstellen müssen. Unsere Zukunft sind also serverlose Microservices auf F # mit einer hundertprozentigen Abdeckung des Codes mit Tests.

Das Problem ist jedoch nicht die Software, die wir schreiben müssen: Unsere Welt ist bereits voller Software. Und wenn Sie sich diese Software in Form einer Pyramide vorstellen, wird serverloses F # nur ganz oben stehen. Ein bisschen mehr wird ASP.NET sein, das irgendwie in Tests behandelt wird. Noch mehr - Visual Basic unter Windows XP. Die beliebteste kommerzielle Produktentwicklungsplattform in der Geschichte sind jedoch Excel-Tabellen.



Ich bin bereit zu wetten, dass jedes Mal, wenn Sie ein Flugticket kaufen oder in einem Hotel übernachten, Ihr Name auf die eine oder andere Weise in einer Art Excel-Tabelle erscheint. Die Entwicklung durch Tests berücksichtigt dieses riesige Gepäck an bereits geschriebenem Code nicht.

Aber warum darauf bestehen, alten Code neu zu schreiben? Zuerst mögen die Leute kein klassisches ASP und sie möchten alles in .NET neu schreiben. Dann stellt sich heraus, dass Sie alles in Version 4.5, dann 4.6 und dann .NET Core neu schreiben müssen. JQuery ist nicht gut, daher sollten Sie auf jeden Fall zu Angular wechseln. Danach kommt die Zeile React, dann Vue.

Ich vermute, dass zumindest einer der Gründe hier im Streben nach Mode liegt. Wir alle kommunizieren miteinander, und ein wesentlicher Teil der qualitativ hochwertigsten Arbeit in unserer Branche wurde geleistet, weil die Autoren Anerkennung und Respekt für die Menschen ihres Berufs erreichen wollten. Es scheint mir, dass in unserer Branche eine übermäßige Abhängigkeit von allem Neuen und Glänzenden besteht und Programmiersprachen Modetrends unterliegen. Aber diejenigen, an denen die Mode von selbst vorbeigeht, haben sich in keiner Weise verändert, alle ihre Vorteile sind unverändert geblieben.

Stellen Sie sich vor, Sie haben zwei Lebensläufe vor sich:



Ich habe keinen Zweifel, welcher von ihnen für mich besser ist, um an wirklich wichtigen Problemen zu arbeiten. Wenn Sie jedoch mit Mitarbeitern der Personalabteilung oder mit Personen sprechen, die gerade einen Programmierkurs abgeschlossen haben, werden Sie feststellen, dass sie mit den Fähigkeiten des ersten Programmierers gutes Geld verdienen können, und sie betrachten die Fähigkeiten des zweiten als veraltet. Aber sie sind überhaupt nicht veraltet - es gibt immer noch viele Probleme, an denen diese Person arbeiten kann.

Ich denke, einer der Gründe für diese Einstellung ist, dass die Menschen Angst haben. Einige meiner Kollegen haben unser Team verlassen, weil sie an Angular oder NodeJS arbeiten wollten. Als ich sie fragte, warum sie es brauchten, antworteten sie, dass sie nach zwei Jahren keine Arbeit finden können, wenn sie weiterhin nur an .NET arbeiten. Ich antworte ihnen: Leute, wir haben mit unserem .NET gerade geholfen, Star Wars zu machen! Und sie sagen: Ja, aber es ist immer noch nicht Angular.

Versteh mich nicht falsch, ich respektiere ihre Entscheidung. Von Korruption kann nicht die Rede sein, nur die Menschen sorgen sich um ihre Zukunft und die Zukunft ihrer Familie, wenn sie Arbeit suchen müssen. In unserer Branche wird dieses Sicherheitsproblem normalerweise so interpretiert, dass Sie alle anderthalb Jahre alles von Grund auf neu lernen müssen, da Sie sonst an Wettbewerbsfähigkeit verlieren. Sehr oft interessieren wir uns viel mehr für Technologie an sich als für unsere Fähigkeit, Probleme zu lösen.

Neben der Angst, hier ins Hintertreffen zu geraten und obsolet zu werden, spielt Angst meiner Meinung nach eine wichtige Rolle bei der Änderung eines Systems, das Sie nicht verstehen. Sie geben Ihnen einen Code, von dem Sie nichts wissen, aber wenn etwas darin kaputt geht, liegt es in Ihrer Verantwortung, und wenn es mitten in der Nacht fällt, werden Sie geweckt. Daher entsteht Angst.



Wie wir aus denselben Star Wars wissen, führt Angst zu Wut, Wut zu Hass, Hass führt zu Leiden, Leiden führt zu JavaScript. Wie arbeiten wir mit unserer Angst und der Angst unserer Kollegen? Meiner Meinung nach gibt es drei Hauptaspekte: Verständnis , Vertrauen und Kontrolle .

Vertrauen ist sowohl das einfachste als auch das schwierigste der drei. Ich vertraue diesem Laptop, weil er während einer Präsentation nie abgestürzt ist. Sobald dies geschieht, wird mein Vertrauen in ihn verschwinden. In der englischen Sprache gibt es ein Sprichwort: "Vertrauen wird Tropfen für Tropfen gewonnen, aber durch Eimer verloren." Nach einem Monat der Arbeit mit einer Person werden Sie bereit sein zuzugeben, dass sie sich in ihrem Geschäft gut auskennt. In zwei Fällen werden Sie sagen, dass sie sich gut auskennt. In drei Fällen stimmen Sie zu, dass sie sein Geschäft sehr gut kennt. Und nach drei Monaten und einem Tag wird die Anfälligkeit für SQL-Injektionen in seinem Code aufgedeckt, und Sie werden sagen: "Ah, ich habe immer gesagt, dass er keinen Nutzen hat."

Anderen Menschen zu vertrauen ist immer schwierig, weil es immer bedeutet, ein gewisses Maß an Kontrolle aufzugeben. Das Vertrauen in den Code ist ebenfalls ein wichtiges Thema. Nachdem Sie eine bestimmte Zeit mit dem System gearbeitet haben, möchten Sie glauben, dass es Ihren Erwartungen entspricht. Ihre Betriebssysteme sind stabil und zuverlässig, und Sie hoffen, dass sie nicht fallen. Sie vertrauen den Datenbanken Ihrer Informationen und erwarten, dass diese nicht verloren gehen. Sie erwarten, dass Cloud-Anbieter den kontinuierlichen Betrieb Ihrer Website sicherstellen und die Informationen Ihrer Kunden nicht auf dem Schwarzmarkt verkaufen.

Es gibt keinen schnellen Weg, um Vertrauen zu gewinnen. Es stimmt, Vertrauen ist transitiv: Wenn ich Ihnen vertraue und Sie jemand anderem vertrauen, kann ich höchstwahrscheinlich auch dieser Person vertrauen. Wenn ich auf Ihre Meinung höre und Sie der Meinung sind, dass Sie Amazon, AWS, Azure oder Google App Engine vertrauen können, bin ich bereit zu glauben, dass dies gute Dienste sind. Es gibt jedoch keinen schnellen Weg, um Vertrauen zu gewinnen.

Kommen wir zum Verständnis . An der Universität habe ich drei Jahre Informatik studiert. Wenn Bauingenieure dem Prinzip unserer Ausbildung folgen würden, würden sie im ersten Jahr Holzschuppen bauen, im zweiten - Metall - und im dritten, fortgeschrittenen - Glas.



Im ersten Jahr haben wir kleine Programme in Lisp geschrieben, im zweiten - kleine Programme in Java, im dritten - kleine Programme in Scheme und Prolog. Wir haben keine großen Programme geschrieben und, was noch wichtiger ist, nicht versucht, sie herauszufinden.

Bauingenieure werden jedoch nicht am Beispiel von Schuppen unterrichtet, sondern müssen Wolkenkratzer, Brücken, philharmonische Gesellschaften und Gebäude wie das, in dem wir uns gerade befinden, verstehen. Diese Studenten lernen aus den größten und beeindruckendsten Projekten ihrer Branche. Und wenn sie nach dem gleichen Prinzip studiert hätten, wie sie Informatik unterrichten, hätte der Student, der vor einem echten Auftrag für einen Wolkenkratzer stand, an nichts anderes gedacht, als Schuppen übereinander zu legen, bis sich die Petronas-Türme herausstellten.



In dieser Situation befindet sich ein Student, der einen Informatikkurs absolviert, mit der Aufgabe, ein verteiltes kommerzielles Beschaffungssystem zu schreiben. Ein wesentlicher Teil der vorhandenen Software wurde ungefähr auf die gleiche Weise geschrieben. Die Leute, die es geschrieben haben, waren nicht unverantwortlich, sondern einfach unerfahren. Sie haben alles, was sie an der Universität getan haben, sehr gut gemacht, und dies hat ein falsches Selbstvertrauen geschaffen. Das war genau das, was ich einmal war, und ich bin sicher, viele von Ihnen waren auf einmal gleich. Wir haben so gehandelt: Schreiben Sie eine Webseite, erstellen Sie einen Link zu einer anderen Seite, dann zu einer anderen, kopieren Sie den Code und alle werden glücklich sein - unsere Kunden haben ein Produkt, unser Unternehmen hat Geld, wir haben einen Bonus. Fünf Jahre später schauen Sie sich diesen Albtraum an und denken: Wie könnte das geschrieben werden?

Ein Teil des Problems ist die Fähigkeit, Software zu lernen. Bauingenieure können gut Gebäude studieren, Flugzeugingenieure können gut über Flugzeuge lernen. Nehmen Sie Literatur: In Krieg und Frieden kann es 45.000 Zeilen geben (abhängig von der Veröffentlichung). Dies ist eines der größten Bücher der Welt. Es erfordert sehr ernsthafte Studien von Menschen, die sich mit Literaturkritik beschäftigen. Mit anderen Worten, das Studium eines so großen Objekts ist eine Aufgabe. Die Größe von Shakespeares längstem Stück, Hamlet, beträgt 6.000 Zeilen. Denken Sie jetzt: Der Linux-Kernel ist dreimal so lang wie War and Peace. Und wir sprechen von einem sehr kompakten Code, gut organisiert, mit umfangreicher Dokumentation und einer großen Community. Um es zu verstehen, muss man jedoch dreimal „Krieg und Frieden“ verstehen.



Schauen Sie sich diese Grafik an, die die Anzahl der Zeilen in den Büchern Hamlet, Moby Dick, Die Brüder Karamasow, Der Herr der Ringe, Atlas Shrugged und Krieg und Frieden sowie die Linux- und Mono-Kernel zeigt .

Scheint Ihnen dieses Verhältnis realistisch? Bitte vergib mir, dass ich dich irregeführt habe. Dieser Graph ist tatsächlich exponentiell.

Ein Liniendiagramm auf der nächsten Folie:



Die Idee hier ist sehr einfach: Die Software ist riesig, es ist unmöglich, sich nur hinzusetzen und sie zu lesen. Bitten Sie jemanden, sich mit dem Linux-Kernel vertraut zu machen, genauso wie Sie jemanden bitten, Krieg und Frieden, Atlas Shrugged, Der Herr der Ringe und alle Harry Potters hintereinander zu lesen. Stellen Sie sich vor, Sie sind zu einer neuen Firma gekommen, und sie sagen Ihnen ab der Schwelle, dass Sie all diese Bücher studieren müssen, und erst dann dürfen Sie den Code eingeben. Natürlich nicht.

Das Lesen des Codes kann sehr nützlich sein - Sie können verstehen, wie einige Muster funktionieren, und einige Beispiele lernen. Sie können ein großes System jedoch nicht herausfinden, wenn Sie es so lesen, wie Sie ein Buch lesen. Vielleicht hat dieser Ansatz etwas Edles, aber er führt zu nichts, wie es mir scheint. Es gibt zu viel Code und er ist schlechter geschrieben als diese Bücher.

Wenn es ineffizient ist, nur den Code zu lesen, wie kann man ihn dann richtig studieren? Erinnern Sie sich an Richard Feynman, Nobelpreisträger für Physik. Für ihn war das Thema Wissenschaftsunterricht von großer Bedeutung. Er glaubte, dass es notwendig sei, Menschen nicht Wissenschaft beizubringen, sondern wie man Wissenschaft richtig macht. Er wurde an die Universität von São Paulo in Brasilien eingeladen, weil in Brasilien Studenten sehr gute Noten erhielten, gleichzeitig aber keine High-Tech-Produktion aufgebaut werden konnte. Feynman wurde gebeten, herauszufinden, wo das Problem lag.

Mehrere Jahre lang kam er mehrere Wochen lang jedes Jahr nach Brasilien und sprach mit Studenten. Er sah, dass brasilianische Studenten zum Beispiel den Namen des Phänomens, das auftritt, wenn Druck auf einen kristallinen Körper ausgeübt wird - Tribolumineszenz - genau kannten. Aber keiner von ihnen wusste, dass, wenn Sie ein Stück Zucker mit einer Zange zu Hause in einem dunklen Raum zerdrücken, Funken durchrutschen - und das ist Tribolumineszenz. Feynman erklärte, dass die Schüler nur in Lehrbüchern geschult wurden, um Prüfungen zu bestehen, aber keine Experimente durchgeführt haben.

Meiner Meinung nach enthält dies eine wichtige Lehre für unsere Branche. , . , , , . , .

— . , , , .

— . , , . , , - .

. , . . , , .



, — , , . , , - , ? .

- , , - . .



- «I love LAMP», , , . — , , , . : , , , .

, , , . , . , DLL. , , . , — , . , , — .

— ? ? -, « - ». , , . , , . , , Wi-Fi. Wi-Fi , , , . : , , — ? Usw.

, , . , , , .



, . , , DLL api.payments.mycompany.com. DLL, , , , , DLL , . : .

, : , . . , : , .

. , , . , , . : , , , . , - , . .

Spotlight, ASP Amazon Web Services. , GitHub - « ». , , , , .

- , , . Windows 2016 , ASP, 2003 .



, , , «» , « » Windows 2016 , . ASP.NET MVC 2 , , 3, 4. DLL, , ASP.NET MVC 2, - - microsoft.com, , , Nuget , . Program Files. ASP.NET MVC 2, , .

, . , , - . , : , -?



: , , -?



, , , , . - — -, , . — . , !

, , , - — , .

, . 50 000 , . — 100 000, 200 000… , Int32. , , - id -. , - , , , int, .

, , , . — . , , , .



, , . , , 32 64, . , , . . , , , . , , . , , , .

, 80- 90-, -, , . , . , .



. , — , . , , , , . , .

, . , , . , , . , — « » . , , , . : «, - ?»

, - — , . , , . , ; , — , . . , , . , .



, . , , . , . , . , , , , — , 12 , , , 3 .

, , , . , . , , .

, — ? «definition of done»?

, , GitHub , , , .



, . , . Google Analytics , , . . - , . «», , . — , . , JavaScript, . , .

, , — , . — , 20 . — , .

: , . , . , . GitHub, . - , . : , .

-. , , , , , , , COBOL. MUMPS? , . , 1960- , 26 . — . , , - .

- , « -» « ». .



: (control), (alter) (delete) - .

Vielen Dank für Ihre Aufmerksamkeit.

, : DotNext 15-16 . .NET- ( -10 ), — , .NET Foundation. , — .