La métrique de temps de construction finale dans le livre blanc « Découvrir le meilleur framework multiplateforme grâce à l’analyse comparative » mesure le temps total nécessaire au framework pour produire la version finale de l’application de référence. Le livre blanc évalue deux frameworks prenant en charge le développement d’applications de bureau multiplateformes : Delphi et Electron .
Il s’agit du quatrième d’une série d’articles de blog examinant de plus près chacune des 26 mesures individuelles utilisées dans l’étude, et comment Delphi et Electron se sont comportés chacun sur ces mesures. Le premier se trouve ici.
Téléchargez le livre blanc complet ici
Catégorie de référence : Productivité des développeurs
La productivité des développeurs est la mesure de l’effort et du code requis pour que les développeurs effectuent des tâches de développement typiques. La productivité a un impact direct sur le temps de mise sur le marché des produits et les coûts de main-d’œuvre à long terme, de sorte que les outils qui augmentent la productivité des développeurs ont des impacts substantiels sur les délais et les résultats de l’entreprise. La productivité peut être réalisée de deux manières distinctes : des exigences de codage réduites grâce aux bibliothèques natives et des outils IDE tels que la complétion de code et la conception visuelle.
Les IDE avec une plus grande largeur de bibliothèque entraînent généralement moins de lignes de code par application et produisent une base de code propre et allégée qui minimise les opportunités de bogues ou de problèmes de maintenance plus tard dans le cycle de vie du produit.
Benchmark Metric 4/26 : temps de construction final
Temps de construction final : Nombre total d’heures nécessaires pour « accélérer » l’application à l’aide d’une solution connue. Celui-ci mesure le nombre d’actions et le volume de code requis pour compléter l’application complète par un développeur expert ayant une parfaite connaissance d’une solution de travail. Les frameworks productifs réduisent le temps de développement sur des tâches répétitives mais légèrement modifiées.
Résultats de l’analyse comparative
Score Delphi : 5 (sur 5)
Score électronique : 3 (sur 5)
Une fois terminée, l’application Electron a été « speedrunnée » en deux fois moins de temps que l’application Delphi malgré le fait qu’elle nécessitait presque deux fois plus de lignes de code tapé par le développeur. C’est en grande partie parce que l’IDE de Delphi fournit le développement d’applications visuelles [P2] via des composants glisser-déposer, ce qui réduit la complexité de la création d’interface graphique au prix d’un temps de configuration accru des composants.
Delphi a cependant fait preuve de force dans d’autres domaines. Sa base de données et son code réseau ne composaient que 46 % des lignes typées par les développeurs, contre 61 % pour Electron, ce qui indique clairement que la bibliothèque de bases de données FireDAC et les outils réseau de Delphi résument mieux ces opérations que Node.JS, réduisant ainsi les efforts des développeurs et les risques d’erreur.
Dans l’ensemble, des résultats similaires dans la phase de développement initiale ont fait apparaître Delphi et Electron comme équivalents. Cette conclusion a changé après la modification de la spécification pour ajouter des tests unitaires internes. Une fois que les entrepreneurs ont suffisamment compris les exigences du test, l’application Delphi a été modifiée et
acceptée en 8,33 heures de travail. L’application Electron, quant à elle, a mis 47,8 heures pour ajouter la même fonctionnalité. Bien que le développeur Electron ait implémenté les fonctionnalités de test dans son environnement de développement en 28,6 heures, le dépannage de diverses erreurs Javascript et de bibliothèque de base de données survenant sur les machines clientes (Windows, macOS, Linux) a presque doublé le délai de livraison du lecteur RSS modifié à 47,8 heures. .