J'ai l'impression que ce qui caractérise le plus KDE et GNOME, c'est leur intégration d'un système de partage de composants. Le fait que "ca ressemble à Windows" est purement secondaire.
Les questions sont:
1. A quoi sert la réutilisabilité ?
2. Quels sont les mécanismes existants qui permettent de partager du code ?
3. A-t-on besoin de nouveaux mécanismes ?
Mes réponses sont:
1. La réutilisation doit diminuer le temps de développement.
Dans les faits, il faut faire attention à ce qu'on réutilise. La STL est un bon exemple d'ensemble cohérent de code réutilisable et extensible. Par contre, plus le composant est complexe, plus il est susceptible de contenir des bugs. En plus, agglutiner différents composants complexes contribue à l'émergence de nouveaux bugs. Je me méfie de la réutilisabilité.
2. Il existe déjà les librairies partagées. Différents programmes peuvent communiquer par différents canaux: sockets, IPC, fichiers, tubes.
3. On peut vouloir de nouveaux mécanismes de communication abstraits cachant les sockets, IPC... Quelque chose comme CORBA par exemple. Mais c'est au prix d'une lourde perte de performance.
Jetons un oeil au noyau Linux: on a un bel exemple de composants qui coopèrent plutot bien, performants, stables, portables. Pourtant, tout est écrit en C. Ce qui permet ce miracle, c'est:
- Un design propre
- Une documentation précise (ca pourrait cependant être mieux)
- Un code source accessible
- Une communication ouverte entre développeurs.
Scott Adams (Dilbert) a une idée qui me plaît bien: On doit toujours se demander si on est pas un pas trop loin. Si on passe son temps à écrire du code, c'est bien. Si on passe son temps à écrire du code qui doit permettre d'écrire du code plus vite, on est peut-être en train de perdre son temps.
# Réutilisabilité: pour ou contre ?
Posté par Johann Deneux . En réponse à la dépêche Interview de Miguel de Icaza. Évalué à 6.
Les questions sont:
1. A quoi sert la réutilisabilité ?
2. Quels sont les mécanismes existants qui permettent de partager du code ?
3. A-t-on besoin de nouveaux mécanismes ?
Mes réponses sont:
1. La réutilisation doit diminuer le temps de développement.
Dans les faits, il faut faire attention à ce qu'on réutilise. La STL est un bon exemple d'ensemble cohérent de code réutilisable et extensible. Par contre, plus le composant est complexe, plus il est susceptible de contenir des bugs. En plus, agglutiner différents composants complexes contribue à l'émergence de nouveaux bugs. Je me méfie de la réutilisabilité.
2. Il existe déjà les librairies partagées. Différents programmes peuvent communiquer par différents canaux: sockets, IPC, fichiers, tubes.
3. On peut vouloir de nouveaux mécanismes de communication abstraits cachant les sockets, IPC... Quelque chose comme CORBA par exemple. Mais c'est au prix d'une lourde perte de performance.
Jetons un oeil au noyau Linux: on a un bel exemple de composants qui coopèrent plutot bien, performants, stables, portables. Pourtant, tout est écrit en C. Ce qui permet ce miracle, c'est:
- Un design propre
- Une documentation précise (ca pourrait cependant être mieux)
- Un code source accessible
- Une communication ouverte entre développeurs.
Scott Adams (Dilbert) a une idée qui me plaît bien: On doit toujours se demander si on est pas un pas trop loin. Si on passe son temps à écrire du code, c'est bien. Si on passe son temps à écrire du code qui doit permettre d'écrire du code plus vite, on est peut-être en train de perdre son temps.