Discussion :

[miasou]

Bonjour tout le monde,

voila j'ai commencé à coder mes première appllications, je suis content, sauf que je trouve que ma manière de coder est ... comment dire affreuse.

Je suis tombé par hasard sur cet article

L'auteur explique qu'il ne faut pas passer beaucoup de temps sur le code et qu'il faut passer plus de temps à réfléchir sur comment on va coder, il va même à dire qu'il faut donner 20% de son temps au code et 80% à la refléxion.

Je suis un peu perturbé vis a vis de ça. Pensez vous que je dois appliquer ce qu'il dit ou qu'il y'a un problème dans sa méthode

[thelvin]

Oui. Quand on ne sait pas où on va, ça prend bien plus de temps pour y arriver.
Si on réfléchit d'abord à quoi vont ressembler les étapes, et qu'on les organise bien sous forme d'idée et pas de code, le code sera écrit plus vite et avec moins de bizarrerie.

Le problème c'est quand on ne sait pas encore assez bien coder pour savoir comment transformer une idée en code, ou si c'est seulement possible. Dans ce cas-là il n'y a pas de miracle, on devient forcément meilleur avec l'habitude.
Il y a forcément un peu de temps qui doit être passé à chercher comment on code telle ou telle idée. Ce qu'il faut fse rappeler, c'est qu'une fois qu'on a compris, ce code qu'on a cherché, il est moche et mal fait. Alors on met ce code de côté pour se rappeler comment on a fait, et on recommence tout, d'abord en réfléchissant à ce qu'on va faire, et ensuite en le codant.

[miasou]

Merci d'avoir pris la peine de me répondre, c'est exactement la réponse que je cherchait

[hwoarang]

Il faut savoir qu'on passe beaucoup plus de temps à maintenir son code qu'à l'écrire. Généralement, faire un programme demandé par un client/pour soi est plutot rapide (quelques semaines à quelques mois selon le projet). Par contre, la maintenance est très longue (plusieurs années).
En écrivant le programme en se lancant directement dans le code comme un cochon, on aboutit généralement au résultat voulu. par contre, on se retrouve avec plein de hack parce qu'on avait pas prévu une fonctionnalité qui entre en conflit avec l'architecture qui a été choisie. C'est pour ca qu'avoir un code réfléchi (et pas trop mal écrit parce qu'on a pris le temps de choisir une architecture adaptée) le rend beaucoup plus maintenable.
Et il ne faut pas oublier que dans une entreprise, il y a souvent plusieurs personnes qui travaillent sur le meme code. Et si le code d'un cochon est dur à maintenir, le code de plusieurs cochons est encore pire