Discussion :

[Pyramidev]

Ce que j'ai pas mal pratiqué en bancaire, ce sont des traitements par nature très linéaires, ou tu fais des choses au kilomètre, que tu ne fais nulle part ailleurs, et qui sont juste en séquence. Il y a zéro valeur ajoutée à découper tout ça en rondelles.

La valeur ajoutée serait de pouvoir faire plus facilement des grands sauts quand on débogue pas à pas.

Au lieu de faire :
"scroll, scroll, scroll, scroll, scroll, scroll, scroll, scroll, scroll, scroll, ajouter un point d'arrêt, avancer l'exécution jusqu'à ce point d'arrêt",
il suffit de faire :
"pas à pas sortant, avancer un peu, pas à pas entrant, avancer un peu".

Remarque : A la place du scroll, on peut parfois faire Ctrl+F et entrer une chaîne qui va nous amener là où on veut mettre un point d'arrêt, mais ça suppose que l'on connaît déjà le code suffisamment bien pour savoir quelle chaîne rechercher.

[Nebulix]

L'entrée qui manque dans le sondage (trop évident peur-être) est : savoir exactement ce que je veux faire. Et donc commencer par l'écrire en français. Puis écrire en dessous les grandes étapes, puis les subdiviser en petites étapes, ajouter les détails essentiels (d'où je pars, où je vais). Quand cela est fait et stable, il est beaucoup plus facile de développer chaque ligne de commentaire en code (quelques dizaines de lignes max). Et il est aussi facile de maintenir le programme.

[progfun]

Lorsque je développe un logiciel, je ressens toujours une grande satisfaction lorsque j'écris des procédures qui peuvent s'appliquer à presque n'importe quel logiciel. Bien sût cette universalité est relative au champ d'application. Par exemple une procédure pour la gestion de l'affichage à l'écran peut être utilisée dans n'importe quel logiciel dans les capacités limites de cet affichage. Les procédures souvent universelles sont des solutions mathématiques. Mais les procédures en lien avec la réalité humaine comme la gestion et l'administration sont plus difficiles à rendre universelles car il y a tellement de possibilités, et souvent on arrive pas à tout prévoir au moment de la conception. Quoiqu'il en soit, construire des procédures le plus universelles possibles est l'une des caractéristiques qui contribuent à faire de la programmation un outil puissant.

[Saverok]

Quoiqu'il en soit, construire des procédures le plus universelles possibles est l'une des caractéristiques qui contribuent à faire de la programmation un outil puissant.

Si et seulement si tu références tes procédures "universelles" dans une API que tu peux importer facilement dans un autre projet.
Sinon, je trouve que c'est se prendre la tête pour pas grand chose.

Par expérience, j'ai rarement eu besoin de coder ce genre de procédure car elles existent souvent déjà.
Note : je bosse en Java et vu le nombre de framework existants, c'est vraiment rare de trouver une fonction générique jamais développée ailleurs.

[progfun]

Si et seulement si tu références tes procédures "universelles" dans une API que tu peux importer facilement dans un autre projet.
Sinon, je trouve que c'est se prendre la tête pour pas grand chose.

Par expérience, j'ai rarement eu besoin de coder ce genre de procédure car elles existent souvent déjà.
Note : je bosse en Java et vu le nombre de framework existants, c'est vraiment rare de trouver une fonction générique jamais développée ailleurs.

En effet, l'informatique a bien évolué et aujourd'hui on retrouve beaucoup de librairies, de bibliothèques qui offrent justement des procédures génériques qui illustrent l'idée que je veux exprimer. Et comme l'expression le dit, "on ne veut pas réinventer la roue". Mais même lorsqu'on utilise ces librairies dans notre programmation, on les utilise pour construire des procédures propre à notre application (par exemple un système de paie, de gestion du transport, etc.) et encore à ce niveau, on peut rechercher à "universaliser" la procédure créée, si c'est possible bien sûr.

[remi_inconnu]

- Faire une bonne architecture, découpage en classe, module, etc.
- Chaque module doit être testé unitairement, avoir une bonne couverture de test (au moins 90 %), et aussi être testé rapidement et fréquemment pour éviter les regressions.
- Faire simple, limiter la longueur des fonctions ou méthodes (pas plus de deux pages écran).
- Réutiliser au maximum, ne jamais au grand jamais dupliquer du code (duplication code = duplication bug, duplication des modifications, et immanquablement on oublie de faire les évolutions à tous les endroits).
- Documenter le code pour l'utilisateur (si ce sont des librairies utilisateurs), exemples d'utilisation (et cela n'a rien à voir avec du test), tutoriaux, une bonne documentation demande de gros effort, mais elle est nécessaire si on veut que les utilisateurs puissent pleinement adopter le fruit de votre travail.
- Documenter le code pour le mainteneur ou pour soit même (reprendre du code 5 ans après est fréquent, et on a complètement oublié comment il fonctionne)
- Avoir une mise en page du code aéré, correctement tabulée (pour apprendre à faire propre, rien ne vaut l'utilisation de python qui oblige une indentation irréprochable).
- Bien sur git ou autre gestionnaire de version, et base de bug (jira par exemple).

[progfun]

- Faire une bonne architecture, découpage en classe, module, etc.
- Chaque module doit être testé unitairement, avoir une bonne couverture de test (au moins 90 %), et aussi être testé rapidement et fréquemment pour éviter les regressions.
- Faire simple, limiter la longueur des fonctions ou méthodes (pas plus de deux pages écran).
- Réutiliser au maximum, ne jamais au grand jamais dupliquer du code (duplication code = duplication bug, duplication des modifications, et immanquablement on oublie de faire les évolutions à tous les endroits).
- Documenter le code pour l'utilisateur (si ce sont des librairies utilisateurs), exemples d'utilisation (et cela n'a rien à voir avec du test), tutoriaux, une bonne documentation demande de gros effort, mais elle est nécessaire si on veut que les utilisateurs puissent pleinement adopter le fruit de votre travail.
- Documenter le code pour le mainteneur ou pour soit même (reprendre du code 5 ans après est fréquent, et on a complètement oublié comment il fonctionne)
- Avoir une mise en page du code aéré, correctement tabulée (pour apprendre à faire propre, rien ne vaut l'utilisation de python qui oblige une indentation irréprochable).
- Bien sur git ou autre gestionnaire de version, et base de bug (jira par exemple).

Je suis tout à fait d'accord avec cela. Je pense que ces principes et techniques de travail sont incontournables.

[Mat.M]

- Faire une bonne architecture, découpage en classe, module, etc.
-

+1000
c'est la première des habitudes que devrait avoir un bon développeur...mais ce n'est pas cité dans la liste donc le créateur de ce fil de discussion devrait le rajouter

Pour une petite fonction ca peut passer, mais après c'est juste immonde!
Je me suis déjà retrouver à devoir modifier une fonction de plus de 3500 lignes...
Ben franchement j'aurais mis beaucoup moins de temps si c'était éclaté en 10 méthodes elles même divisé en 10 méthodes.

cela semble être un problème malheureusement souvent rencontré dans les projets: soit la personne ne sait pas refactoriser soit le projet est bâclé.
Ou bien la plupart du temps c'est qu'il y a zéro architecture de projet

De toute façon avant d'apprendre à programmer on devrait obligatoirement apprendre à architecturer un programme

[devdiop00]

Etre curieux, comprendre l'anglais, être bien en algorithme, beaucoup pratiqué essayer aux moins de maîtriser un langage sans oublier les méthodologies des développement (SRUM OU AGILE...)

[Pierre Fauconnier]

Au vu de certaines discussions, notamment sur le forum VBA Excel, je dirais qu'une qualité d'un programmeur, c'est de pouvoir se remettre en question lorsqu'on lui met le nez dans son caca parce qu'il a codé comme un goret