Comment bien coder ?
Miasou06
Messages postés
4
Date d'inscription
Statut
Membre
Dernière intervention
-
KX Messages postés 16761 Date d'inscription Statut Modérateur Dernière intervention -
KX Messages postés 16761 Date d'inscription Statut Modérateur Dernière intervention -
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 ?
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 ?
A voir également:
- Comment bien coder ?
- Application pour apprendre à coder - Guide
- Comment déverrouiller un téléphone quand on a oublié le code - Guide
- Comment coder son whatsapp - Guide
- Tapez cette phrase, en respectant bien les espaces et la ponctuation. - Guide
- Comment débloquer un code puk - Guide
4 réponses
désolé j'ai oublié le lien de l'article le voici : http://www.blogduprogrammeur.com/comment-bien-coder/
Salut
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.En quoi est-ce affreux ?
Je suis tombé par hasard sur cet articleQuel article ?
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 ?Tout dépend du besoin, du contexte, de la complexité.
Oui en effet j'avais oublié le lien de l'article : http://www.blogduprogrammeur.com/comment-bien-coder/
Affreux genre je fais une grande partie du travail puis je constate que j'ai oublié quelque chose d'important et je dois refaire presque 70% de ce que j'ai déjà fait et des fois je suis totalement perdu.
Croyez vous que cete méthode puisse m'aider ?
Affreux genre je fais une grande partie du travail puis je constate que j'ai oublié quelque chose d'important et je dois refaire presque 70% de ce que j'ai déjà fait et des fois je suis totalement perdu.
Croyez vous que cete méthode puisse m'aider ?
Oui cette méthode peut t'aider mais je ne me focaliserais pas sur le rapport 80/20 du temps passé. Il suffit de suivre les étapes habituelles :
1- Définir les besoins : que veut l'utilisateur ?
2- Affiner les besoins : que doit faire l'application ? Dans quelles conditions ?
3- Décrire le fonctionnement de l'application : comment l'application répond aux besoins ? Quelles solutions techniques ?
Et seulement ensuite commencer à structure l'application puis la coder, tester, deployer, tester, deboguer, tester, etc
Si tu arrives à faire les étapes 1, 2 et 3 sans programmer alors effectivement tu gagneras bcp de temps pour la programmation proprement dite.
1- Définir les besoins : que veut l'utilisateur ?
2- Affiner les besoins : que doit faire l'application ? Dans quelles conditions ?
3- Décrire le fonctionnement de l'application : comment l'application répond aux besoins ? Quelles solutions techniques ?
Et seulement ensuite commencer à structure l'application puis la coder, tester, deployer, tester, deboguer, tester, etc
Si tu arrives à faire les étapes 1, 2 et 3 sans programmer alors effectivement tu gagneras bcp de temps pour la programmation proprement dite.
Bonjour,
Je trouve le rapport de 20/80 un peu "extrême" mais je pense que c'est volontaire de sa part pour faire comprendre que la réflexion est beaucoup plus importante que le codage.
Pourquoi ? (ce n'est que mon avis propre)
Tout simplement parce qu'aujourd'hui, on s'appuie de plus en plus sur la puissance montante de nos chères machines. Du coup, la moindre application minable demandera 200Mo de RAM pour fonctionner convenablement alors que bien codée, moins de 40Mo suffiraient. Les temps de réaction des applications s'allongent alors que la puissance de calcul de nos CPU augmente... contradictoire, non ?
Concevoir un bon algo ne veut pas dire concevoir un algo qui marche. C'est là toute la différence. Combien d'applis ne libèrent pas la mémoire quand les variables ne sont plus utilisées. Certaines ont même des processus qui restent ouverts après fermeture. Certaines ne sont absolument pas optimisées dans la gestion des traitements ou leur ordre. On a tendance à utiliser de mauvaises variables ou de mauvais traitements en se disant que ça passera toujours niveau mémoire. On a tendance à être fainéants. On sait que les machines récentes ont des bons CPU, au moins 4Go de RAM et un espace disque à ne plus quoi savoir en faire. On s'appuie dessus et on gaspille des ressources pour gagner du temps... mais au final, les applis sont gourmandes, de façon injustifiée, en CPU, en RAM, en temps pour l'utilisateur.
Coder une appli, c'est pas mal mais à la portée de tout le monde. Concevoir une bonne appli est beaucoup plus dur et nécessite de passer plus de temps à réfléchir qu'à coder ;-)
Je trouve le rapport de 20/80 un peu "extrême" mais je pense que c'est volontaire de sa part pour faire comprendre que la réflexion est beaucoup plus importante que le codage.
Pourquoi ? (ce n'est que mon avis propre)
Tout simplement parce qu'aujourd'hui, on s'appuie de plus en plus sur la puissance montante de nos chères machines. Du coup, la moindre application minable demandera 200Mo de RAM pour fonctionner convenablement alors que bien codée, moins de 40Mo suffiraient. Les temps de réaction des applications s'allongent alors que la puissance de calcul de nos CPU augmente... contradictoire, non ?
Concevoir un bon algo ne veut pas dire concevoir un algo qui marche. C'est là toute la différence. Combien d'applis ne libèrent pas la mémoire quand les variables ne sont plus utilisées. Certaines ont même des processus qui restent ouverts après fermeture. Certaines ne sont absolument pas optimisées dans la gestion des traitements ou leur ordre. On a tendance à utiliser de mauvaises variables ou de mauvais traitements en se disant que ça passera toujours niveau mémoire. On a tendance à être fainéants. On sait que les machines récentes ont des bons CPU, au moins 4Go de RAM et un espace disque à ne plus quoi savoir en faire. On s'appuie dessus et on gaspille des ressources pour gagner du temps... mais au final, les applis sont gourmandes, de façon injustifiée, en CPU, en RAM, en temps pour l'utilisateur.
Coder une appli, c'est pas mal mais à la portée de tout le monde. Concevoir une bonne appli est beaucoup plus dur et nécessite de passer plus de temps à réfléchir qu'à coder ;-)
Bonjour,
Je trouve le rapport de 20/80 un peu "extrême"
Evidemment il faut relativiser en fonction du contexte.
Je pense qu'une part de réflexion vient aussi d'un certain nombre d'essais/erreurs.
Si on est sur une nouvelle application, tout le code que l'on a écrit ne se retrouvera pas dans le produit final. Je vois le rapport 20/80 comme ceci : pour un code de 20 lignes on en a écrit 80 qui n'ont finalement servi à rien..
Mais si on est sur de la maintenance, c'est encore pire, on va perdre énormément de temps à déboguer pour trouver le problème, alors que souvent ça va se corriger en une ligne ou deux...
Je trouve le rapport de 20/80 un peu "extrême"
Evidemment il faut relativiser en fonction du contexte.
Je pense qu'une part de réflexion vient aussi d'un certain nombre d'essais/erreurs.
Si on est sur une nouvelle application, tout le code que l'on a écrit ne se retrouvera pas dans le produit final. Je vois le rapport 20/80 comme ceci : pour un code de 20 lignes on en a écrit 80 qui n'ont finalement servi à rien..
Mais si on est sur de la maintenance, c'est encore pire, on va perdre énormément de temps à déboguer pour trouver le problème, alors que souvent ça va se corriger en une ligne ou deux...