Bonjour à tous,
 
Ça faisait un moment que j'avais peu développé,
et là j'ai tout un tas de projets qui s'annoncent.
J'aimerais me parfaire (c'est loin d'être gagné),
j'ai lu le manifeste du développement agile,
je suis en train de lire Coder Proprement, en vue d'essayer de faire un bon code, éventuellement utilisable longtemps.
 
Et sinon j'ai trouvé pas mal de méthodes concernant surtout le développement en équipe.
Ça viendra, certainement,
mais en attendant, comment faire quand on est tout seul ?
A part un bon bouquin de C++, un autre de C#, un visual studio tout neuf, faut il que je rentre dans le tas directement où y a-t-il des prérequis ?
Je ne pourrai sans doute pas trop trainer vu la tâche déjà définie (j'en ai listé déjà pour au moins deux ans pour commencer)
En même temps j'ai toujours un flottement quand il s'agit de passer à du concret.
 
Tout conseil sera le bienvenu, merci

Ben, les méthodes qui marchent pour une équipe marchent pour une personne seule. Bien faire ses spécs et toute la doc (dossier de conception, manuel d'exploitation, MUT, dossier de tests...), gérer en conf son code source...
 
Pour les méthodes agile, SCRUM est bien. Faire de petites itérations pour pas trop diverger, impliquer le client final ou les utilisateurs finaux dans les spécs et les itérations (mise à disposition de ce qui a été codé pour tests). Faire du dév piloter par les tests aussi, ça permet d'automatiser le dossier de tests et le passage des TU/TI.
 
Voilà qq pistes.

Quelques pistes nécessitant documentation mais c'est bien,
Merci
l'utilisateur pour le moment c'est moi aussi (ou actuellement seulement moi) pour une partie des développements.
 
Je cherche "gérer en conf", "MUT" et "TU/TI" (test unitaire test d'intégration je suppose ?)
 
Il va aussi falloir que je me documente sur les tests, je suis une antiquité je n'ai jamais vraiment fait ça sérieusement (je sais que c'est un tort).

Mut = manuel utilisateur.
TU/TI, oui c'est ça.
Un projet de logiciel doit avoir au minimum, un DSL (dossier de spéc logicielle), un DCP (dossier de conception préliminaire) éventuelle un DCD (dossier de conception détaillée si le soft est "gros" ), un MEX, un MUT et un DTV (dossier de tests de validation). dans le cas de soft qui communique avec d'autres, on doit avoir un DDI (dossier de description d'interface). Suivant la culture d'entreprise, ces docs peuvent porter d'autres non, bien entendu ou être fusionnés dans un un seul doc.

Ah ok merci.
 
Je ne pense pas pouvoir faire tout ça dans les règles de l'art vu qu'il s'agit pour une bonne part d'une myriade d'outils qui nous ferons rapidement gagner du temps et/ou de l'argent, et que nous naviguons partiellement à vue.
 
Certains petits développements ou modifications sont surtout l'affaire d'heures ou de quelques jours.  
Ma grosse difficulté pour le moment c'est de comprendre l'esprit et récupérer le maximum du travail de mon prédécesseur, malheureusement disparu, avant de le faire évoluer, et je ferai tout pour que ça soit plus facile à comprendre pour un nouveau.

Y'a pas de secret, pour qu'une appli soit maintenable, faut de la doc. Rogner sur la doc, en pensant que ça fera gagner du temps, c'est d'une bêtise    
 
Suivant la taille et la complexité du soft, faut juste adapter le niveau de détail de la doc. Tu peux éventuellement te passer du DTV. Tu peux te passer éventuellement du DCP (ou DCD) si l'outil est est petit et si ton code est très bien commenté. Mais le DSL, MEX et MUT sont indispensables !!! Pour les MEX et MUT, tu peux te contenter de faire un article dans le wiki de l'entreprise si vous gérer votre connaissance par ce type d'outil.

C'est juste que je dois jongler pour que la boutique continue à tourner, et que forcément entre la reprise, l'investigation, les docs, les modifications, la prod... Il n'y a que 168 heures par semaine.
 
Mais je suis d'accord et j'essaierai de faire les choses proprement, c'est aussi pour cela que je demandais conseil.

Enfin je ne vais pas jouer ma pleureuse non plus
Je n'en suis plus au stade "ça passe ou ça casse". C'est passé. Mais il en reste.