URL: https://linuxfr.org/users/sygne/journaux/publication-de-petits-projets Title: Publication de petits projets Authors: Sygne Date: 2012年05月05日T19:32:32+02:00 License: CC By-SA Tags: développeur Score: 36 Il y a long entre le script qui fonctionne à la maison et le logiciel publié ! Cela est d'autant plus long pour moi que c'est par tâtonnement que j'avance. En effet, si les tutoriels apprenant à coder sont légions, ceux qui concernent la publication du code – et les inévitables étapes préalables à cette publication – sont plutôt rares, voire inexistants. Faute d'être capable d'écrire un tel tutoriel, je partage ici mon expérience, dans l'espoir que cela puisse faire gagner du temps à ceux qui, comme moi, se donnent pour but de publier pour la première fois un petit logiciel. Ceux qui connaissent tout cela, peuvent directement passer à la partie « publication » qui, à défaut d'image, contient une requête. Préparation =========== Mise en forme des sources ------------------------- Le regard que l'on porte sur son code change radicalement lorsque l'on sait qu'il sera lu. Je constate que les bonne pratiques de programmation se perdent lorsqu'un script est modifié au moment même ou on veut s'en servir. Ainsi, je me suis vu modifier en profondeur le code source de mon logiciel, rien que pour le rendre présentable. Ce qu'il faut harmoniser est connu: noms de fonctions et de variables, contenu et place des commentaires, mise en page. Il est par contre moins souvent dit qu'il est plus efficace est de choisir un style formel et de l'appliquer sur l'ensemble des sources, que de faire cela à l'occasion. L'avantage, c'est que le style peut être décrit dans la documentation du projet, ce qui aidera les personnes désirant hacker le logiciel à se retrouver dans les sources, et cela harmonisera les contributions potentielles. Ce travail stylistique est aussi l'occasion d'effectuer une révision générale du code et de ses algorythmes, afin de le rendre plus facile à comprendre et à maintenir. Exceptions et configuration --------------------------- La gestion des exceptions et les options de configuration sont des choses dont on se soucie peu lorsqu'on est le seul utilisateur d'un logiciel, mais qui sont indispensables pour un logiciel partagé. Normalisation de l'interface ---------------------------- De même que le style du code doit être normalisé, de même, l'interface utilisateur doit être clarifiée. J'y travaille actuellement pour mon projet, et je m'aperçois que les enjeux sont importants, car une fois le logiciel publié, la liberté de modification sera limitée par l'exigence de rétro-compatibilité. L'interface doit être cohérente, mémorisable, et respecter les usages. Comme ces trois conditions ne s'articulent pas toujours très bien, il faut faire des choix. Mieux vaut, à nouveau, se donner quelques principes et les appliquer rigoureusement. Ainsi, ces principes pourront être exposés dans la documentation du projet, et l'utilisateur sera plus à même de comprendre les choix ergonomiques. Ces principes guideront en outre les développements à venir, et assureront l'harmonie future de l'interface. Documentation ------------- Ceci étant fait, il est possible d'écrire l'indispensable manuel. Outre la liste des options et la description du format du fichier de configuration, une section consacrée au style formel utilisé pour le code (voyez la section « _naming conventions_ » de groff_ms(7) à titre d'exemple), et les principes guidant les choix ergonomiques de l'interface y sont bienvenues. La documentation ne concerne pas seulement le manuel, mais aussi les fichiers inclus dans l'archive: LICENCE, README, et pour les archives les plus soignées, CHANGES et TODO. Publication =========== Ici, je me heurte à plusieurs difficultés... Que devra contenir le site présentant mon petit projet ? Une page d'accueil, avec les dernières nouvelles (redondante avec la liste des modifications incluses dans l'archive), de la documentation (redondante avec les pages de manuel cette fois), une page de téléchargement. Si je veux faciliter les retours, un système de ticket serait utile. Et si je veux faciliter la collaboration, une liste de discussion, voire une forge collaborative. Je pourrais décider de très bien faire, et déployer l'artillerie lourde: un wiki, un serveur de pages de manuel, une forge, un système de tickets. Mais pour moi qui ne connaît pas ces technologies, c'est un investissement énorme en temps pour apprendre à les utiliser, les mettre en place, et les maintenir. C'est donc totalement disproportionné pour mon projet. Je réfléchis donc à des solutions alternatives. En un sens, j'ai d'ores et déjà le contenu sous la main: j'utilise un système de gestion de versions (RCS), la documentation est faite de pages de manuel et de README. Peut-être pourrai-je penser à cette bonne vieille méthode dite de la râche, qui via un script maison, prendrait tout ça en entrée, et ressortirait un site statique, que je n'aurais qu'à pousser par ftp. Méthode un peu moins conventionnelle, peut-être pourrais-je écrire toute ma documentation dans un format x (text2tag ou autre), et produire à partir de là un site d'un côté, manuels et README de l'autre. Peut-être, finalement, existe-t-il un outil créé spécialement pour ce genre de situation. Je serais donc heureux d'avoir quelques retours sur les choix technologiques faits par ceux d'entre vous qui publient un petit projet logiciel.

AltStyle によって変換されたページ (->オリジナル) /