Discussion :

[dva2tlse]

Bonjour le forum; j'ai déjà posé sur ce forum des questions relatives au développement que j'ai à faire, et vos réponses m'ont bien aidé donc je reviens. C'est un gros programme en fortran, enfin gros pour moi en tous cas, qui ne suis pas du tout développeur mais ingénieur mécanicien; le problème qui se pose à moi est que justement ce n'est pas mon métier, et qu'il n'y a pas la place pour tout dans ma tête.

Donc je fais des impasses, en laissant des "ZZZ" et des "???" dans mon code, en espérant retrouver l'impasse faite quand j'y reviendrais, mais ce n'est pas très rigoureux.
J'ai aussi des interrogations à propos d'une gestion intelligente des sauvegardes des différentes versions de mon travail, à propos du pseudo-code que j'utilise rarement et dont je ne sais même pas si c'est bien utile, des erreurs que le programme peut détecter et s'arrêter ou laisser filer (?), et de la méthode de développement que je pratique, par essais-corrections. (je n'en connais pas d'autre)

Merci si vous pouvez me donner des liens vers des informations sur ces problématiques pour que je prenne connaissance des pratiques possibles et m'en inspire.
David

[DonQuiche]

Bonjour. Je ne sais pas si ça te sera bien utile mais :

a) Plutôt que de simples sauvegardes on utilise généralement un système de contrôle des sources (git, subversion, etc) qui permet à tout moment d'annuler certains changements, de retrouver toutes les modifications apportées à un fichier, etc. Beaucoup plus puissant qu'une simple sauvegarde. Pour te donner une idée avec subversion (sans doute le plus facile), tu peux faire des "commit" qui envoient tes modifications sur le serveur ou bien au contraire à tout moment visualier la version X du fichier ou du projet. Tu peux installer le serveur toi-même sur ta machine (mais gare aux défaillances de cette machine), sur une seconde machine ou sur un serveur (si possible sur un autre site), passer par une entreprise tierce (solution clé en main payante, solution clé en main gratuite mais publique sur github, serveur mutualisé OVH avec SVN, etc), etc. TortoiseSVN sur Sourceforge (zyeute les images).

b) Pour le pseudo-code il sert surtout à communiquer tes idées aux autres et à enseigner la conception d'algorithmes. Ce n'est pas une aide à la conception logicielle (sauf si tu en ressens le besoin, régulièrement ou exceptionnellement) et il n'y pas en général d’intérêt à les maintenir. Eventuellement pour un algo important si la mise en oeuvre est très différente et pour faciliter la vie de ceux qui suivront mais gare : comme les commentaires, ces artefacts de documentation deviennent rapidement obsolètes et peuvent alors égarer au lieu d'aider.

c) Le système essai-erreur est malheureusement indispensable. Cela dit :
1) Il faut chercher à planifier à l'avance et à suivre le cours de ton idée avant de te jeter sur le clavier. Le but est de se rendre compte des erreurs le plus tôt possible et pas après trois semaines de programmation. Pour reprendre une citation : "trois semaines de codage peuvent vous épargner trois jours de conception".

2) Si tu ne trouves pas la solution, il n'y a malheureusement qu'une chose à faire : persévérer. Si toutefois tu as des collègues plus expérimentés, tu peux voir avec eux (évite simplement de les interrompre dans une tâche requérant de la concentration). Ou, si dans ce contexte tu laisses le problème en plan (pas terrible) et qu'il est résolu plus tard, vérifie la solution pour apprendre.

3) Il y a parfois de bonnes raisons pour mettre les choses de côté : tes futurs tâches t'éclaireront davantage sur ce problème ou tu es en train de bosser sur autre chose et tu butes sur un problème annexe. Mais dans ce cas mets en place un système qui te rappellera les choses à faire. Un simple système de commentaires commençant pas une chaîne précise que tu n'aurais qu'à chercher, comme "TODO:". D'ailleurs certains IDE (notamment VS) listent automatiquement ces commentaires dans une fenêtre à part. Ou un système de tickets (bogues, tâches restantes, etc), que ce soit var un logiciel dédié ou un simple fichier texte que tu maintiendras. Ou les deux puisqu'un simple commentaire est plus spontané et plus rapide. C'est le post-it en bas de ton écran contre le tableau centralisé pour l'équipe.

4) Comme tu l'as dit ce n'est pas ton métier et il est normal que tu aies des difficultés, il faut savoir en faire part. Mais ne te place pas dans une optique réfractaire : ça va aussi devenir ton métier, tu vas devenir aussi compétent qu'un autre en la matière. Place-toi dans une optique d'apprentissage.

[dva2tlse]

Bonjour, merci de m'avoir répondu...

