[Débat] Vaut-il mieux unifier ou diviser ?

Salut à tous

Avec un ami on est souvent en divergence sur un sujet lorsque l’on développe des applications ensemble, la problématique est la suivante :

Vaut-il mieux unifier ou diviser ?

Ça peut être des applications, des environnements, des langages etc…

Par exemple, il vaut mieux utiliser plusieurs langages distincts pour le front, le back et la base de données ou un seul langage/environnement qui fait tout (comme Haxe notamment voir Node.js) ?

Actuellement je développe un moteur de jeu et je réfléchis à comment intégrer le système multijoueur pour que l’expérience utilisateur soit la plus simple possible.

Mon ami me recommande de séparer les scripts côté client des scripts côté serveur alors que moi je pense qu’il vaudrait mieux regrouper en un seul composant qui définit un comportement et que le moteur se charge de déterminer ce qu’il faut transférer ou non aux autres clients.

De même pour le système d’animation : personnellement je pense qu’il est préférable d’intégrer tous les changements d’état d’une même animation dans un seul composant (du style Unity) alors que mon ami préfère les dissocier via des événements (genre plusieurs scripts qui captent onAnimationPlay('anim1') et qui modifient l’animation initiale).

Qu’en pensez-vous ?

Salut,

Je n’ai pas d’arguments techniques à avancer, d’autant qu’il s’agit du domaine du web, néanmoins je suis d’avis que, de manière générale, il vaut mieux diviser. Globalement, plus un programme se voit ajouter des fonctionnalités et plus il est sujet aux dysfonctionnements et devient difficile à maintenir (cela ne veut bien entendu pas dire que c’est infaisable, les contre-exemples ne manquent pas, c’est une simple observation). Je suis partisan de la philosophie sur laquelle Unix s’est appuyé : un programme pour une tâche et qui réalise bien cette tâche.

A vrai dire, ça ne fait que déplacer une partie du problème. Au fond, même si ton système fait beaucoup de choses, il y a fort à parier qu’en interne il soit en réalité découpé en petits sous-systèmes qui sont relativement indépendants les uns des autres.

Au final, si ton système est découpé "à la Unix" ou découpé dans ton architecture, le problème global est le même. C’est l’interaction des tâches qui rend la tâche globale difficile à analyser.

Il n’y pas de réponse toute faite.
Ça dépends, même si de manière générale, il faut mieux diviser son code, on préférera unifier les technologies.

En fait je te rejoins à 100% dans le fait qu’il faille diviser une application/un programme en plusieurs modules/fichiers.

En réalité ma question portait plus sur l’expérience utilisateur au niveau de "l’utilisation d’un service".

Je m’explique en reprenant ton exemple :

Unix a été conçu avec des petits programmes, chacun effectuant une tâche précise (on conçoit en divisant). Cependant, tous ces programmes peuvent être interconnectés par le biais de pipes, l’utilisation de Unix est donc unifiée en un seul système.

C’est sur ce deuxième aspect que la problématique se pose

+1 pour plutôt favoriser la division.

Vers 2015 j’ai eu un petit projet de stage avec Meteor. C’est une plate-forme dans laquelle on développe entièrement en JavaScript, côté client comme côté serveur (le serveur avec Node.js évidemment). Les codes serveur et client étaient tellement bien imbriqués les uns dans les autres qu’il devenait parfois difficile de savoir quoi exactement était exécuté où. C’est vite de la prise de tête inutile pour bien comprendre ce que fait l’application, et c’est aussi un flou dangereux pour la sécurité. Donc franchement je recommande pas l’approche.

C’est valable dans les deux sens, donc les plate-formes qui te proposent d’écrire du Java ou du Python transpilés en JS pour le client, je pense que c’est tout autant une mauvaise idée, si elles ne délimitent pas clairement ce qui doit être exécuté à quel endroit. Si tu utilises le même langage pour le serveur et le client, sépare au moins très clairement les choses pour qu’il n’y ait jamais la moindre ambiguïté. Tu te féliciteras de ce choix le jour où tu devras sérieusement débugger.

Pour les composants graphiques, la tendance est plutôt à la division aussi. On préfère avoir plein de petits composants connectés entre eux qui font chacun des petites choses, plutôt qu’une grosse boîte noire usine à gaz qui fait tout (y compris ce qu’on ne veut pas). C’est beaucoup plus maintenable à long terme. Attention toutefois à ne pas tomber dans l’excès de division, à l’image du module is_odd de npm… c’est difficile de dresser une limite, à chacun ses sensibilités.

Du côté du multijoueur, en plus du flou client/serveur que je te conseille fortement t’éviter à tout prix, rappelle-toi que tout ce qui est dans les mains du client est potentiellement cheatable/hackable. Les vieux loups du PHP te diront "Never trust user input"; En d’autres termes, tant que c’est possible, je conseillerais la logique du client stupide. J’ai un jeu online moi-même et cette logique m’a bien réussi en tout cas. Note tout de même qu’en disant ça, je vais à l’encontre de ce que tout le monde prone actuellement avec les SPA….

Je peux aussi t’affirmer que tout ce qui est potentiellement piratable dans un jeu le sera très probablement un jour. certains joueurs passent leur temps à chercher des failles; toujours; tout le temps. En mettant un maximum de logique sur le serveur, on limite grandement la marge de manoeuvre des tricheurs.