2014-02-12 Travailler à plusieurs sur le même projet informatique
La principale difficulté lorsqu'on travaille à plusieurs sur le même programme survient lorsqu'on doit agréger les modifications de plusieurs personnes. On part d'un même programme, on le modifie chacun de son côté et on essaye quelques jours plus tard de réconcilier les deux versions. C'est souvent laborieux et ça peut introduire quelques erreurs.
Une solution peut déjà être d'avoir un emplacement qui détient toujours la bonne version. Par exemple, hubiC vous propose d'avoir un répertoire distant (donc pas chez soi) synchronisé avec un répertoire local de son ordinateur. Ce même répertoire peut être synchronisé avec un autre répertoire local sur un autre ordinateur. De cette façon, dès que quelqu'un modifie un fichier, les autres contributeurs récupèrent les modifications (à condition d'être connecté).
Même si c'est pratique, ce genre de solution ne permet pas de revenir en arrière ni même de visualiser les modifications de chacun. Pour cela, on peut utiliser un système de suivi de source tel que GitHub, ce que j'ai fait pour pyensae, qui permet de voir les différences. Ce service n'est pas totalement gratuit (voir GitHub Pricing, BitBucket Pricing). Avant d'essayer, il est préférable de lire cette page : Fork A Repo. Si vous n'aimez pas trop les lignes de commande, il est possible de coupler cela avec TortoiseGit.
GitHub fonctionne à la fois avec une interface graphique que suppléent quelques instructions en ligne de commande comme mettre à jour son fork avec les modifications du répertoire forké :
git fetch upstream git merge upstream/master
Même si ces outils facilitent la vie, quelques règles simples lors de l'implémentation d'un programme évitent de la compliquer inutilement.
Ecrire des petites fonctions
Parce que :
- Il est plus facile de corriger un programme qui est constitué de petites fonctions plutôt que de quelques grandes. Chaque fonction peut être vérifiée séparément.
- Il est plus facile de réutiliser des petites fonctions qui font quelque chose de précis.
- Il est plus facile de répartir le travail sur plusieurs personnes.
Eviter les variables globales
Elles sont en quelque sorte des paramètres cachés, le genre de petits détails qu'on oublie. Et lorsqu'on fait du multi-threading, on se souvient pourquoi il fallait les éviter.
Séparer calcul et interface graphique
Parce que :
- Il est plus facile de vérifier un calcul s'il est dans une fonction indépendante plutôt que caché dans le code d'une interface graphique.
- C'est facile de faire un calcul une fois lorsqu'un utilisateur appuie sur un bouton, si on veut faire ce calcul cent fois, on ne peut pas lui demander d'appuyer cent fois sur le même bouton.
- Les calculs peuvent être utilisés dans d'autres programmes sauf s'ils sont coincés dans l'interface graphique.
Tests unitaires
Ce sont des petites fonctions qui vérifient les entrées et sorties d'une autre. On les exécute à chaque changement pour vérifier qu'ils n'ont pas cassé quelque chose qui marchait avant. Par exemple : on crée une fonction qui retourne 0 dans un cas précis. Deux semaines plus tard, on préfère que cette fonction retourne 1 dans ce cas précis. Sauf qu'entre temps, on a écrit deux fonctions en tenant compte de ce 0. Mais on a oublié... et on cherche le bug pendant des heures. Autre exemple plus concret, on considère une fonction qui doit retourner une somme réelle même si les éléments de la liste sont entiers. On écrit la fonction qui vérifie cela.
def somme_double (liste) :
return 1.0 * sum(liste)
def test_somme_double () :
y = somme_double([ 1 ]) / 2
if y == 0 : raise Exception ("valeur > 0 attendue")
if __name__ == "__main__" :
test_somme_double()
Si plus tard, quelqu'un modifie la fonction somme_double en enlevant la multiplication parce qu'il considère cela inutile. La fonction de test provoquera une erreur. Elle est là pour rappeler que la fonction a été programmée pour retourner un nombre réel et que quiconque l'utilise s'attend à ce qu'elle retourne ce type de résultat.
Traceback (most recent call last):
File "conseil.py", line 10, in <module>
test_somme_double()
File "conseil.py", line 7, in test_somme_double
if y == 0 : raise Exception ("valeur > 0 attendue")
Exception: valeur > 0 attendue
|
Xavier Dupré
|
