Categories: Archives Jobprod.comArticles tech

Développement natif ou multiplateformes, lequel choisir ?

Actuellement, beaucoup de langages et plateformes permettent de développer en multiplateforme, que ce soit .Net, Java, ou encore tous les langages interprétés. Il est vrai que la promesse de ces environnements est le fameux write once, run anywhere lancé par Java il y a plus de 20 ans maintenant. Mais est-ce toujours une bonne solution de développer en multiplateforme ?

Débloque les + belles offres tech en 10 mins

Avantages et pièges du développement multiplateformes

Les avantages de développer en multiplateforme sont assez évidents :

Avec une même base de code, vous pouvez cibler de plus nombreux utilisateurs.
Moins de coûts de maintenance si c’est bien fait, car il n’y a pas à maintenir plusieurs versions de l’applicatif.
Plus d’utilisateurs satisfaits, ce qui peut donner une image d’ouverture à l’entreprise.

Néanmoins, le développement multiplateforme contient un certain nombre de pièges. Comme il vise plusieurs plateformes cibles, il convient de tester votre logiciel sur absolument toutes les plateformes, et ce de manière exhaustive.. En effet comme d’habitude l’enfer est dans les détails. Par exemple W—–s et macOS ont un système de fichiers qui n’est pas case sensitive, alors que celui de Linux l’est. Et j’ai déjà vu des applications planter pour des problèmes de casse, en particulier en PHP !

Par conséquent, développer en multiplateforme nécessite une plus grande rigueur de programmation, et la recherche du plus grand dénominateur commun. Dans bien des cas ce n’est pas nécessairement compliqué, mais comme il est très difficile de tester de manière exhaustive une application il est indispensable d’avoir un maximum de tests automatisés pour de telles applications. Autrement dit il va falloir vous habituer à mettre des tests unitaires à tous les niveaux, ainsi que des tests d’intégration et j’en passe.

Par ailleurs, il peut être de bon aloi d’avoir des développeurs travaillant sur chacune des plateformes cibles. Par exemple si votre application vise W—–s, macOS et Linux, il est bon d’avoir des développeurs sous W—–s, d’autres sous Mac et enfin les derniers sous Linux. Ceci permet de détecter au plus vite les bugs, et comme vous le savez plus un bug est détecté tardivement plus il est difficile de le corriger. Le pire est que le bug arrive à l’utilisateur, ce qui peut causer des problèmes d’image.

Le support

Un point à ne pas négliger lorsque vous faites du développement multiplateforme est le fait que certains bugs peuvent être propres à une plateforme donnée. Par conséquent cela va nécessiter davantage de budget support pour éviter le phénomène du chez moi ça marche ™.

Le cas des applications devant accéder au matériel

Certaines applications doivent pouvoir dialoguer directement avec le matériel. C’est notamment le cas de l’application de recharge du pass Navigo. Et même si cette dernière passe par une applet Java, elle n’est pas réellement multiplateforme étant donné qu’elle utilise du code natif pour accéder au matériel.

Mais le cas le plus emblématique reste clairement celui des jeux, qui doivent pouvoir dialoguer avec la carte graphique directement. Alors certes il y a eu quelques jeux en Java, dont Minecraft, mais globalement ceux-ci sont moches ou affichent des performances déplorables. La situation est en train de changer avec le moteur Unity, mais dans l’ensemble les développeurs qui utilisent cette technologie sont les premiers à dire que porter un jeu Unity est plus complexe que cliquer sur un bouton.

Un point à ne pas négliger est qu’une bonne pratique de développement consiste à isoler la partie ayant une adhérence au système cible du reste. Autrement dit un bout de votre code va avoir une API bien définie et va accéder au système, et vous proposerez plusieurs implémentations de votre API suivant le système cible. De même il peut être utile d’utiliser des frameworks multiplateforme comme Qt ou wxWidgets pour simplifier le portage d’applications graphiques, ou du moins la SDL pour les jeux. L’idée est là encore d’avoir la plus faible adhérence au système.

Cela dit globalement faire l’effort de rendre votre application multiplateforme exigera là encore une plus grande rigueur dans le design de votre application, ce qui ne peut être que bénéfique pour sa maintenabilité future. N’oubliez pas, une application développée à la RACHE n’est que rarement maintenable dans le temps. Une amie, voulant faire développer son site à vil prix et rapidement, en a récemment fait les frais.

Alors certes dans ce cas votre application ne sera pas à proprement parler multiplateforme puisque ce ne sera pas exactement le même code qui fonctionnera partout, mais elle le sera en grande partie, et au niveau des sources. C’est d’ailleurs comme ça que tout fonctionne dans le monde Linux : la compatibilité se fait au niveau des sources, pas au niveau du binaire.

Le cas des applications Web

Les applications web sont généralement développée en HTML et Javascript, et hélas ça s’avère souvent être un bordel sans nom. L’état actuel des technologies Javascript n’y est certainement pas étranger. Par ailleurs le fait qu’il soit en l’état impossible d’écrire du code correct en Javascript n’aide pas. Pas convaincu ? Essayez ceci :


console.log('5' + 3); // 53
console.log(5 - '3'); // 2

Cela dit revenons à nos moutons : certes les navigateurs sont supposés suivre les standards pour l’HTML, le CSS et le Javascript. Mais voilà, aucun n’implémente strictement la même version de ces normes, donc faire du développement web consiste à chercher en permanence le plus petit dénominateur commun. D’autre part les bugs des différents navigateurs obligent souvent à écrire des horreurs du type :


if (IE) {
  //
} else if (Firefox) {
  //
} else {
}

Le problème empire quand on sait que certains navigateurs qui utilisent le même moteur affichent un rendu radicalement différent d’une même page ! J’ai déjà eu le cas avec Safari et Chrome il y a quelques années. Enfin les polices de caractères ne sont pas non plus forcément à négliger (et oui celles disponibles par défaut sous Linux sont hideuses).

Par conséquent le développement web doit être considéré comme multiplateforme, mais à court terme. En effet rien ne permet de garantir que le comportement du site ne va pas changer suite à une nouvelle version d’un browser. La semaine dernière j’ai ainsi eu le cas avec un changement de comportement de Chrome dans la version 54 : celui-ci prend le comportement des polices du système au lieu d’avoir le sien, au moins sous Windows. Total ceux qui avaient paramétré le navigateur pour avoir des polices à une taille de 125% ont eu l’affichage de l’application totalement cassé, et cela nous a valu bien des appels de clients mécontents…

En bref…

Hormis le cas du développement web qui est du multiplateforme avec des bouts de ficelle, développer en multiplateforme est plutôt une bonne chose, et même avec des langages natifs comme C et C++ même si pour ces derniers c’est plus compliqué. En effet ceci oblige une plus grande rigueur lors du développement et de l’architecture de votre application, ce qui est toujours très positif !

Par contre il est clair qu’en terme que le budget de support sera plus important, et que l’application mettra un peu plus de temps à sortir en version 1.0. Ceci dit une application sortant trop vite en première version s’avère bien souvent être développée trop vite, et impossible à maintenir dans le temps…

Débloque les + belles offres tech en 10 mins

Cet article vous a plu ? Vous aimerez sûrement aussi :

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn