Discussion :

[Songbird]

Bonjour,

Je ne savais pas où poser ma question sans qu'elle fasse tâche, donc j'ai fait en sorte de rester dans une rubrique "générale".

Le génie logiciel encapsule différentes méthodes de développement, toutes plus ou moins adaptées pour une équipe de développeurs. Et, à vrai dire, je m'y perds un peu parce que y'a quand même de sacrés pavés qui essaient de documenter ces méthodes.
J'ai compris plus ou moins que, de toute façon, les méthodes les plus communes ne peuvent être maîtrisées par une seule personne, mais est-ce que vous auriez, justement, avec vos retours d'expérience, des conseils à donner lorsque l'on est seul à travailler sur un projet ? (Organisation, maintien du logiciel, etc)

Je ne cherche pas non plus à créer un débat, parce que je ne m'y connais absolument pas et je souhaite juste avoir quelques explications si certains en ont le courage et/ou la patience.


Je vous remercie d'avance pour vos réponses,

Cordialement,

Songbird.

[Logan Mauzaize]

Bonjour,


Les méthodes de développement ont surtout été étudié pour gérer le travail à plusieurs et éventuellement tenir compte de l'entrée/sortie des intervenants. Néanmoins, il y a toujours quelques trucs bons à prendre :

Il faut automatiser. Il y a certaines opérations que l'on fait qu'une fois mais un grand nombre d'opérations sont répétées (même si pas régulièrement). Ces dernières se doivent d'être automatisées afin de fluidifier l'activité et limiter les erreurs. Le plus simple c'est souvent la chaîne de compilation mais être capable de mettre en place un environnement pour réaliser des tests ou faire la mise en production est également nécessaire.

La plus grosse source d'erreur, c'est l'intervention humaine donc autant la limiter. Et ceux même jusqu'au déclenchement des scripts !


Pour faire suite, ne pas lésiner sur les outils. Qu'ils soient existants ou qu'ils faillent en développer dédiés. Dans le premier cas, il s'agit par exemple d'avoir un IDE et qu'il soit bien configurer ; prendre du temps à le faire n'est jamais du temps perdu ! Dans le second cas, il s'agit d'outils divers qui passent par la compilation, la génération de cas de tests, etc. A titre d'exemple, j'ai travaillé sur une application qui s'appuyait sur plusieurs bases de données pour générer un fichier XML et qui devait remplacer une application existante ayant un fonctionnement un peu différent. J'ai développé des outils qui régénèrent des structures de bases de données pour les tests unitaires, qui de générer des statistiques sur les valeurs possibles afin de faciliter l'écriture de cas de tests, qui permettent de comparer les fichiers XMLs des deux applications et établir des statistiques de conformité et d'avancement, etc.


Travailler avec un gestionnaire de configuration de sources (Git, SVN, etc.) et éventuellement de binaires (Nexus, ???). Le premier est important pour tout un tas de raison (historique, retour à une version stable, branching, etc.). Pour le second, cela permet des retours arrières encore plus rapide en évitant de régénérer d'anciennes versions.


Documenter ! C'est extrêmement vague mais voici deux choses à retenir : définir le plan de la direction à prendre et établir l'état des lieux actuels. Parfois on se perd dans ce que l'on a déjà fait, avoir une documentation qui défini l'existant permet de connaître ou se remémorer le fonctionnement de tel ou tel partie sans avoir à replonger dans le code. Mais il est également important de savoir dans quelle direction on va.


Ce sera mon dernier conseil : Rigueur et constance. Ce qui fait la qualité d'un projet c'est son homogénéité que ce soit dans ses composants binaires, ses fonctionnalités, son code (organisation, arborescences, noms, ...), etc. Pour reboucler sur la première partie, il existe des outils et des configurations qui permettent de contrôler et corriger certains aspects (mais cela dépend pas mal de ton environnement technique).


Ensuite il existe un certain nombre de bonnes pratiques qui dépendent de ton environnement technique et fonctionnel. Mais pour cela, il faudra donner un peu plus de contexte.

[Songbird]

Merci pour ta réponse, tout d'abord.

Concernant les outils, c'est noté: j'ai souvent tendance à hésiter concernant la conception d'outils faits-maisons. En abuser peut ralentir un projet, mais savoir aussi gérer ses besoins réduit le temps de recherche d'un outil peu ou pas plus adapté que ce que l'on aurait pu faire soi-même.

Travailler avec un gestionnaire de configuration de sources (Git, SVN, etc.) et éventuellement de binaires (Nexus, ???)

A propos de Nexus, aurais-tu des liens vers lesquels je pourrais me documenter ? (Mis à part des guides pour la configuration, dont je me fiche puisque pour le moment je ne sais pas m'en servir, je n'ai pas trouvé grand-chose (ou alors je cherche mal))

Ce sera mon dernier conseil : Rigueur et constance. Ce qui fait la qualité d'un projet c'est son homogénéité que ce soit dans ses composants binaires, ses fonctionnalités, son code (organisation, arborescences, noms, ...), etc. Pour reboucler sur la première partie, il existe des outils et des configurations qui permettent de contrôler et corriger certains aspects (mais cela dépend pas mal de ton environnement technique).

Ensuite il existe un certain nombre de bonnes pratiques qui dépendent de ton environnement technique et fonctionnel. Mais pour cela, il faudra donner un peu plus de contexte.

Je dispose d'un serveur apache et MySQL en local pour le développement de projets principalement en PHP.
Ce n'est pas le langage que je préfère, mais disons que pour des raisons pratiques je m'en sert, et je souhaiterais pouvoir m'organiser pour installer un véritable IDE autour de ce langage car ça devient vite disparate... (J'ai déjà configuré des petits outils de débogage, mais rien de génial) Seulement je sais pas vraiment par où commencer, quand je vois que pour avoir la stack trace d'une erreur faut aller le signaler dans le php.ini

Je te remercie d'avance pour ton aide (n'hésites pas à me signaler les choses que j'aurais oubliées de préciser si mes explications ne sont pas claires)

[Logan Mauzaize]

A propos de Nexus, aurais-tu des liens vers lesquels je pourrais me documenter ? (Mis à part des guides pour la configuration, dont je me fiche puisque pour le moment je ne sais pas m'en servir, je n'ai pas trouvé grand-chose (ou alors je cherche mal))

Non désolé je n'ai jamais eu à gérer la mise en place d'un Nexus. Cependant dans le cadre de projet PHP, tu n'as pas besoin de gérer de binaire ?

Je dispose d'un serveur apache et MySQL en local pour le développement de projets principalement en PHP.
Ce n'est pas le langage que je préfère, mais disons que pour des raisons pratiques je m'en sert, et je souhaiterais pouvoir m'organiser pour installer un véritable IDE autour de ce langage car ça devient vite disparate... (J'ai déjà configuré des petits outils de débogage, mais rien de génial) Seulement je sais pas vraiment par où commencer, quand je vois que pour avoir la stack trace d'une erreur faut aller le signaler dans le php.ini

Est-ce que tu à regarder du côté de Netbeans, Eclipse ou Aptana ? Je ne suis pas un spécialiste PHP mais tu pourrais poster du côté de la section concernée du forum pour demander leurs méthodes de travail aux autres membres ?

[Songbird]

Bonjour,

Navré pour la réponse tardive.

Sinon pour rebondir sur ton dernier post:

J'ai ouvert se topic en posant dans l'optique de connaître "en général" comment peuvent être organisés certains projets, je ne visais pas un type de projet spécifique (PHP, Java, ou autre)

Pour ce qui est de PHP, Netbeans et Eclipse ne m'intéressent pas du tout. Vraiment trop lourd pour une techno comme PHP.
Pour le dernier, je ne connais pas, je vais aller me renseigner, merci !

[Logan Mauzaize]

Un truc que tu lances, une fois par jour. Même s'il met 5mn à se lancer ce n'est pas la mort. Surtout si l'apport en productivité est considérable (contrôle d'erreur, auto-complétion, déploiement automatique, debuggage, etc.)
Par exemple j'utilise Eclipse pour développer en Groovy (langage de script), c'est beaucoup plus confortable.

Sinon Netbeans m'a toujours paru plus léger mais je l'ai pas utilisé intensivement depuis plusieurs années. Eclipse s'est beaucoup imposé dans les entreprises, surtout celles qui ont migrées depuis des solutions IBM (car basées sur Eclipse).

Après cela dépend aussi si tu utilises beaucoup de frameworks.

Les méthodes de développement sont conceptuellement partagées mais dans la pratique, il y a pas mal de différences. Les langages de scripts devraient imposer plus de tests unitaires pour compenser l'absence de compilateur par exemple.

De mêmes des personnes qui travaillent réellement en environnement polyglote auront surement une autre manière de travailler que ceux plus focaliser sur Java ou sur PHP par exemple.

Idem entre du développement pur front, du fullstack, du pur backend, des services d'orchestration/intégration (EAI), des custo pour progiciels (ERP, PLM), du client lourd, de l'embarqué, des jeux vidéos, etc. tout cela va nécessiter des méthodes, outils et techniques un peu particuliers.

Les trucs supplémentaire (mais toujours très génériques) qui me viennent en tête sont donc : les tests (focalisé sur l'unitaire si on reste dans le monde des développeurs, sinon la gestion des tests en général), le "clean code" et la robustesse.

Ce dernier point pourrait faire l'objet d'un livre entier et contrairement à ce que les gens pensent, cela va bien au delà de faire un code qui plante pas. Je dirai même que ca concerne avant tout la capacité d'un code à fournir de l'information sur son fonctionnement. Cela passe pas des logs, des mécanismes de détection des erreurs, de réparation et de reprises.
Voici un message que j'ai écrit il y a quelques temps sur le sujet mais qui illustre bien : http://www.developpez.net/forums/d15...e/#post8255500

[Songbird]

re-bonjour,

Un truc que tu lances, une fois par jour. Même s'il met 5mn à se lancer ce n'est pas la mort. Surtout si l'apport en productivité est considérable (contrôle d'erreur, auto-complétion, déploiement automatique, debuggage, etc.)
Par exemple j'utilise Eclipse pour développer en Groovy (langage de script), c'est beaucoup plus confortable.

Juste pour terminer à propos de PHP:

Oui effectivement ce n'est pas bien méchant, mais faisant uniquement du PHP vanilla pour le moment, je laisse les outils côté serveur me servir la trace de l'erreur et ça me suffit amplement.
Bien évidemment si je viens à utiliser de grosses bibliothèques, j'éviterai de m'y aventurer seul personnellement.

Les trucs supplémentaire (mais toujours très génériques) qui me viennent en tête sont donc : les tests (focalisé sur l'unitaire si on reste dans le monde des développeurs, sinon la gestion des tests en général), le "clean code" et la robustesse.

Cela passe pas des logs, des mécanismes de détection des erreurs, de réparation et de reprises.
Voici un message que j'ai écrit il y a quelques temps sur le sujet mais qui illustre bien : http://www.developpez.net/forums/d15...e/#post8255500

C'est noté !
Ça ressemble à de la programmation défensive, mais en un peu plus coriace quand même.

En revanche, pour ce qui est de la détection des erreurs, j'ai toujours eu beaucoup de mal à créer des routines pour faire communiquer les modules entre eux et qu'ils remontent leur "état" de santé.
En Java par exemple, y'a une méthode sale mais qui fonctionne, c'est de cloisonner l'intégralité du programme dans un thread puis d'écouter les erreurs non gérées.




Je ne te demanderai pas de m'expliquer tout ça ici, mais si tu as un lien vers une bonne doc à ce sujet, je t'en remercie d'avance !