Effectivement, même si je ne l'ai pas précisé dans mes précédents posts, il va de soi que pour mettre en place un label, il est nécessaire de définir un protocole. Un protocole bien pensé et assez strict tout de même. Pourquoi strict? Parce que, un dév va récupérer un script labellisé (par exemple un script qui permet d'installer une FAQ entièrement paramétrable côté admin). Ce script va donc respecter le protocole. Il va l'étudier, le mettre en place pour le projet sur lequel il travaille. Puis tout fonctionne parfaitement sur son projet.
Il revient 3 mois plus tard. Il a besoin d'un autre script dans un domaine totalement différent (un scripts qui utilise les sockets: un chat par exemple). Ce script est labellisé. Cette fois, l'étude sera plus rapide et plus efficace pour lui car il reconnaîtra la méthodologie employée pour le script: modélisation d'objets, messages d'erreurs similaires, etc.
Disons maintenant, qu'il ne trouve pas de scripts labellisé qui lui conviennent. Il va aller voir dans les scripts en cours de modélisation en cours de labellisation ou non labellisé. Il en trouve un, il l'améliore et le remets en amélioré sur le serveur. L'équipe vérifie le scripts et le labellise grâce à ce dév qui connaît comment faire un script pour qu'il soit validé. Parce qu'il en aura étudié et configuré d'autres, labellisés, auparavant.
Donc je suis:
- pour être strict et rigoureux sur la labellisation
- totalement ouvert et permissif pour les scripts et langages proposés
Je dis langages proposés, car même si je suis passionné par PHP, tous les langages sont bons à prendre. Comme disait is_null qui doit être couché à l'heure ou j'écris ce post, il y a d'autres langages qui valent le coup et qui sont open source: ruby on rails, perl, des codes sources C/C++ pour Linux, etc.
Voilà mes pensées du soir quand le cerveau fonctionne à l'envers.
Partager