Je ne sais pas si ça te sera bien utile

Si merci, il y a des idées générales qui sont exactement les encouragements dont j'ai besoin, et quelques points précis qui devraient me faire avancer concrètement aussi.

a)sauvegardes

contrôle des sources .../... git, subversion, etc

Oui, en effet j'ai souvent utilisé des sources de soft's pour linux qui résidaient sur des serveurs git.

retrouver toutes les modifications apportées à un fichier

Ça par contre ce n'est pas forcément très utilisable, parce qu'au bout d'un moment je ne sais plus tellement quelle fonctionnalité est apportée par telle ou telle modification.

sans doute le plus facile (subversion)

Mouais, ça fait encore un soft de plus à apprendre, et gare aux conneries de débutant.

mais gare aux défaillances de cette machine

Oui, il faut UN LIEU SÛR, comme d'hab', pour de vraies SAUVEGARDES !

b) pseudo-code

si tu en ressens le besoin

J'en ai eu besoin une fois ou deux pour faire à peu près clairement des choses à peu près claires...

c) essai-erreur

persévérer

Ça je sais faire, et on ne me met pas de pression temporelle, donc ça va.

Ce n'est pas ton[mon] métier

optique réfractaire ../.. optique d'apprentissage

J'adore apprendre, ce qui fait que plus de vingt ans dans le même boulot ne me pèsent pas; et on ne vient me voir que pour du jamais vu ou du jamais fait, et ce boulot-là est justement un des cinq "plus mieux" que je n'aie jamais eu à faire, YOUPI.
David

[foetus]

Un simple système de commentaires commençant pas une chaîne précise que tu n'aurais qu'à chercher, comme "TODO:".

Effectivement ce n'est pas le seul. Trouvé sur Wiki dans la section Tags

• FIXME to mark potential problematic code that requires special attention and/or review.
• NOTE to document inner workings of code and indicate potential pitfalls.
• TODO to indicate planned enhancements.
• XXX to warn other programmers of problematic or misguiding code.

Ça par contre ce n'est pas forcément très utilisable, parce qu'au bout d'un moment je ne sais plus tellement quelle fonctionnalité est apportée par telle ou telle modification.

Lorsque tu commites il faut faire des commentaires très explicites.

Et, tu peux aussi versionner un fichier "ChangeLog"
Mais, tu peux maintenir un "truc" plus consistant qu'un simple fichier txt, avec des diagrammes UMLs [pas forcément complets du moment qu'ils soient explicites] par exemple

Et en dernier lieu, si les modifications ne sont pas importantes en termes de lignes de code et de répétitivité, tu peux laisser dans ton code, l'ancien code commenté avec une date et un commentaire "pourquoi il a été mis de côté": c'est le versionnement du pauvre

Mouais, ça fait encore un soft de plus à apprendre, et gare aux conneries de débutant.

Non 2 Serveur, à paramétrer, et Client, pour l’utilisation.

[el_slapper]

Bonjour le forum; j'ai déjà posé sur ce forum des questions relatives au développement que j'ai à faire, et vos réponses m'ont bien aidé donc je reviens. C'est un gros programme en fortran, enfin gros pour moi en tous cas, qui ne suis pas du tout développeur mais ingénieur mécanicien; le problème qui se pose à moi est que justement ce n'est pas mon métier, et qu'il n'y a pas la place pour tout dans ma tête.
(.../...)

Superbes réponses sur les autres points, mais je souhaite compléter là-dessus. Pas de place pour tout le programme dans ta tête? C'est normal. Un code, c'est juste une quantité gigantesque d'algorithmes. Ce qui est important, c'est la capacité de zoom : je suis sur un détail, qui appartient au groupe de détail machin, qui se situe à tel endroit dans le schéma global. Ne pas oublier le schéma global, jamais. Ne pas oublier l'algo en cours, jamais. Tout le reste, le consulter quand on a besoin.

En tant qu'ancien ingénieur(plasturgiste), je dirais qu'effectivement la différence avec un plan, c'est la quantité de trucs. Une belle mécanique, une fois qu'on a pigé, ça rentre bien. Les éléments unitaires du code sont généralement moins difficilles, moins subtils pris séparément, mais on doit gérer leur immense quantité. On gère la complexité plus que la complication.

C'est pour ça qu'un gestionnaire de sources devient vite trèèèès utile. Il est très vite plus efficace que des commentaires dans le code pour savoir ce qu'on a fait(ce qui ne rend pas les commentaires inutiles, ceinture et bretelle, à ce sujet, est ma doctrine). Nul n'a la place pour tout mettre dans sa cervelle. Il ne faut pas faire de complexe vis-à-vis de celà.