Discussion :

[VivienD]

Au lieu de faire une fonction qui ajoute X à tous les élements d'une liste (renvoyant X'), une fonction qui va appliquer une fonction Y à chaque élement d'une liste (renvoyant Y'), une fonction qui va récupérer l'information Z de chaque élément d'une liste (renvoyant Z', liste des informations), tu fais une fonction qui prend en paramètre une liste L et une fonction F, et qui applique F à chaque élement de L, renvoyant L'.

Bref tu factorises 3 fonctions (à but unique) en une seule (qui a plusieurs utilisations possibles).

C'est parfois un poil plus compliqué à relire, mais si il y a un bug dans ta gestion des listes, tu n'auras pas à traquer chacune des fonctions appliquées à X Y et Z pour corriger un bug.

Ca c'est un exemple simple, souvent déjà prévu dans la bibliothèque de base du langage, mais c'est pour expliquer le principe.

Merci, ManusDei.

[I_believe_in_code]

Bien souvent, l'application que vous developpez a déjà été écrite

Ah tiens ? Cela ne m'est jamais arrivé.

[Logan Mauzaize]

Ah tiens ? Cela ne m'est jamais arrivé.

En ce moment ca m'arrive souvent mais c'est justement parce qu'on remplace l'application vieillissante

[I_believe_in_code]

Le meilleur conseil qu'on m'ait donné, c'était "ne jamais hésiter à refaire".
Francois

C'est aussi le meilleur qu'on m'ait donné. Dans un logiciel que je maintiens depuis bientôt vingt ans (oui, j'avais quinze ans que j'en ai terminé la première version), beaucoup de fonctions, voire des modules entiers, en sont à leur six ou septième version. Chaque version apporte au moins une des améliorations suivantes à la précédente :

- son code est plus facile à comprendre ;
- elle peut servir de sous-routine à une nouvelle fonctionnalité que je vais ajouter bientôt, alors que ce n'était pas le cas de la version précédente ;
- l'algorithme a une meilleure complexité (par exemple n^2 au lieu de n^3) ;
- elle est conforme à un style d'écriture que j'ai appliqué ailleurs et qui a donné des bouts de code bien lisibles.

J'ajoute que pour certaines fonctions assez simples à écrire, je code systématiquement une version sans effet de bord et une avec effets de bord. Cela ne coûte pratiquement pas de temps supplémentaire sur le moment, mais je gagne du temps dès qu'il faut utiliser ces fonctions dans de nouveaux algorithmes qui s'écriront, selon les cas, plus facilement ou non dans un style "fonctionnel".

[Lordsephiroth]

Pour ma part je donnerai ce conseil simple et efficace : être curieux et passionné.

Sinon je rejoins largement les conseils de skip en première page : éviter les couches d'abstractions superflues, éviter de tout mettre en fichier de configuration, éviter de chercher à compresser le code (y a ZIP pour ça). Lisez son post, il est bien écrit et j'adhère parfaitement à sa vision.

[Jay13mhsc]

A peu de chose près, on peut résumer les pensées 1, 2, 5 et 6 à : "faites du TDD"...

[deuz59]

S'il fallait un seul conseil : "WHAT first, HOW last"

Traduction explicative : "Ecrire ce qu'on fait, le QUOI, d'abord en reléguant l'implémentation pure, le COMMENT, en dernier lieu"

Trop souvent on doit déduire, voire supposer sans certitude, ce qu'un code fait en fonction de l'implémentation qui est faite. En terme de maintenance pour le ciblage/diagnostique, trop de perte de temps/énergie à analyser/comprendre du code inutilement pour finalement tomber sur la seule partie qui nous intéresse, sans compter le risque d'erreur d'interprétation.

[el_slapper]

A peu de chose près, on peut résumer les pensées 1, 2, 5 et 6 à : "faites du TDD"...

faut pas pousser.

(1) "write less code"
(2) toujours prendre le temps de réfléchir quand on a une erreur avant de rajouter du code supplémentaire.
(5) Le premier : refactoriser son code rejoignant un peu l'idée d'Erik Buck de rendre le code plus facile à comprendre et donc à maintenir. Le deuxième : écrire des tests unitaires pour son code avant de l'intégrer au projet.
(6) Son conseil : d'abord rendre son code fonctionnel avant de vouloir l'améliorer.


Pour le 1, quel rapport? Quel rapport entre le TDD et la quantité de code?
Pour le 2, avoir les tests unitaires est fortement utile, ça n'oblige pas à les faire AVANT le code(initial ou rajouté).
Pour le 5, pareil : il parle de pouvoir tout tester facilement, histoire de pouvoir faire une version deux qui soi isofonctionelle de la version un, pas d'écrire les tests en question avant la question un.
Pour le 6, je ne vois pas le rapport non plus. Je code, je teste(peu importe comment), je fais marcher, puis ensuite seulement je rajoute des choses ou j'améliore l'existant.

Attention, je ne dégoise pas le TDD(même si en Cobol, c'est compliqué ne serait-ce que d'en rêver, mais passons), c'est sans doute une excellente méthode. Simplement, ton interprétation des conseils me parait très, très orientée.

[h_fabrice]

Lisez plus que vous ne codez

[iker06]

Pour ma part, c'est le conseil de Bill Wagner que je suis chque fois que je code.

[manu007]

Reflechir avant d'écrire une seule ligne de code, c'est le meilleur moyen d'écrire un code simple et eficace donc facile a maintenir.

J'ai horreur des programmes fleuve...

[pegazus225]

RAS (complètement d'accord) pour Obie fernandez, Eric Lippert et Bill Wagner. Merci les gars. Quant à ce qui est d'écrire peu de code, cela dépend de ce qu'on cherche à créer et lire plus qu'on ne code, reste à savoir si on comprend véritablement ce qu'on lit si on ne l'applique pas en même temps. Mais merci d'y avoir penser.

[galyathee]

Les meilleurs conseils que je puisse donner sont:
[Niveau 0]
- Ecrivez les tests avant le code
- Coder avec des interfaces
- Verifier que l'algorithme n'est pas connu avant de réinventer la roue
- Chercher dans les structures des patterns évidents (visitor, builder, command, ...)
- Coder ses propres exceptions
- Analyser et mettre en place une politique flexible de logs (avec AOP pourquoi pas)
[Niveau 1]
- Documenter chaque entete de package, chaque entete de fonction
- Une fonction ne doit pas dépasser 100 lignes - il y a cependant des exceptions à cette règle
[Niveau 2]
- Lire ces livre:
* Design Pattern (GoF)
* CERT (https://www.securecoding.cert.org/co...ndard+for+Java)
* Meyer & Jossutis (C++)

[parou]

Keep it simple

[Pelote2012]

Pour ma part, le 1er travail est de bien comprendre le besoin (actuel et futur) , en posant des questions, en mettant par écrit, demandant des cas concrets (curiosités)
En suite, il faut analyser les différentes options qui se présentent pour répondre aux besoins
Puis coder propres et être rigoureux. Je penses que la qualité 1ere d'un développeur est sa capacité à être carré dans sa tête. Les brouillons, les supers-codeurs (astuces de furieux) parfois ça marches, mais s'il faut faire évoluer le code ... que faire, devoir tout réécrire (comme ça m'est déjà arriver, car le gars à l'origine de l'appli à optimiser son code à mort mais du coup rendu tellment spécifique que toute modif même mineure, étaient impossible)
Parfois vaut mieux un code moins évolué mais évolutif.
Pour le reste :
Les noms de variables , de fonction ... en termes explicites
La solution la plus simple est toujours la meilleure
des commentaires sur les parties plus compliquées
NE SURTOUT PAS SE FAIRE CONFIANCE (vérifier toujours son boulot)
Comprendre avant de faire un copier/coller (quite à faire une petite appli à part)
Touche perso, je travaille toujours en itératif (je fais je refais je rerefais...), une simplification amène toujours une autre. (je précise qu'à chaque tour mon appli est stable )
...

[felxio]

En tant que débutant et ayant rencontré des difficultés de débutant, je suis totalement d'accord avec le classement de el_slapper.

[EtherOS]

+---------------------+
+ PROPOSITION +
+---------------------+

Tous les propositions données sont bonnes. ma proposition pour le développement est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
♥  Analyser : ceci dit avoir des objectifs Clairs,voir si ca repond a un besoin, des données clairement etablies , ceci dit faire l' elaboration des UML,etc... pour structurer clairement les classes et diagrammes ,la structure detaillée du programme.
♥  Mise en algorithmique en suivant par exemple le modèle LEA
♥  Programmer : faire un code clair , bien commenté, lisible, bien indente et suivant une logique syntaxique propre (ie attribut des noms ayant un sens et lies au contexte de votre objectif) a vos variables ou paramètres.
♥ Compilation : rechercher l 'erreur progressivement bref suivre la recherche de manière iterative , corriger les fautes de syntaxe , les variables mals attribuées et les bugs.
♥ Optimisation : corriger le code afin de le ramener a l' objectif visé , rendre l usage facile par l'utilisateur , rendre la presentation du programme plus beau , esthetique et élégant .

[el_slapper]

+---------------------+
+ PROPOSITION +
+---------------------+

Tous les propositions données sont bonnes. ma proposition pour le développement est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
1  Analyser : ceci dit avoir des objectifs Clairs,voir si ca repond a un besoin, des données clairement etablies , ceci dit faire l' elaboration des UML,etc... pour structurer clairement les classes et diagrammes ,la structure detaillée du programme.
2  Mise en algorithmique en suivant par exemple le modèle LEA
3 Programmer : faire un code clair , bien commenté, lisible, bien indente et suivant une logique syntaxique propre (ie attribut des noms ayant un sens et lies au contexte de votre objectif) a vos variables ou paramètres.
4 Compilation : rechercher l 'erreur progressivement bref suivre la recherche de manière iterative , corriger les fautes de syntaxe , les variables mals attribuées et les bugs.
5 Optimisation : corriger le code afin de le ramener a l' objectif visé , rendre l usage facile par l'utilisateur , rendre la presentation du programme plus beau , esthetique et élégant .

Il manque à mon sens un feedback sur la conception de haut niveau(tes étapes 1 et 2). Tes étapes 3, 4 et 5 me paraissent parfaitement adaptées : on découvre progressivement le problème en le codant, en le compilant, et en le testant, et c'est ainsi que l'on en améliore la compréhension. Sauf que souvent, celà a un impact sur l'algorithmique prévue, voire sur l'analyse initiale.

Un projet mené sérieusement envisage que les êtres humains ne sont pas parfaits, et que la conception de base peut avoir loupé certaines choses. Ca ne la rend pas inutile, au contraire(sinon on ne sait pas ou on va), juste, elle ne doit pas être sacrée.

[mitkl]

Petite mise-à-jour pour signaler la série n'étant pas terminée, de nouvelles interviews sont apparues, voici un aperçu :

• Rob Pike : Rob Pike est un programmeur très expérimenté. Il a travaillé chez Bell Labs sur le projet Unix en côtoyant chaque jour les célèbres Thompson, Kerninghan et Ritchie. Depuis 2002, il travaille chez Google. Il est l'un des créateurs du langage Go. Son conseil, c'est Ken Thompson qui lui a donné : "Si vous plongez directement dans le bug, vous allez régler un problème local dans le code. Mais si vous réfléchissez à comment le bug est apparu, vous allez souvent trouver et corriger un problème d'un plus haut niveau dans votre code. Cela améliorera son design et empêchera l'apparition de nouveaux bugs.
• Russ Olsen : Russ Olsen est l'auteur du livre Eloquent Ruby. Il n'a pas réellement de conseils à donner, juste une expérience amusante à partager.

[Luckyluke34]

Quel est le meilleur conseil à suivre quand on programme ?

Avancer par petites étapes mesurables plutôt que se lancer sans filet dans un développement gigantesque.

Une bonne technique est la suivante :

1. Définir le but de la prochaine petite étape (une méthode, une classe...) et créer un moyen d'en mesurer le succès : un test unitaire par exemple.

2. Ecrire le code nécessaire pour compléter l'étape.

3. Recueillir le feedback de notre mesure. Si c'est un échec, retourner à 2. Si c'est un succès, enjoy ! Ca parait tout bête, mais ces petits "moments de satisfaction" sont un très bon carburant.

Avec ça j'ajouterais le conseil de Mark Summerfield (en fait, plutôt de Kent Beck ou Martin Fowler) à savoir refactorer le code à la fin de chaque étape.