Qu'est-ce que Star Wars, le groupe Tatu et la combinaison Ctrl-Alt-Del ont à voir avec le code hérité? Que faire lorsque vous arrivez à un grand projet et que vous tombez sur un abîme d'ancien code incompréhensible? Et comment est-il plus efficace de faire savoir aux autorités que les coûts de main-d'œuvre pour éliminer la dette technique sont payants?
Les rapports de
Dylan Beatty ne sont pas sans blagues, mais ces blagues accompagnent des discussions assez sérieuses sur les principaux problèmes de développement. Cela convient bien à la fin de la conférence: lorsque le public a déjà entendu beaucoup de hardcore et ne peut plus percevoir les diapositives de code, il est temps de poser des questions plus générales et une présentation lumineuse. Et lorsque notre conférence DotNext 2018 Moscou .NET a été complétée par le discours de Dylan sur le code hérité, le public l'a aimé le plus.
Par conséquent, maintenant pour Habr, nous avons fait une version texte traduite de ce discours: pour les donateurs et pour tout le monde. En plus du texte, sous la coupe se trouve un enregistrement vidéo original en anglais.
Bonjour, je m'appelle Dylan Beatty. Le sujet de conversation est très proche de moi et, à mon avis, est extrêmement important pour toutes les personnes impliquées dans le développement de logiciels: nous parlerons du code hérité.
Je vais d'abord dire quelques mots sur moi. J'ai commencé à développer des sites Web en 1992, selon les normes de notre industrie, à l'époque préhistorique. Maintenant, je suis CTO de la société londonienne SkillsMatter. J'ai commencé à travailler là-bas cette année, héritant ainsi de la base de code: 75 000 lignes de code non écrites par moi sont devenues ma responsabilité. Une partie de mon rapport est basée sur cette expérience. En outre, je suis Microsoft MVP et chef du groupe d'utilisateurs London .NET.
Qu'ont en commun Doctor Who, les modernes Star Wars, Sherlock et Paddington? Lors de leur travail, un code hérité a été utilisé. Je le sais car depuis 15 ans je travaille chez Spotlight. Il s'agit d'une société basée à Londres qui fournit un outil en ligne pour les acteurs professionnels agissant dans les films et à la télévision. Le logiciel, écrit par moi et mon équipe, a été utilisé dans le travail sur tous les projets mentionnés et bien d'autres.
Dans la nouvelle Star Wars, certains n'aimaient pas les acteurs, d'autres n'aimaient pas l'intrigue. Mais personne n'est sorti du cinéma avec les mots "Je n'aime pas que l'ASP classique ait été utilisé dans la création!"
Parce que ça n'a pas d'importance. Cette base de code est en production depuis très longtemps, et oui, il existe un ASP classique - un code plus ancien que l'ensemble du .NET - qui est encore utilisé aujourd'hui pour la diffusion de films et d'émissions de télévision. Il faut bien mettre l'accent: ce sont ces films et émissions de télévision qui sont importants, et le code n'existe que pour résoudre des problèmes. Jusqu'à ce que vous l'exécutiez, le code lui-même ne signifie rien. La valeur n'apparaît que lorsque vous le lancez et faites quelque chose avec. C'est ce que les gens paient - Netflix ou DVD. Le problème est qu'il est très facile de l'oublier.
En général, aujourd'hui, je veux, entre autres, partager avec vous mon expérience avec la même base de code pendant de nombreuses années. J'ai regardé comment il a évolué, comment d'autres personnes l'ont appris et ont appris à l'utiliser. Et l'autre côté de cette équation est mon nouveau travail, qui m'a permis de voir le même processus de l'autre côté, quand j'ai moi-même dû me familiariser avec le code de quelqu'un d'autre.
Mais d'abord, parlons de la vitesse à laquelle les choses évoluent en informatique.
Jetez un œil au tout premier iPhone - aujourd'hui, il a l'air complètement ancien et encombrant. Et ce modèle n'a que 11 ans, il est apparu en 2007, puis il a coûté 800 $. Si vous avez acheté une machine à laver, une guitare ou un vélo en 2007, vous pouvez toujours les utiliser aujourd'hui. Mais le premier iPhone ne fonctionne plus - même si vous parvenez à trouver une copie avec une batterie et un chargeur, tout ce qui a fait du smartphone un appareil si étonnant ne fonctionnera pas.
Vous ne pourrez pas ouvrir la carte car les serveurs de carte n'existent plus. Vous ne pourrez pas accéder à Twitter, car les dernières versions de l'application Twitter nécessitent une version iOS qui ne peut pas être installée sur l'iPhone 1. Le client Twitter vous répondra simplement: «endpoint not found». En substance, vous aurez un fossile entre vos mains. Et la seule chose qui fonctionnera est la fonction d'un téléphone ordinaire, vous pouvez toujours y faire appel. Parce que dans ce domaine, contrairement à l'informatique, les normes depuis 11 ans n'ont pas changé.
Prenons un petit voyage dans le temps. Rappelez-vous celui-ci?
Vous souvenez-vous de quelle année c'était? Tatu s'est produit au Concours Eurovision de la chanson en 2003. Et en 2003, j'ai écrit du code ASP, qui est maintenant encore utilisé en production.
Il nous semble que c'était il y a très longtemps, mais ce code fonctionne toujours. Les fabricants de téléphones mobiles ont réussi à inciter les gens à acheter un nouveau téléphone tous les deux ans, afin qu'ils puissent se permettre de se débarrasser des anciens développements, de désactiver les API, les points de terminaison et les services. Mais de nombreuses entreprises n'ont pas une telle opportunité, et donc elles continuent de soutenir le code écrit lorsque Tatu s'est produit à l'Eurovision. Ce code est important car il remplit toujours des fonctions importantes, il génère des revenus - c'est-à-dire qu'il s'agit d'un code hérité.
Et bien que nous soyons tous d'accord pour dire que Legacy existe, la question demeure: de quoi s'agit-il exactement? Voici un exemple de code:
Regardez, pensez: est-ce un héritage ou non? Qu'en penses-tu?
J'ai inventé l'appareil, je veux le vendre l'année prochaine. Vous l'insérez dans le port USB, sélectionnez un morceau de code et l'appareil vous indique s'il est hérité ou non!
Le code que vous venez de voir n'est pas hérité. Il a été écrit par
Andrey Akinshin (
DreamWalker ) il y a quatre jours. Ceci
est tiré de BenchmarkDotNet.
Le fait est qu'il est impossible de déterminer si le code est hérité en le regardant simplement. De plus, le code lui-même n'a rien à voir avec cela. Ce qui est important, c'est ce qui se passe autour de lui: les gens, la culture, les processus, les tests, etc.
Si vous ouvrez l'article «Legacy code» sur Wikipédia en anglais, vous pouvez lire ce qui suit: «Il s'agit du code source lié au système d'exploitation ou à toute autre technologie informatique, dont la prise en charge ou la production a été interrompue.» Nous sommes comme: "d'accord". Et puis il est écrit: "Ce terme a été utilisé pour la première fois par George Olivetti en relation avec un code supporté par un administrateur qui lui-même n'a pas écrit ce code."
À la fin de cette phrase se trouve un lien vers le blog d'un certain Samuel Mullen. Nous pensons: "Intéressant, nous verrons." Mais si nous ouvrons le
message , nous verrons que ce Mullen, à son tour, fait référence à Wikipedia!
Et, il semble, personne d'autre ne sait qui était ce George Olivetti. Il semble donc que nous devrions chercher une meilleure définition.
Michael Faethers a donné l'une des définitions les plus populaires de l'industrie: «L'héritage est tout simplement du code sans tests.» Et Michael a écrit un
livre entier sur ce sujet, donc il sait vraiment de quoi il parle. Mais encore, je ne suis pas entièrement d'accord avec sa définition.
Par conséquent, j'utilise ma définition depuis plusieurs années: "Le code hérité est un code trop effrayant pour être mis à jour, mais trop rentable pour être supprimé."
Plus tard, il s'est avéré qu'une définition très similaire était déjà
donnée indépendamment de moi: "un code très rentable que nous avons peur de changer". Je me demande d'où vient cette peur. Qu'y a-t-il à propos des tests qui transforment le code sans eux en héritage?
L'un des plus anciens outils commerciaux au monde est un système de comptabilité à double entrée. Il a plusieurs centaines d'années et chaque transaction d'une banque ou d'une entreprise est comptée deux fois: dans une colonne, j'écris combien d'argent j'ai payé, et dans l'autre - la valeur que j'ai reçue pour eux. De plus, les sommes des deux colonnes doivent être égales, en cas de divergence, une erreur est commise quelque part.
Il me semble que l'idée fondamentale de cette approche semble très importante: toutes les décisions que nous prenons ont leur effet deux fois, et si vous changez une chose, alors ailleurs vous aurez certainement aussi des changements qui doivent être surveillés. Cette double approche peut être appliquée au code et aux tests, ou au code et à un système de surveillance, ou au code et à la documentation.
De nombreux systèmes que nous considérons comme existants existent également en deux versions, mais ce sont des versions «dans le code et dans la tête de quelqu'un». Et là, à mon avis, se trouve l'une de nos principales difficultés.
Je me souviens de la
bande dessinée d' une page "C'est pourquoi vous ne devriez pas interrompre un programmeur." Le développeur regarde une simple ligne de code et commence immédiatement à penser dans sa tête à ce qui doit être réécrit dans le menu de navigation maintenant, comment cela affectera le débogueur, qui devra ensuite être modifié dans le code. Quelqu'un s'approche de lui et lui demande: "as-tu reçu ma lettre?", Et puis tout cet arbre complexe de retouches s'envole de ma tête.
Lorsque nous travaillons, nous entrons dans un état de conscience altéré, notre cerveau construit des modèles complexes qui expliquent le fonctionnement du code. Lorsque le code est écrit par une seule personne (par exemple, dans un projet de démarrage ou open source), souvent, à part le modèle dans la tête et le modèle dans le code, il n'y a rien. Cela vous permet de travailler très rapidement - il vous suffit de traduire ce que vous avez en tête en code. Le modèle qui est dans la tête est correct, donc si quelque chose ne va pas dans le code, regardez-le, comparez avec ce qui est dans la tête, et l'erreur sera immédiatement visible. Et lorsque vous trouvez un bug, il vous montre souvent que vous n'avez pas suffisamment pensé à aucun aspect, et vous mettez à jour le modèle dans la tête en premier, puis le code.
Il y a un merveilleux
post de Jessica Kerr , où elle dit, entre autres, que l'invention est de savoir comment descendre une montagne, et l'analyse est de savoir comment gravir une montagne. Nous aimons écrire du code, c'est intéressant et facile: vous partez de zéro et inventez quelque chose de nouveau, résolvez des problèmes, écrivez des algorithmes, des méthodes et des classes. Mais la lecture du code est difficile - devant vous depuis le tout début il y a un énorme tableau de code de quelqu'un d'autre, et c'est un caractère complètement différent.
Par conséquent, dans de nombreuses organisations, vous pouvez observer un phénomène qu'Alberto Brandolini a appelé le «maître du donjon»: c'est la personne qui a écrit la première version du système. J'étais cette personne dans Spotlight - j'ai écrit une partie importante de la première version seule, et je l'ai écrite sur un ASP classique, sans documentation et sans tests unitaires. Ils ont commencé à faire des films avec cet outil, ont fait Star Wars, nous avons eu de l'argent et tout était super. Mais ensuite, nous avons commencé à embaucher de nouveaux employés qui, au début, ne pouvaient pas comprendre comment tout cela fonctionnait, et pendant deux à trois mois, ils ont dû se familiariser avec le système.
Bientôt, les discussions ont commencé sur le portage du système vers .NET, car l'ASP classique n'est pas suffisamment fiable et pas assez rapide. De telles conversations seront toujours - quel que soit le code que vous écrivez, quelqu'un insistera pour qu'il soit réécrit. Cela se produit parce que cette personne ne comprend pas votre code, et écrire un nouveau code est plus intéressant que de plonger dans l'ancien. La programmation est un métier qui apporte du plaisir, on aime vraiment. Il est donc tout à fait naturel que, face à un choix, nous pencherons en faveur de l'option la plus fascinante.
Le propriétaire du donjon est une personne qui connaît tous les pièges du code. Il connaît le bouton qui ne peut pas être enfoncé, sinon l'application plantera; celui sur lequel TODO de 2014 s'accroche, auquel personne n'a mis la main. Dans notre industrie, nous avons appris à ne plus créer de tels systèmes. C'est pourquoi j'aime les événements comme DotNext, le groupe d'utilisateurs, la communauté et StackOverflow: lorsque vous démarrez un nouveau projet, on vous dira certainement que vous devez écrire des tests, faire des spécifications par exemple, l'intégration, la surveillance. Notre avenir est donc les microservices sans serveur sur F # avec une couverture à cent pour cent du code avec des tests.
Mais le problème n'est pas le logiciel que nous devons écrire: notre monde est déjà plein de logiciels. Et, si vous imaginez ce logiciel sous la forme d'une pyramide, alors F # sans serveur n'occupera que le sommet. Un peu plus sera ASP.NET, en quelque sorte couvert par les tests. Encore plus - Visual Basic sur Windows XP. Mais la plate-forme de développement de produits commerciaux la plus populaire de l'histoire est les feuilles de calcul Excel.
Je suis prêt à parier que chaque fois que vous achetez un billet d'avion ou séjournez dans un hôtel, d'une manière ou d'une autre, votre nom apparaît dans une sorte de feuille de calcul Excel. Le développement par le biais de tests ne prend pas en compte cet énorme bagage de code déjà écrit.
Mais pourquoi insister pour réécrire l'ancien code? Au début, les gens n'aiment pas ASP classique et ils veulent tout réécrire sur .NET. Il s'avère ensuite que vous devez tout réécrire sur la version 4.5, puis 4.6, puis .NET Core. JQuery n'est pas bon, vous devez donc certainement passer à Angular, après quoi la ligne React, puis Vue, viendra.
Je soupçonne qu'au moins une des raisons réside ici dans la poursuite de la mode. Nous communiquons tous les uns avec les autres, et une partie importante du travail de la plus haute qualité dans notre industrie a été réalisée parce que les auteurs voulaient obtenir la reconnaissance et le respect des gens de leur profession. Il me semble que dans notre industrie, il y a une dépendance excessive à tout ce qui est nouveau et brillant, et les langages de programmation sont soumis aux tendances de la mode. Mais après tout, ceux sur lesquels la mode passe, par eux-mêmes, n'ont pas changé du tout, tous leurs avantages sont restés les mêmes qu'ils étaient.
Imaginez qu'il y a deux CV devant vous:
Il n'y a aucun doute pour moi lequel d'entre eux sera le mieux pour moi de travailler sur des problèmes vraiment importants. Mais si vous parlez avec des gens des RH ou avec ceux qui viennent de terminer un cours de programmation, vous verrez qu'ils peuvent gagner beaucoup d'argent sur les compétences du premier programmeur, et ils considèrent que les compétences du second sont obsolètes. Mais ils ne sont pas du tout obsolètes - il y a encore beaucoup de problèmes sur lesquels cette personne peut travailler.
Je pense que l'une des raisons de cette attitude est que les gens ont peur. Certains de mes collègues ont quitté notre équipe car ils voulaient travailler sur Angular ou NodeJS. Quand je leur ai demandé pourquoi ils en avaient besoin, ils ont répondu que s'ils continuaient à travailler uniquement sur .NET, après deux ans, ils ne seraient pas en mesure de trouver du travail. Je leur réponds: les gars, avec notre .NET, nous avons juste aidé à faire Star Wars! Et ils disent: oui, mais ce n'est toujours pas angulaire.
Ne vous méprenez pas, je respecte leur décision. On ne peut pas parler de corruption, juste les gens s'inquiètent de leur avenir et de celui de leur famille s'ils doivent chercher du travail. Et dans notre industrie, ce problème de sécurité est généralement interprété en ce sens que vous devez tout apprendre de zéro tous les ans et demi, sinon vous perdrez votre compétitivité. Très souvent, nous nous intéressons beaucoup plus à la technologie en soi qu'à notre capacité à résoudre des problèmes.
En plus de la peur de prendre du retard et de devenir obsolète ici, à mon avis, la peur joue un rôle important dans le changement d'un système que vous ne comprenez pas. Ils vous donnent un code dont vous ne savez rien, mais si quelque chose le casse, ce sera votre responsabilité, et s'il tombe au milieu de la nuit, ils vous réveilleront. D'où la peur.
Comme nous le savons de la même Star Wars, la peur mène à la colère, la colère mène à la haine, la haine mène à la souffrance, la souffrance mène à JavaScript. Comment travaillons-nous avec notre peur et la peur de nos collègues? À mon avis, il y a trois aspects principaux: la
compréhension , la
confiance et le
contrôle .
La confiance est à la fois la plus simple et la plus difficile des trois. Je fais confiance à ce portable car il ne s'est jamais planté lors d'une présentation. Dès que cela arrivera, ma confiance en lui disparaîtra. Dans la langue anglaise, il y a un dicton, "la confiance se gagne goutte à goutte, mais se perd par des seaux". Après un mois de travail avec une personne, vous serez prêt à admettre qu'il peut être bien versé dans son entreprise, en deux, vous direz qu'il est bien versé, en trois, vous conviendrez qu'il connaît très bien son entreprise. Et après trois mois et un jour, la vulnérabilité aux injections SQL sera révélée dans son code, et vous direz: «Ah, j'ai toujours dit qu'il n'était pas utile».
Faire confiance aux autres est toujours difficile, car cela signifie toujours renoncer à un certain contrôle. La confiance dans le code est également un sujet important. Après avoir travaillé avec le système pendant un certain temps, vous voulez croire qu'il fonctionnera conformément à vos attentes. Vos systèmes d'exploitation sont stables et fiables, et vous espérez qu'ils ne tomberont pas. Vous faites confiance aux bases de données de vos informations et vous vous attendez à ce qu'elles ne les perdent pas. Vous vous attendez à ce que les fournisseurs de cloud assurent le fonctionnement continu de votre site et ne vendent pas les informations de vos clients sur le marché noir.
Il n'y a pas de moyen rapide de gagner la confiance. Certes, la confiance est transitive: si je vous fais confiance, et que vous faites confiance à quelqu'un d'autre, alors je peux très probablement faire confiance à cette personne aussi. Si j'écoute votre opinion et que vous pensez que vous pouvez faire confiance à Amazon, AWS, Azure ou Google App Engine, alors je serai prêt à croire que ce sont de bons services. Mais il n'y a pas de moyen rapide de gagner la confiance.
Passons à la
compréhension . À l'université, j'ai étudié l'informatique pendant trois ans. Si les ingénieurs civils suivaient le principe sous-jacent à notre éducation, alors la première année, ils construiraient des abris en bois, dans le deuxième - en métal et dans le troisième, en verre avancé.
Au cours de la première année, nous avons écrit de petits programmes en Lisp, dans le deuxième - de petits programmes en Java, dans la troisième - de petits programmes en Scheme et Prolog. Nous n'avons pas écrit de gros programmes et, surtout, nous n'avons pas essayé de les comprendre.
Mais les ingénieurs civils ne sont pas enseignés par l'exemple des hangars, ils sont obligés de comprendre les gratte-ciel, les ponts, les sociétés philharmoniques et les bâtiments comme celui dans lequel nous nous trouvons actuellement. Ces étudiants apprennent des projets les plus importants et les plus impressionnants de leur industrie. Et s'ils étudiaient selon le même principe qu'ils enseignent l'informatique, alors l'étudiant, confronté à une véritable commande de gratte-ciel, n'aurait pensé à rien d'autre qu'à mettre des hangars les uns sur les autres jusqu'à ce que les tours Petronas se soient avérées.
C'est dans cette situation qu'un étudiant qui termine un cours d'informatique se retrouve et se voit confier la tâche de rédiger un système d'approvisionnement commercial distribué. Une partie importante du logiciel existant a été écrite à peu près de la même manière. Les personnes qui l'ont écrit n'étaient pas irresponsables, mais simplement inexpérimentées. Ils ont très bien fait tout ce qu'ils ont fait à l'université, ce qui a créé une fausse confiance en soi. C'était exactement ce que j'étais à un moment donné et, j'en suis sûr, beaucoup d'entre vous étaient les mêmes à un moment donné. Nous avons agi comme ceci: écrire une page Web, créer un lien vers une autre page, puis une autre, copier le code et tout le monde sera content - nos clients ont un produit, notre entreprise a de l'argent, nous avons un bonus. Cinq ans plus tard, vous regardez ce cauchemar et vous vous demandez: comment pourrait-il être écrit?
Une partie du problème est la capacité d'apprendre des logiciels. Les ingénieurs civils sont bons dans l'étude des bâtiments, les ingénieurs aéronautiques sont bons dans l'apprentissage des avions. Prenez la littérature: dans Guerre et Paix, il peut y avoir 45 000 lignes (selon la publication). C'est l'un des plus grands livres du monde, il nécessite une étude très sérieuse de la part de personnes engagées dans la critique littéraire. En d'autres termes, étudier un si grand objet est un travail. La taille de la pièce la plus longue de Shakespeare, Hamlet, est de 6 000 lignes. Pensez maintenant: le noyau Linux est trois fois plus long que War and Peace. Et nous parlons d'un code très compact, bien organisé, avec une documentation complète et une grande communauté. Néanmoins, comprendre cela revient à comprendre trois fois «Guerre et paix».
Regardez ce graphique, qui montre le nombre de lignes dans les livres Hamlet, Moby Dick, The Brothers Karamazov, Le Seigneur des anneaux, Atlas Shrugged et War and Peace, ainsi que les noyaux Linux et Mono .
Ce ratio vous semble-t-il réaliste? Veuillez me pardonner de vous avoir induit en erreur. Ce graphique est en fait exponentiel.
Un graphique linéaire sur la diapositive suivante:
L'idée ici est très simple: le logiciel est énorme, il suffit de s'asseoir et de le lire est impossible. Demandez à quelqu'un de se familiariser avec le noyau Linux de la même manière que de demander à une personne de lire Guerre et Paix, Atlas Shrugged, Le Seigneur des Anneaux et tous les Harry Potters d'affilée. Imaginez que vous êtes venu dans une nouvelle entreprise, et ils vous disent depuis le seuil que vous devez étudier tous ces livres, et alors seulement vous serez autorisé à utiliser le code. Bien sûr que non.
La lecture du code peut être très utile - vous pouvez comprendre le fonctionnement de certains modèles et en apprendre quelques exemples. Mais vous ne pouvez pas comprendre un grand système si vous le lisez comme vous lisez un livre. Cette approche a peut-être quelque chose de noble, mais elle ne mène à rien, comme il me semble. Il y a trop de code et il est pire que ces livres.
Si la simple lecture du code est inefficace, alors comment l'étudier correctement? Rappelons Richard Feynman, prix Nobel de physique. Pour lui, la question de l'enseignement des sciences revêt une grande importance. Il croyait qu'il était nécessaire d'enseigner aux gens non pas la science, mais comment bien faire la science. Il a été invité à l'Université de São Paulo au Brésil, car au Brésil, les étudiants ont obtenu des notes très élevées, mais en même temps, il n'a pas été possible d'établir une production de haute technologie. On a demandé à Feynman d'aider à comprendre quel était le problème.
Pendant plusieurs années, il est venu au Brésil chaque année pendant plusieurs semaines et a discuté avec des étudiants. Il a vu que les étudiants brésiliens connaissaient parfaitement bien, par exemple, le nom du phénomène qui se produit lorsque la pression est appliquée à un corps cristallin - la triboluminescence. Mais aucun d'entre eux ne savait que si vous écrasez un morceau de sucre avec une paire de pinces à la maison dans une pièce sombre, vous verrez des étincelles passer - et c'est la triboluminescence. Feynman a expliqué que les étudiants étaient uniquement formés aux manuels pour réussir les examens, mais qu'ils n'avaient mis en place aucune expérience.
À mon avis, cela contient une leçon importante pour notre industrie. , . , , , . , .
—
. , , , .
—
. , , . , , - .
. ,
.
.
, , .
, — , , . , , - , ? .
- , , - . .
- «I love LAMP», , , . — , , , . : , , , .
, , , . , . , DLL. , , . , — , . , , — .
— ? ? -, « - ». , , . , , . , , Wi-Fi. Wi-Fi , , , . : , , — ? Et ainsi de suite.
, , . , , , .
, . , , 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) - .
Merci de votre attention.
, : DotNext 15-16 . .NET- ( -10 ), — , .NET Foundation. , — .