Nous lisons souvent les meilleures pratiques de programmation, les nouvelles fonctionnalités du framework ou les nouveautés de la prochaine version de PHP. Nous lisons comment changer " ceci en ceci " , pourquoi une technique est bonne ou mauvaise, ou quel nouveau package vous pouvez utiliser dans votre projet. Mais tout cela n'est que spéculation sur le passé ou le présent.
Je terminerai la lecture du livre « of The Inevitable » , écrit par le fondateur du magazine Wired, dans lequel il ne parle que du futur. Inspiré par ce livre, je propose de regarder le futur de la programmation.
Aujourd'hui, nous luttons contre la dette technique (quoi que cela signifie), un code hérité difficile à maintenir et coûteux à modifier, mais qui génère beaucoup d'argent en même temps. Régulièrement, nous devons refactoriser le code, suivre les principes DDD, écrire des tests, mettre à jour la version PHP pour des raisons de sécurité, installer les dernières versions logicielles sur le serveur et automatiser la mise en page.
Il y a tellement de travail de routine en cours qu'il n'y a absolument pas le temps de regarder des dizaines d'autres projets que notre entreprise soutient ... ou du moins de le stocker quelque part sur nos serveurs. Nous devrions engager un expert pour aider à améliorer chaque aspect au moins légèrement. Non pas parce que ces projets sont mauvais, mais simplement parce qu'il y a tellement de technologies que nous pouvons utiliser, et encore plus de code que nous devons simplement maintenir.
Et comment tout cela se passera-t-il à l'avenir?
IDE utilisera l'intelligence artificielle
À l'avenir, la saisie du code deviendra plus facile. Notre IDE sera alimenté par l'intelligence artificielle, qui apprend des données anonymes d'autres projets PHP et de tous les projets open source sur Github et Gitlab.
Grâce à cette IA, lorsque nous commencerons à taper "class HomepageC ...", l'EDI saura que nous créons un contrôleur de page d'accueil, que nous utilisons Symfony, ainsi que sa version de composer.json, et proposera d'ajouter automatiquement des modificateurs de finalisation au reste du code et les types forts, basés sur la connaissance de la version PHP utilisée, également de composer.json. Il générera un modèle pour le moteur de modèle que nous utilisons et imitera le contenu trouvé dans d'autres modèles que nous avons déjà dans notre projet.
Grâce à l'énorme quantité de données anonymes et de données provenant de magasins de codes publics, l'IA saura comment tester au mieux le contrôleur et utilisera ces connaissances pour créer un test de contrôleur optimal.
Meilleures pratiques vérifiées
Lorsque nous parlons de «meilleures pratiques», nous ne voulons pas dire ce que moi ou quelqu'un d'autre a écrit dans un article ou un livre basé uniquement sur l'expérience personnelle. Ces opinions sont souvent basées sur les expériences de quelques projets et sont chargées d'émotion.
À l'avenir, le concept de "meilleure pratique" sera remplacé par "pratique vérifiée" et reposera sur des données réelles associées à deux indicateurs rigides - la dette technique et l'efficacité du codage. La dette technologique aura un équivalent financier qui montrera combien il en coûtera pour maintenir chaque ligne de code à l'avenir. Êtes-vous libre d'écrire du code statique sans classes typées? La chaîne peut "coûter" 10 $. Êtes-vous en train d'écrire des classes finales avec des types forts et une méthode publique? Dans ce cas, la ligne coûtera 2 $.
Ces chiffres ne seront pas aléatoires, mais seront basés sur l'analyse constante d'une quantité colossale de big data, anonyme pour tous les projets qui souhaitent utiliser cette fonctionnalité. Le code sera comparé aux coûts monétaires nécessaires pour maintenir et améliorer les projets. Grâce à ces commentaires, l'IA saura également quelle version est la plus avantageuse pour votre projet particulier.
L'IA connaîtra le contexte de votre projet et comparera les données en conséquence. Avez-vous un projet CLI? Il sera comparé avec le code d'autres projets CLI dans ce domaine. Créez-vous un site Web? Il sera comparé à des projets d'autres sites.
L'efficacité du codage sera déterminée par la métrique de «maintenabilité» du projet. Il sera mesuré sur une échelle de 0 à 100 points, où 0 signifie qu'il faut de nombreuses heures pour comprendre le code, et que des modifications peuvent prendre des jours, voire des semaines. Un code avec un score de 100 sera facile à comprendre pour un développeur junior, et il pourra changer le code presque instantanément.
Saisie automatique vérifiée par IDE
L'EDI sera au courant de ces métriques et suivra également les modèles utilisés dans votre code. Lorsque vous commencez à écrire un morceau de code dont l'efficacité est de 40 à 50 points, l'auto-complétion apparaîtra avec une suggestion de code avec la même fonctionnalité, mais avec une efficacité de 80 à 90. Ceci est similaire au travail que le recteur ou le PHPStan font aujourd'hui.
L'analyse des performances sera également effectuée avec l'analyse des performances de codage. Les performances seront automatiquement mesurées chaque fois que le code change en arrière-plan dans le conteneur Docker, et vous serez informé de toute fuite de mémoire ou augmentation du temps d'exécution. Cette analyse sera si précise qu'elle signalera la chaîne ou les caractères spécifiques à l'origine de la fuite et suggérera un correctif que vous devrez simplement accepter.
Refactoring AST
La refactorisation sera également plus puissante qu'elle ne l'est aujourd'hui. Il sera basé sur l'arbre de syntaxe abstraite (AST). L'EDI vous proposera la meilleure refactorisation que vous envisagez de faire maintenant, sur la base de données anonymes de tous les projets ouverts et fermés.
Au lieu de vous référer aux meilleures pratiques, vous saurez que:
- la solution A vous coûtera 3 $ par ligne en dette technique, et sera notée 95 pour l'efficacité et 45 pour la performance
- La solution B vous coûtera 1 $ par ligne de dette technique, avec une cote d'efficacité de 70 et une cote de performance de 50
Vous construisez une startup et souhaitez tester votre idée? Ensuite, vous choisirez l'option A. Et si votre entreprise est stable et devrait le rester à l'avenir? Ensuite, vous devriez passer à l'option B, qui est moins chère en support et en performances, mais légèrement plus lente en développement.
Vous n'aurez pas à discuter avec un collègue ou avec votre patron pourquoi vous devriez utiliser telle ou telle solution. Vous comparez les chiffres et décidez ensuite en fonction de vos priorités actuelles.
Architecture de contexte
Votre code aura une architecture contextuelle. L'IA saura quand faire la transition entre les contextes en fonction des données d'autres projets et du coût final de leur migration. Vous démarrez un projet WordPress? C'est bon. Mais que faire si votre projet devient plus populaire et que vous devez passer à un framework PHP qui répond mieux à vos besoins? L'IDE vous invitera à passer à Laravel. Un clic et vous avez terminé.
Trois ans plus tard, votre projet prend de l'ampleur et vous aurez de nombreuses tâches pour intégrer des services tiers déjà intégrés au framework Symfony. L'EDI vous invite à migrer ... cliquez ... et boum, vous êtes sur Symfony 9. Avez-vous constaté qu'il n'y avait pas assez de développeurs Symfony sur le marché pour gérer le développement de votre projet? Un clic et l'EDI transférera le projet vers un framework pour lequel il y a suffisamment de développeurs à un coût raisonnable.
Réponses versionnées StackOverflow
L'IDE analysera votre code et analysera vos habitudes de codage. Vous écrivez généralement une fonction en 15 minutes, mais maintenant cela prend presque 2 heures? Dans les années à venir, l'EDI sera si bon qu'il remarquera même une légère diminution de la vitesse d'écriture du code en quelques secondes.
L'EDI vérifiera ensuite votre code, analysera les réponses sur StackOverflow, comparera les réponses aux versions de votre composer.lock et vous suggérera d'utiliser le morceau de code spécifique qui correspond le mieux à vos besoins.
Craignez-vous que ce morceau de code soit simplement copié au hasard et qu'il casse votre projet? L'évaluation des réponses n'est plus basée sur le vote des utilisateurs, mais prend désormais en compte le pourcentage d'utilisation de la réponse si elle est intégrée avec succès dans le code du projet.
Extraits de code testés
De plus, les extraits de code sont testés quotidiennement par StackOverflow lui-même et également avant d'être copiés dans votre projet. C'est avec la version de votre environnement local, vous pouvez donc être sûr que le code fonctionnera. Les gens n'écrivent plus eux-mêmes des versions de ces réponses, comme ils le faisaient dans le passé. Le code de la réponse est mis à jour automatiquement à chaque version de la technologie ou du framework qu'il utilise. Une réponse a été donnée pour Symfony 5. Que se passera-t-il lorsque Symfony 6 sortira? L'ancien code de la réponse sera mis à jour avec la recette AST qui a été publiée avec Symfony 6. De cette façon, l'humain et l'IDE peuvent facilement travailler avec lui.
Financement basé sur les activités Open Source
Un nouveau projet sera créé qui mettra en relation des entreprises commerciales et des contributeurs open source. Le projet open source sera financé par les entreprises qui l'utilisent. Les développeurs qui contribuent seront financés par un système unique basé sur les flux d'argent entrants, sans frais supplémentaires pour couvrir les coûts.
Le financement sera mesuré à l'aide de mesures telles que l'impact des fonctionnalités, la charge de travail, le temps passé, l'efficacité du code, etc. Ainsi, le code sera développé de manière beaucoup plus cohérente que lorsqu'il a été développé par des contributeurs indépendants pendant leur temps libre. Un développeur sur un projet open source obtiendra, en fait, un emploi à temps plein financé par ce projet.
Que recevront ces entreprises en récompense? Promotion spécifique à la communauté, versions préliminaires de nouvelles versions et accès direct aux consultants experts qui ont créé les projets open source qu'ils (ces entreprises) utilisent.
Consolidation des cadres
~ 10 frameworks PHP actuellement existants seront consolidés. Les communautés autour des frameworks PHP apprendront à collaborer davantage, plutôt que de développer des copies presque identiques de frameworks avec une approche MVC.
Grâce aux migrations AST, il sera possible de basculer vers n'importe quel framework PHP. Cela réduira la sélection à 3-4 cadres. Si la migration entre les frameworks est une question de 1 clic dans votre IDE, alors il n'y aura plus de concurrence basée sur l'affirmation selon laquelle «c'est arrivé historiquement» et les habitudes, mais uniquement sur la qualité.
Réduire le nombre de frameworks conduira à leur étroitesse d'esprit - un framework excellera en API, un autre en CLI, troisième dans les sites avec une excellente UX.
Lorsque toute la communauté PHP se concentre sur moins de frameworks, cela nous permettra d'investir l'effort économisé dans le développement de nouvelles technologies et fonctionnalités.
Une seule version PHP stable
Grâce aux migrations AST automatiques, il n'y aura que deux versions de PHP - stable et dev. Étant donné que la mise à jour de tout package ou projet deviendra très rapide et bon marché, il n'y a aucune raison de ne pas mettre à jour vers la dernière version. Cela peut prendre un an ou deux à la communauté PHP pour l'accepter et garder tous les projets synchronisés. Mais lorsque cela se produit, dans un délai d'un mois après la sortie d'une nouvelle version de PHP, tout l'écosystème open source l'utilisera comme version minimale.
Mises à jour du code entièrement automatiques et instantanées
Le code PHP n'a pas besoin d'être mis à jour manuellement. Chaque version de PHP aura une "recette" de mise à jour complète basée sur AST que vous pouvez utiliser pour mettre à jour automatiquement le code de votre projet. GitHub gérera ces "recettes", donc quand une nouvelle version de PHP sera publiée, GitHub commencera automatiquement à envoyer une pull request à votre référentiel. Il y aura des mises à jour automatiques non seulement pour PHP, mais aussi pour tout framework ou package. Comme Dependabot, qui a été récemment intégré dans GitHub, mais maintenant avec une mise à jour du code et tous les problèmes de compatibilité descendante.
Upgrader GitHub
Si vous ne souhaitez pas prendre en charge tous les PR vous-même, vous pouvez vous inscrire au programme de mise à jour automatique pour que GitHub le fasse pour vous. Il mettra également à jour correctement les versions et leur SemVer.
SemVer automatisé
Il n'y aura pas de débat sur la question de savoir si le changement est une rupture de compatibilité descendante ou juste un correctif. L'IA analysera le code avant et après, et sur cette base, elle prendra des décisions. Il sera si intelligent qu'il sera en mesure de déterminer dans quelle mesure un changement donné a un impact significatif. Si cela n'affecte aucun code dans d'autres projets, il sera publié sous forme de correctif.
PHP RFC basé sur les leçons apprises
La même analyse de rupture de compatibilité descendante sera possible pour n'importe quel RFC dans le code de base PHP. Vous souhaitez suggérer des constantes typées? L'IA vous dira combien de projets parmi les 10 000 premiers sur Github seront brisés en pourcentage. Quelque chose de similaire est maintenant fait manuellement dans certaines RFC.
Repenser la rupture de compatibilité descendante
L'IA vous aidera également à générer des «recettes» de migration AST, de sorte qu'une mise à jour instantanée peut entièrement gérer l'interruption de la compatibilité descendante. Cela conduira à un changement du concept lui-même. Les interruptions de compatibilité descendante ne se produiront que lorsque les mises à jour automatiques ne peuvent pas se produire et qu'un humain est requis pour modifier le code.
Essayez RFC localement
De plus, n'importe qui peut essayer la fonctionnalité RFC localement juste après la création du PR sur GitHub. Comment? Github créera automatiquement une version temporaire avec une balise dev spéciale et poussera cette version PHP dans le registre des packages. Vous créez un RFC pour ajouter des constantes typées, le soumettre en tant que PR à GitHub, et après 1 minute, vous pouvez exécuter sudo apt-get install php-dev-typed-constant pour obtenir PHP avec ce RFC sur votre machine locale.
Ainsi, les programmeurs pourront essayer cette fonctionnalité avant d'être inclus dans le courant dominant et même avant de voter sur le RFC. Dans ce cas, même le vote sur de nouvelles fonctionnalités sera basé sur des données et une expérience réelles, et non sur des émotions, des opinions subjectives et des arguments.
Que nous réserve l'avenir?
À l'avenir, nos capacités ne seront pas limitées par notre histoire, nos choix passés ou des technologies en évolution rapide qui rendent notre code rapidement obsolète. En un seul clic, tous nos outils sont les plus avancés du marché aujourd'hui.
Cela nous permettra d'expérimenter davantage, de tester nos hypothèses et d'obtenir de vrais retours. Cela conduira à une automatisation encore meilleure des processus de codage et des inventions dans le langage, les modèles et l'architecture d'application que nous ne pouvons même pas imaginer aujourd'hui.
"La meilleure façon de prédire l'avenir est de le créer."
Bonne création!