Kotlin
Kotlin est une langue JVM relativement nouvelle, et JetBrains se développe activement depuis 2011.
Au fil des ans, la langue a reçu une attention croissante dans la communauté Android et est devenue le sujet le plus chaud du développement Android après la conférence Google IO 2017. La conférence a annoncé qu'Android soutient officiellement Kotlin.
Malheureusement, bien qu'il y ait déjà de nombreux articles sur Kotlin, il n'y a pas beaucoup d'informations objectives, et de nombreux développeurs réfléchissent toujours à savoir si le déménagement à Kotlin est le bon chemin.
Dans le reste de cet article, je vais essayer de fournir une liste plus complète de choses à considérer lors de l'évaluation de Kotlin comme alternative à Java.
Comparaison subjective entre Kotlin et Java
"Kotlin est meilleur que Java", "Kotlin est plus lisible que Java", "la vitesse de développement de Kotlin est plus rapide que Java", des déclarations comme celle-ci manquent de support de données précises pertinentes, ils sont donc tous classés comme vues subjectives.
Une vision subjective est formée lorsqu'un développeur individuel porte un ou plusieurs jugements subjectifs sur des sujets liés à Kotlin ou Java.
Il y a des problèmes avec les jugements subjectifs suivants des développeurs:
Il n'y a aucun indicateur quantitatif associé au jugement subjectif.
Il y a de grands biais dans le jugement subjectif.
Le biais du jugement subjectif varie considérablement selon les développeurs.
Puisqu'il n'y a pas de mesures quantitatives associées aux jugements subjectifs, les perspectives fondées sur ces jugements ne reflètent que les biais que les développeurs ont déjà eu. Différents développeurs peuvent avoir des biais très différents, donc cela ne signifie pas que d'autres développeurs le pensent également.
De plus, comme il n'y a pas d'indicateurs objectifs, les différences subjectives ne peuvent pas être objectivement éliminées, ce qui conduit souvent à la «guerre des mots».
Erreur de jugement subjectif
Pour illustrer les malentendus auxquels les jugements subjectifs peuvent conduire, examinons de plus près une vision subjective très courante:
Kotlin est plus lisible que Java - d'innombrables articles sur le Web
En théorie, il est possible d'essayer de concevoir une expérience qui mesure la différence de lisibilité entre Kotlin et Java, mais pour autant que je sache, personne ne fait vraiment une telle expérience. Par conséquent, pour l'instant, cette vue n'a pas de support de données.
La syntaxe de Kotlin est l'une des raisons pour lesquelles de nombreux développeurs louent sa lisibilité. Leur logique est la suivante:
Kotlin a une meilleure syntaxe, il est donc plus lisible - d'innombrables articles sur le Web
Dans cette phrase, "meilleure grammaire" est un autre jugement subjectif, qui est lui-même discutable, mais pour éviter les arguments, nous supposons que la grammaire de Kotlin est en effet meilleure. Cependant, cela signifie-t-il que Kotlin est plus lisible?
Pour observer l'effet de la syntaxe sur la lisibilité, lisez ce paragraphe de "texte":
Au début, ce "texte" est difficile à comprendre, mais lentement, il devient plus facile à lire. Si vous le lisez deux ou trois fois, vous ne remarquerez pas qu'il est composé de lettres non standard. Pour être précis, le remplacement des lettres n'est pas un changement syntaxique, mais il montre que l'apparence devient rarement un obstacle à la lisibilité pour les lecteurs qualifiés.
Nous pouvons également étendre cet exemple à la langue naturelle. Je comprends trois langues complètement différentes. Bien qu'ils diffèrent considérablement, je trouve très difficile de lire du texte dans l'une ou l'autre langue lorsque je ne comprends pas les mots utilisés dans le texte. Une fois que j'ai connu les mots qui composent le texte et que je me suis familiarisé avec le contexte - quelle que soit la langue dans laquelle il se trouvait, je n'ai pas eu de mal à le lire.
Par conséquent, pour moi, le choix du langage n'affecte pas la lisibilité, il suffit de comprendre le contenu et le contexte.
Il en va de même pour les langages de programmation.
Lorsque nous commençons à utiliser une nouvelle langue, nous aurons un certain temps de difficulté à comprendre le code source et devons comprendre attentivement chaque structure syntaxique. Cependant, comme nous lisons et écrivons de plus en plus de code pour une langue spécifique, nous nous familiariser progressivement avec la syntaxe de cette langue, et à un moment donné, nous ne prêterons plus attention à la structure syntaxique.
J'ai moi-même eu cette expérience en plusieurs langues: Verilog, Bash, Perl, Tcl, Lisp, Java.
Sur la base de mon expérience avec les langues ci-dessus, je peux vous dire: si une personne s'adapte au code de Lisp et ne remarque plus les supports, alors la syntaxe de Kotlin ne peut pas avoir un impact ininvestible sur la lisibilité par rapport à Java, même si elle est "meilleure".
Puisque nous discutons de ce sujet, je partagerai mon jugement subjectif sur les facteurs qui affectent la lisibilité du code source.
Après avoir lu le code écrit par d'autres développeurs dans de nombreuses langues (le ci-dessus répertorie uniquement les langues dans lesquelles je maîtrise à un certain stade; j'ai utilisé plus de langues que celle-ci), je suis arrivé à la conclusion suivante: si les développeurs peuvent écrire du code à la fois lisible et compréhensible dans une langue, ils peuvent généralement écrire du code à la fois lisible et compréhensible dans d'autres langues également.
Par conséquent, le jugement subjectif que j'ai fait sur la base de ma propre expérience est que la lisibilité du code source n'a rien à voir avec la langue choisie, et cela dépend des compétences de l'écrivain de code et des compétences des lecteurs (les compétences de l'écrivain sont plus importantes).
Si vous pensez toujours que les opinions subjectives sont représentatives, au moins lire et réfléchir à ce que Robert «Oncle Bob» Martin pense dans ce billet de blog.
Comparaison objective entre Kotlin et Java
Contrairement aux comparaisons subjectives, les comparaisons objectives utilisent des indicateurs quantitatifs pour mesurer ou évaluer où Kotlin présente des avantages par rapport à Java.
L'idée de prouver objectivement si un langage de programmation est meilleur qu'un autre avec un ensemble de normes est très attrayant, mais il y a un problème: pour autant que je sache, il n'y a pas d'indicateurs objectifs généraux liés aux langages de programmation.
Étant donné que nous ne pouvons pas faire de comparaisons précises et directes, pouvons-nous comparer objectivement Kotlin et Java? capable! Nous pouvons toujours évaluer l'étendue de l'impact positif et de messagerie de la passage de Java à Kotlin, puis de comparer les résultats et de discuter de leur impact.
Pour évaluer les meilleurs résultats que Kotlin peut produire, nous ferons les hypothèses suivantes:
Les développeurs peuvent passer à Kotlin immédiatement;
Après avoir basculé à Kotlin, les développeurs ne perdent aucune compétence (par exemple, les développeurs avec deux ans d'expérience en développement Java peuvent par comme par magie deux ans d'expérience en développement de Kotlin);
Kotlin est aussi stable que Java;
Les outils Kotlin sont aussi matures que les outils Java.
En fait, aucune des hypothèses ci-dessus n'est raisonnable, mais au début, il existe un cadre idéal pour une explication facile. Ensuite, nous mettrons de côté ces hypothèses et discuterons de l'impact des effets du monde réel.
Kotlin Meilleures estimations de résultats
Suivant le modèle proposé par Steve McConnell dans le code complet, nous pouvons décomposer les activités de construction des logiciels en trois sous-activités: conception détaillée, codage et débogage, développement et test.
Kotlin a peu d'effet sur la conception de la sous-activité en détail (cette activité est généralement indépendante du langage de programmation spécifique orienté objet choisi), donc Kotlin et Java doivent faire le même effort dans cette section.
Pour autant que je sache, Kotlin n'a rien proposé de révolutionnaire sur la sous-activité des tests de développement. Par conséquent, il en va de même pour développer des tests.
Toutes les sous-activités de codage et de débogage sont laissées.
Si nous remplaçons Java par Kotlin, combien de travail puis-je économiser dans les activités de codage et de débogage? Cette question est difficile à répondre et cette valeur varie considérablement d'un programmeur (certains programmeurs utilisent plus efficacement Java). Cependant, maintenant que nous évaluons la meilleure situation, nous pourrions aussi bien supposer que le passage de Java à Kotlin peut augmenter la productivité du développeur en moyenne de 10% pendant les phases de codage et de débogage.
Une augmentation de la productivité de 10% est une valeur étonnamment irréaliste. Même si nous entrons manuellement tout le code dans un éditeur de texte, c'est irréaliste. Compte tenu des fonctions actuelles des IDE, cette valeur est encore plus irréaliste. Étant donné que certains développeurs utilisent Java plus efficacement, cette valeur n'a aucun sens.
Cela ne me dérange pas d'utiliser une telle valeur qui est à la fois irréaliste et favorable à l'évaluation de Kotlin, car je sais que peu importe à quel point elle a un positif irréaliste sur les résultats de l'évaluation, une fois que nous avons mis de côté certaines des "hypothèses idéales", les impacts négatifs qui en résultent compenseront ces effets positifs.
Donc, en termes de codage et de débogage, nous avons augmenté de 10% - à quelle vitesse fournissons-nous nos produits à nos clients?
L'image suivante provient du code du livre complet, montrant la proportion de diverses activités des projets logiciels:
Le petit projet de l'image se concentre sur les activités de construction. Les projets plus grands nécessitent plus d'architecture, d'intégration et de tests système pour garantir que le projet réussit. Cette image ne montre pas d'exigences car, contrairement à d'autres activités, le travail des exigences n'est pas une fonction de programme directe. (Albrecht 1979; Glass 1982; Boehm, Gray et Seewaldt 1984; Boddie 1987; Card 1987; McGarry, Waligora et McDermott 1989; Brooks 1995; Jones 1998; Jones 2000; Boehm et al.2000)
Code complet, deuxième édition
Selon cette image de Code complète, dans un projet logiciel plus grand (plus de 10 000 lignes), le codage et le débogage représentent moins de 20% de la charge de travail totale du projet.
Par conséquent, dans un projet logiciel plus large, l'efficacité de codage et de débogage que nous supposons est de 10%, ce qui ne peut que réduire la charge de travail totale requise pour terminer le projet de 2%.
Par exemple, un projet qui prend 5 personnes à terminer pendant des années (il s'agit d'un projet Android relativement important), 2% de la charge de travail totale est:
5 personnes - an * 12 * 4 * 5 * 0,02 = 24 (personnes - jour)
Si nous pouvions vraiment réduire la charge de travail du projet par 24 jours de personnes, ce serait une bonne raison de passer de Java à Kotlin. Cependant, nous devons nous rappeler que l'évaluation positive ci-dessus a été dérivée dans des situations idéales et était basée sur des hypothèses irréalistes.
Dans le monde réel, le passage à un autre langage de programmation a un impact inévitable, que nous évaluerons et comparerons avec l'évaluation idéalisée mentionnée ci-dessus.
Préparation des développeurs
Pour évaluer le meilleur scénario, nous supposons que les développeurs peuvent passer immédiatement de Java à Kotlin.
En fait, bien que Kotlin soit très similaire à Java, les développeurs doivent encore passer du temps à apprendre et ensuite passer du temps à peaufiner les pratiques et les outils de développement. Le temps de préparation varie d'une personne à l'autre: certains développeurs peuvent basculer entre trois ou quatre jours, tandis que d'autres peuvent prendre 10 jours ou plus.
Soyons optimistes, en moyenne, chaque développeur peut passer de Java à Kotlin en seulement 5 jours.
Un projet qui prend 5 ans à terminer aura de 3 à 5 développeurs (dans le meilleur cas). Le temps de commutation moyen pour chaque développeur est de 5 jours, de sorte qu'un projet prend du temps de commutation de 15 à 25 jours au total.
L'effort économisé en passant à Kotlin (estimation optimiste) semble être à peu près le même que l'effort total requis pour la commutation.
Perte de compétences du développeur
La capacité de travailler efficacement dans un langage de programmation spécifique est une compétence.
Nous avons discuté d'un aspect de cette compétence (lisibilité au code), mais il y en a beaucoup d'autres. Lors du passage d'une langue à une autre, certaines compétences liées à l'ancien langage de programmation peuvent être appliquées à la nouvelle langue, mais d'autres parties de la compétence sont perdues.
Pour évaluer l'impact de la perte des compétences linguistiques de programmation sur la charge de travail du projet, nous utiliserons le facteur "Expérience en langage et outil" dérivé du modèle d'évaluation COCOMO2:
Expérience en langue et en outil (LTEX)
Cette métrique est utilisée pour mesurer l'expérience des équipes de projet développant des systèmes logiciels ou des sous-systèmes à l'aide de langages de programmation et d'outils logiciels. Le développement de logiciels comprend l'utilisation d'outils pour compléter les exigences, la conception et l'analyse de l'expression, la gestion de la configuration, l'extraction de documents, la gestion des bibliothèques, le style de programme et le formatage, le contrôle de cohérence, la planification et le contrôle, etc. En plus de l'expérience en langage de programmation de projet, l'expérience des ensembles d'outils de support de projet peut également affecter les efforts de développement. L'expérience inférieure à 2 mois obtiendra une note très faible et l'expérience inférieure à 6 mois ou années recevra une note très élevée, voir le tableau ci-dessous:
Je ne sais pas de quel type de déclin il s'agit, combien de projets ont été affectés, mais mon cerveau a automatiquement traduit la combinaison de la "baisse significative des performances" en "perdue de nombreuses heures de développement".
De plus, si vous lisez les commentaires sur les notes de publication, vous remarquerez que de nombreuses personnes ont des problèmes de migration. Dans les commentaires sur la version 1.1.2, certains ont même souligné que cette version "patch" a introduit des modifications destructrices (incompatibles en arrière).
En revanche, si vous lisez les notes de version d'Oracle JDK8, vous constaterez qu'il est relativement stable. La plupart des modifications sont des améliorations de la sécurité.
Par conséquent, Kotlin est un langage instable et immature par rapport à Java - quelle sera la migration vers Kotlin sur le projet? Pour répondre à cette question, j'utiliserai le facteur de travail de la «volatilité de la plate-forme» du modèle d'évaluation Cocomo 2:
Volatilité de la plate-forme (PVOL) Ici, le terme "plate-forme" fait référence au matériel et aux logiciels complexes (OS, SGBD, etc.) qui sont appelés lorsqu'un produit logiciel effectue des tâches. Si le logiciel développé est un système d'exploitation, la plate-forme est du matériel informatique. Si le système de gestion de la base de données est développé, la plate-forme est le matériel et le système d'exploitation. Si le navigateur de texte réseau est développé, la plate-forme est le réseau, le matériel informatique, le système d'exploitation et la bibliothèque d'informations distribuées. La plate-forme comprend des compilateurs ou des assembleurs nécessaires pour prendre en charge le développement de systèmes logiciels. Comme indiqué dans le tableau suivant, si la plate-forme ne change qu'une fois tous les 12 mois, la note sera très faible, et s'il y a un changement majeur toutes les 2 semaines, la note sera très élevée:
Manuel de définition du modèle COCOMO2
Vous avez peut-être remarqué que le langage de programmation n'apparaît pas directement dans la description de ce facteur de travail, mais les compilateurs et les assembleurs apparaissent. À mon avis, cette description n'inclut pas explicitement le langage de programmation car tous les projets qui dérivent le modèle COCOMO2 utilisent un langage stable.
Étant donné que les compilateurs et les assembleurs appartiennent à ce facteur de travail, nous pouvons également déduire les langages de programmation et les outils connexes.
Sur la base de cette gamme de volatilité de la plate-forme, Java doit être «très», tandis que Kotlin devrait être «faible» ou plus. Kotlin peut avoir une note plus élevée car elle s'appuie en interne sur d'autres outils, augmentant le risque de problèmes de compatibilité.
Étant donné que "Verylow" ne fournit pas de facteur de travail, nous avons besoin d'une estimation.
En regardant la règle décroissante du facteur de "très high" à "bas", je pense que nous pouvons supposer en toute confiance que le score de "très" n'est pas supérieur à 0,82.
Sur la base de ces hypothèses (en faveur de Kotlin), si un projet nécessite une charge de travail nominale de 5 personnes par an, l'utilisation de Kotlin deviendra 1 044 personnes par jour, tandis que la charge de travail totale de l'utilisation de Java est de 984 personnes par jour.
Choisir de mettre en œuvre un tel projet utilisant Kotlin au lieu de Java augmentera la charge de travail totale de 60 personnes.
Le travail supplémentaire causé par l'instabilité du langage et de l'outil est plus de deux fois plus que le travail réduit en passant à Kotlin.
Combiner tous les facteurs
Le projet que j'ai discuté comme exemple nécessite une charge de travail nominale de 5 personnes par an.
Selon l'évaluation ci-dessus, si le projet est mis en œuvre à l'aide de Java par un développeur avec une moyenne de 1 an d'expérience de développement Java, la charge de travail totale est:
5 personnes-année * LTEX (Java) * PVOL (Java) = 984 (jour du peuple)
Si le même projet est mis en œuvre à l'aide de Kotlin par un développeur avec peu d'expérience dans le développement de Kotlin, la charge de travail totale est:
5 personnes-année * LTEX (Kotlin) * PVOL (Kotlin) * 0,98 + T_RAMP_UP = 1115 + 5 * N_DEVELOPERS (Human-Heaven)
On estime que la charge de travail supplémentaire causée par le choix de Kotlin pour remplacer Java est de 131 + 5 * n_developers (jour de l'homme).
Précautions d'évaluation
Au cours de la discussion d'évaluation, nous avons trouvé une valeur de point unique pratique pour la charge de travail liée à Kotlin et Java.
Mais en réalité, les valeurs à point unique ne sont pas du tout des estimations - ce ne sont que des suppositions. La véritable estimation doit avoir une incertitude associée. En d'autres termes, les estimations représentent des gammes de possibilités, plutôt que des valeurs de point unique.
Nous avons fini par utiliser des valeurs de point unique au lieu de plages car j'ai choisi la valeur la plus favorable pour Kotlin à partir de la plage d'estimation et converti toutes les estimations en valeurs de point unique.
Par exemple, lorsque je discute de l'impact de Kotlin sur les activités de codage et de débogage, j'ai choisi la valeur de boost de productivité maximale de 10% par rapport à la plage estimée des possibilités [-5%, 10%]. Dans d'autres cas, lorsque nous discutons du temps moyen que le développeur passe à Kotlin, j'ai choisi les 5 plus petits jours à partir de la gamme estimée de possibilités [5 jours, 21 jours].
De plus, nous avons utilisé le facteur de travail dédié au modèle d'estimation COCOMO2. Ces facteurs ne sont pas des vérités universelles, et dans le cas le plus général, il devrait également y avoir une incertitude liée. J'ai attribué à Kotlin une note plus élevée que je ne le pensais réellement, et j'espère supprimer cette incertitude de cette manière.
Inutile de dire que la valeur de point unique que nous obtenons n'est pas correcte à 100%. Pour obtenir une estimation plus complète, nous pouvons utiliser la véritable estimation de la simulation Montecarlo. Grâce à cette technique, nous pouvons observer la distribution des résultats possibles et déterminer quels résultats sont les plus susceptibles de se produire.
N'oubliez pas que puisque nous compressons les estimations dans la valeur point unique qui est la plus favorable à Kotlin, d'autres résultats possibles montreront une plus grande au-dessus de Kotlin de commutation. Par conséquent, de tous les résultats possibles, la valeur ponctuelle unique que nous avons décrite ci-dessus est la plus favorable à Kotlin.
résumé
Au début de l'article, nous montrons des jugements subjectifs qui peuvent être trompeurs pour la comparaison des développeurs des langages de programmation.
Ensuite, nous discutons des difficultés à comparer objectivement les langages de programmation et à effectuer une série d'estimations pour déterminer la charge de travail totale requise pour la pile Kotlin et la pile Java pour terminer le projet logiciel. Lorsque nous effectuons une estimation, nous utilisons toujours la valeur la plus favorable de Kotlin dans la plage d'estimation.
Grâce à notre analyse, le passage de Java à Kotlin semble entraîner une augmentation de la charge de travail totale requise pour terminer un projet logiciel.
Plus de travail signifie que les entreprises doivent dépenser plus d'argent pour passer à Kotlin pour obtenir les mêmes fonctionnalités, tandis que les utilisateurs doivent attendre plus longtemps pour obtenir le produit.
Certains développeurs peuvent être surpris et trouver ce résultat pas facile à accepter.
Après avoir considéré toutes les situations, Google a finalement décidé de prendre en charge le développement de Kotlinanroid. Google peut avoir besoin d'investissements considérables dans ce domaine - n'y a-t-il personne dans l'équipe de la plate-forme Google Cloud capable de faire une analyse similaire pour déterminer l'impact négatif du passage à une nouvelle langue?
Je pense que les employés de Google sont tous des gens très intelligents et je pense qu'ils ont fait une analyse très approfondie avant de décider de soutenir Kotlin.
Ce qui précède est tout le contenu de cet article sur la comparaison subjective et objective et l'analyse de Kotlin et Java. J'espère que ce sera utile à tout le monde. Les amis intéressés peuvent continuer à se référer à d'autres sujets connexes sur ce site. S'il y a des lacunes, veuillez laisser un message pour le signaler!