IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

Comment bien programmer en C ?


Sujet :

C

  1. #1
    Membre actif Avatar de lastrecrue
    Développeur Java
    Inscrit en
    Février 2006
    Messages
    360
    Détails du profil
    Informations personnelles :
    Âge : 41

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Février 2006
    Messages : 360
    Points : 278
    Points
    278
    Par défaut Comment bien programmer en C ?
    je voudrais apprendre a programmé en C.
    j'ai déjà des connaissance de base, mais je cherche quelque conseil qui me permettent de mieux avancé, alors si on veut avoir un bon programmé en C, quel sont les chose nécessaire a faire et ne pas faire.

  2. #2
    Expert éminent
    Avatar de PRomu@ld
    Homme Profil pro
    Ingénieur de Recherche
    Inscrit en
    Avril 2005
    Messages
    4 155
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2005
    Messages : 4 155
    Points : 6 486
    Points
    6 486
    Par défaut
    e voudrais apprendre a programmé en C.
    Qu'appele tu programment en C ? Le langage C est un outil, un bon programmeur doit savoir bien programmer et bien programmer, c'est connaitre et savoir utiliser à bon escient des algos, ensuite le langage Utilisé n'est là que pour transcrire les algos ...

    j'ai déjà des connaissance de base
    Ou t'es tu arrêté ?

    quel sont les chose nécessaire a faire et ne pas faire.
    Connaître ses limites est une bonne chose ! Ne pas essayer de bidouiller le code et savoir exactement ce que l'on fait est une bonne chose, ensuite, il y a des règles à bien suivre : bien nommer ses variables, effectuer des tests à chaque appel système, bien séparer les programmes en modules indépendants, éviter les "trucs" de hackers qui font gagner un cycle d'horloge sur dix minutes de calculs et produire du code le plus simple possible (plus c'est simple plus c'est facile à maintenir)

  3. #3
    Membre éprouvé Avatar de gnto
    Homme Profil pro
    Ingénieur système logiciel
    Inscrit en
    Janvier 2006
    Messages
    923
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur système logiciel
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Janvier 2006
    Messages : 923
    Points : 1 210
    Points
    1 210
    Par défaut
    salut,

    Je crois que l'algorithmie est très importante.
    Connaitre les structures avancées c'est pas mal par exemple pourquoi utiliser une liste plutot qu'un tableau ?

    Et a part certains points l'echelle du goret me semble un bon indicateur
    echelle du goret
    C'est très exhaustif !!

  4. #4
    Membre actif Avatar de lastrecrue
    Développeur Java
    Inscrit en
    Février 2006
    Messages
    360
    Détails du profil
    Informations personnelles :
    Âge : 41

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Février 2006
    Messages : 360
    Points : 278
    Points
    278
    Par défaut
    j'ai regarder votre echelle de goret je n'ai pas compris ces points:
    que signifie cette phrase "Utilisation d'expressions C non idiomatiques ".
    quand on a pas le choix"Plus d'un return par fonction ".

    ma question n'était pas la, je me pose la question si je vais faire un long programme, comment puise je etre sur que je ne vais pas devoir tous refaire après que je dépasse une centaine de ligne, quand je doit utiliser une macro, quand faire une fonction, comment découpé mon programme en plusieurs fonction sans perdre de son efficacité, est ce que une fonction qui appelle plusieurs fonction est une mauvaise chose, quand je doit faire pus d'un fichier, voila ce genre de question.

  5. #5
    Expert éminent
    Avatar de PRomu@ld
    Homme Profil pro
    Ingénieur de Recherche
    Inscrit en
    Avril 2005
    Messages
    4 155
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2005
    Messages : 4 155
    Points : 6 486
    Points
    6 486
    Par défaut
    'ai regarder votre echelle de goret je n'ai pas compris ces points:
    que signifie cette phrase "Utilisation d'expressions C non idiomatiques ".
    quand on a pas le choix"Plus d'un return par fonction ".
    On en a parlé il n'y a pas si longtemps que cela et il en était ressorti que cette échelle était issue d'expérience purement personnelle et que certain points étaient presque discutables . D'ailleurs, j'ai l'occasion quelque fois de coder comme un goret en programmation système. (Emmanuel, je ne veux pas relancer la discution ... )

    Je ne pense pas que c'est un document qui peut t'aider. En revanche, les notes sont très utiles :

    http://emmanuel-delahaye.developpez.com/notes.htm

    Ensuite les conventions de codage sont tout aussi importantes (même si tu n'es pas obligé de respecter scrupuleusement tout ceci, ça reste indicatif)

    http://emmanuel-delahaye.developpez.com/codage.htm

    Pour finir avec les liens sur le site d'Emmanuel, je te recommande aussi ceci :

    http://emmanuel-delahaye.developpez.com/complog.htm

    je me pose la question si je vais faire un long programme, comment puise je etre sur que je ne vais pas devoir tous refaire après que je dépasse une centaine de ligne
    En fait qu'appelle tu tout refaire ? En fait, ça n'est pas à cause du langage que tu devra tout refaire, c'est de la conception, et ça, ça ne se fait pas devant un clavier et un écran, c'est avec un papier et un crayon. Il faut absolument que lorsque tu code, ça ne soit que la dernière étape. Que tu n'ai pas à réfléchir sur l'agencement entre les modules. Parce que si cette reflexion se fait pendant que tu codes, tu es quasiment sur de faire n'importe quoi et produire du code qui ne sera pas bon.

    quand je doit utiliser une macro, quand faire une fonction
    Pour répondre à ces questions, il faut comprendre que les macros sont des éléments du préprocesseur et donc d'un simple analyseur de texte. Les fonctions appartiennent au langage. c'est le code qui sera compilé. Alors quand choisir entre l'un et l'autre ? Bonne question ! En fait, une macro c'est pour regrouper une ou deux instructions assez simple (MIN, MAX, ...), ou alors des instruction assez répétitives (allocations mémoire et vérification). Ensuite, il y a les personnes qui ne font que des macros ... ( même en cours, on a eu l'occasion de faire une liste chainée générique entierement avec les macros ...) mais, ça n'est pas une bonne chose parce que c'est long à écrire et mon lisible quavec des fonctions. Comme je te l'ai dis au premier post, privilégie la simplicité. Si tu dois passer une heure à écrire une macro, vérifier les effets de bords éventuels, c'est trop long (sauf si tu en vois une utilité primordiale pour ton programme).

    comment découpé mon programme en plusieurs fonction sans perdre de son efficacité
    Le cout d'un appel de fonction est on va dire assez dérisoire et il existe des mécanismes pour les éviter (inline et compagnie). Ca rejoint ce que je t'ai dis au premier post : si c'est pour gagner quelques cycles d'horloge sur un temps d'éxécution significativement plus long, ça n'est pas la peine. En revanche, si ta fonction est très courte, là utilise une macro.

    Tout est une question de conception de tes programmes, il faut regrouper dans une fonction des instructions permettant d'effecuer une action bien définie (par exemple tu regroupes toutes les insttructions pour calculer une racine carrée dans une fonction racine).

    De plus, tu as l'air d'avoir toujours en tête des problèmes de performance. Il faut savoir que l'optimisation est une des dernières phases du développement : tu fais quelque chose de fonctionnel dans un premier temps, tu utilise un profiler pour savoir quels sont les fonctions qui prennent le plus de temps et tu regarde ensuite comment les optimiser. Si tu commences par l'optimisation en premier, tu ne sauras pas quel est la partie qui ne fonctionne pas ; ton programme de base ou ton optimisation.

    Mais n'oublie pas, l'optimisation par le langage de programmation ne représente qu'une infime partie de ton optimisation. La majeure partie de l'optimisataion concerne le choix des algos. Un tri par tas non optimisé (optimisations compilateur et langage) sera plus rapide qu'un tris par insertion optimisé sur un jeu de donnée assez conséquent.

    est ce que une fonction qui appelle plusieurs fonction est une mauvaise chose
    Non pas du tout, le langage C est un langage de fonction, alors utilises les ! Quand tu dois effecter des E/S sur un fichier, tu ouvres le fichier, tu écrit ou tu lis dedans, et tu finis par le fermer, tout est fait avec des appels de fonction ...

    quand je doit faire pus d'un fichier,
    Un fichier par module indépendant. Tu ne fais pas un fichier par fonction. Tu regroupes sous un même fichier des fonctions qui ont la même utilité : fonctions mathématiques, fonction d'E/S. Pour ceci inspire toi de ce qui est fait dans la bibliothèque standard.

  6. #6
    Membre habitué Avatar de skip78
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    247
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2006
    Messages : 247
    Points : 133
    Points
    133
    Par défaut
    Citation Envoyé par lastrecrue
    si je vais faire un long programme, comment puise je etre sur que je ne vais pas devoir tous refaire après que je dépasse une centaine de ligne

    Non sinon pour être à l'aise en programmation, un seul mot d'ordre : l'expérience

    Si tu as le courage de te pencher sur un tuto, tu lis les bases et tu code toi même tous les programmes exemples.
    Une fois que tu as toutes les bases, entraine toi à creer toi même tes petits programmes, puis quand tu seras fin prêt, étudie une API quelconque, par exemple pour developper un petit jeu, et si tu te fait plaisir, tu prendra la main

  7. #7
    Rédacteur

    Avatar de millie
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    7 015
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 7 015
    Points : 9 818
    Points
    9 818
    Par défaut
    Il m'est déjà arrivée de coder un gros programme assez salement, puis qq mois (ou même pas), le recommencer complétement avec une nouvelle vision (plus pratique, plus performante, plus PROPRE). C'est vraiment qqch qui m'a bien permis de progresser. Pour des gros programmes, au début, c'est pas toujours facile de toujours prévoir tout d'avance, on fait des erreurs, on corrige assez salement, et au final, ça marche mais ce n'est pas terrible. Mais on peut analyser après coup toutes les erreurs qu'on a fait pour ne plus les faire la fois d'après.

    Donc, l'expérience...
    Je ne répondrai à aucune question technique en privé

  8. #8
    Membre habitué Avatar de _kal_
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2006
    Messages
    178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Janvier 2006
    Messages : 178
    Points : 156
    Points
    156
    Par défaut
    J'aimerai savoir comment vous procédez lorsque vous vous lancez dans un nouveau projet. Faites vous tout à la main, à savoir :
    • Ecrire sur papier l'ensemble des fichiers
    • Ecrire sur papier le nom des différentes fonctions et leur type etc...


    Cela me parait difficile, il faut penser au programme avant de l'avoir conçu
    Quelque chose qu'on nous apprend pas à l'université, car nous sommes guidé fonction par fonction donc bon...

    J'entend souvent parler d'UML et design paterns, cela s'applique-t-il aussi au C qui n'est pas orienté objet (même si on peux faire de l'objet en C) ?

    Merci de vos indications, car j'ai souvent envi de me lancer dans mon premier GROS programme (interface graphique, utilisation de plusieurs bibliothèque etc...), mais je ne sait toujours pas comment m'y lancer (et je n'aime pas la programmation spontanée).


  9. #9
    Expert éminent
    Avatar de PRomu@ld
    Homme Profil pro
    Ingénieur de Recherche
    Inscrit en
    Avril 2005
    Messages
    4 155
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2005
    Messages : 4 155
    Points : 6 486
    Points
    6 486
    Par défaut
    Cela me parait difficile, il faut penser au programme avant de l'avoir conçu
    C'est toujours pareil quelque soit le projet (aéronautique, technique), tu es obligé de penser à ton projet sans l'avoir vu.

    Ecrire sur papier l'ensemble des fichiers
    Non, tu penses trop technique, l'ensemble des fichiers n'est pas important et ça n'est pas la première chose à penser. Il faut que tu penses au découpage de ton programme, les modules à créer et à utiliser.


    Quelque chose qu'on nous apprend pas à l'université, car nous sommes guidé fonction par fonction donc bon...
    Ne fais tu pas de projets dans ton université ?

    J'entend souvent parler d'UML et design paterns, cela s'applique-t-il aussi au C qui n'est pas orienté objet (même si on peux faire de l'objet en C) ?
    L'UML permet de présenter ton projet, c'est une formalisation de ton programme, ça aide à faire comprendre ce que tu fais mais ça n'aide pas à la reflexion sur ton programme ( mais je n'ai pas dis que c'était inutile).

    Les design pattern, ne sont pas interressant, c'est juste bon d'en connaître quelques uns (et encore ...), c'est à mon avis un truc de "geek" (désolé) qui ne te servira quasiment jamais en C. (On dirait que le terme a été inventé par des commerciaux, c'est génial ça fait tout, et en fait, c'est du vent car ce sont des pratiques que bon nombre connait et utilise en toute logique ...)

    interface graphique
    Si je peux te conseiller une chose avec un tel projet, utilises le modle MVC, c'est à dire séparer les données sur lequels tu travailles et ton interface. Ca permet de ne pas tout mélanger et ça te permet aussi de pouvoir changer d'interface graphique sans trop de problème.

    mais je ne sait toujours pas comment m'y lancer
    Plusieurs techniques, j'utilises la plupart du temps l'analyse descendante. Tu liste grossièrement ce que doit faire ton programme, ensuite, tu essais de faire un découpage grossier de ton programme (j'ai besoin de faire tel ou tel module). Après tu regardes module par module quels sont les fonctions dont tu auras besoin (peut être t'as t'on parlé dans ton université de fonctions minimales). Et enfin, fonctions par fonctions tu regardes les algos à employer s'il y en a.

  10. #10
    Expert éminent sénior
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Points : 20 985
    Points
    20 985
    Par défaut
    Citation Envoyé par _kal_
    J'aimerai savoir comment vous procédez lorsque vous vous lancez dans un nouveau projet. <...> Merci de vos indications, car j'ai souvent envi de me lancer dans mon premier GROS programme (interface graphique, utilisation de plusieurs bibliothèque etc...), mais je ne sait toujours pas comment m'y lancer (et je n'aime pas la programmation spontanée).
    La conduite d'un projet est un art difficile et, tu le confirmes, non enseigné.

    En fait, il n'y a pas de méthode rigide et rigoureuse, simplement quelques principes de bon sens qu'il convient d'appliquer, à savoir qu'il faut respecter une certaine séquence dans l'exécution des tâches.

    En gros, et quelque soit le niveau, on doit suivre cette séquence :
    1. Définition (Quoi ?)
    2. Conception (Comment ?)
    3. Réalisation
    4. Integration
    5. Validation

    1 - La définition traduit noir sur blanc les désirs du client. Les imprécisions et autres incohérences doivent être levées.

    2 - La conception permet de spécifier les comportements sous la forme d'algorithmes et/ou de machines à états, et de découper le projet en unités plus petites (blocs fonctionnels ou BF). En gros, on arrive à un arbre dont les branches sont des BF de plus en plus fins. Dans un projet informatique pur, en gros, les feuilles sont les fonctions.

    3 - Celles-ci sont ensuite codées et testées individuellement.

    4 - Ensuite, on remonte d'un cran et on assemble les morceaux, on les fait communiquer on teste le résultat etc. Quand l'ensemble est assemblé, on a le produit. On le teste massivement (tests d'integration), et on corrige les derniers détails (interfaces, performances...).

    5 - Enfin, le comportement du produit est comparé avec les exigences de la définition de celui-ci.

    Ce principe de base bien connu (méthode en V) ne doit pas s'appliquer de façon brutale à un énorme projet, sinon, on risque de pertdre en visibilité, et de s'apercevoir au bout de 3 ans que le projet est trop coûteux ou qu'il utilise des technologies à la Star Trek...

    C'est là qu'intervient la notion de méthode 'agile' (Comme eXtrem Programming, ou XP), qui considère qu'il faut au préalable découper le projet en une successions de mini projets cohérents (itérations courtes). Chaque itération nouvelle utilise la ou les itérations précédentes censée avoir été validée par la méthode en V.

    Le but est d'avoir très rapidement (< 1 mois) un résultat tangible qui permet de valider et de corriger la définition et la conception du projet. Si un choix technologique se révèle inadéquat ou désatreux, on est prévenu plus rapidement, et on peut envisager une nouvelle orientation.

    D'autres principes de XP sont interessants comme
    • Le codage en binôme
    • Le codage par les tests
    • etc.
    Pas de Wi-Fi à la maison : CPL

  11. #11
    Membre actif Avatar de lastrecrue
    Développeur Java
    Inscrit en
    Février 2006
    Messages
    360
    Détails du profil
    Informations personnelles :
    Âge : 41

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Février 2006
    Messages : 360
    Points : 278
    Points
    278
    Par défaut
    Citation Envoyé par PRomu@ld
    L'UML permet de présenter ton projet, c'est une formalisation de ton programme, ça aide à faire comprendre ce que tu fais mais ça n'aide pas à la réflexion sur ton programme ( mais je n'ai pas dis que c'était inutile)..
    qu' est ce qu' une UML?
    si non je me demande finalement pour le passage d'un niveau de conception a un autre par exemple pour la création d'un jeu pour passé du mode console en mode graphique, quel sont les étapes nécessaires pour avoir un beau résultat graphique, je pense a la SDL.

  12. #12
    Expert éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    Par défaut
    Citation Envoyé par lastrecrue
    qu' est ce qu' une UML?
    UML est un langage de modelisation qui permet d'exprimer differentes choses a propos d'un programme, dont:
    - sa structure statique
    - sa structure dynamique
    - le comportement temporel
    - les cas d'utilisation
    - d'autres choses qui m'echappent pour le moment.

    Les diagrammes UML qu'on voit le plus souvent sont les premiers.

    UML a ete developpe et est principalement utilise dans le cadre de methodologies de conception orientees objets, mais rien n'empeche de s'en servir dans d'autres contextes.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  13. #13
    Expert éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    Par défaut
    Citation Envoyé par PRomu@ld
    Les design pattern, ne sont pas interressant, c'est juste bon d'en connaître quelques uns (et encore ...), c'est à mon avis un truc de "geek" (désolé) qui ne te servira quasiment jamais en C. (On dirait que le terme a été inventé par des commerciaux, c'est génial ça fait tout, et en fait, c'est du vent car ce sont des pratiques que bon nombre connait et utilise en toute logique ...)
    Tu sembles avoir percu l'essentiel de la nature des design pattern (ce sont des pratiques eprouvees) sans en percevoir les interets:
    - le premier, c'est de leur donner un nom; ce qui permet d'en parler sans recourir a de longues descriptions ("a ta place, j'utiliserais une factory", c'est simple, ca va droit au but, "a ta place, j'utiliserais des classes virtuelles et une classe qui permet de construire les classes derivees, un peu comme on a fait dans le projet X", c'est ambigu, ca demande des explications complementaires ...)
    - ce sont des pratiques qui ont ete etudiees en tant que telles, en cherchant a decrire le genre de problemes qu'elles resolvent (donc on a une forme canonique qu'on utilisera si on n'a pas de bonnes raisons de faire autrement, ce qui favorise l'uniformite et donc la robustesse, et une analyse de variantes possibles avec leur qualites et leurs defauts)

    C'est un genre de bonnes pratiques de conception. Comme toute bonnes pratiques, ce n'est pas quelque chose de genial, c'est quelque chose que beaucoup faisaient plus ou moins consciemment. Mais il y a un interet a les utiliser de maniere consciente.

    Maintenant, comme tout sujet qui a ete a la mode, il y a eu un usage marketing, il y a eu ceux qui ont cherche a mettre dans tous les programmes toutes celles du bouquin sans chercher a voir si elles s'appliquaient reellement a leur probleme, il y a eu ceux qui ont cherche a "inventer des DP" en partant de rien, sans remarquer que c'etait un non sens: une DP, c'est un schema recurrent dans la conception de programmes, on ne les invente pas, on les remarque apres les avoir rencontrees... Et comme toujours quand il y a une reflexion plus abstraite, ca peut etre aussi un moyen pour certains d'eviter de redescendre vers le concret.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  14. #14
    Membre habitué Avatar de _kal_
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2006
    Messages
    178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Janvier 2006
    Messages : 178
    Points : 156
    Points
    156
    Par défaut
    Citation Envoyé par PRomu@ld
    Non, tu penses trop technique, l'ensemble des fichiers n'est pas important et ça n'est pas la première chose à penser. Il faut que tu penses au découpage de ton programme, les modules à créer et à utiliser.
    Chose que je n'ai jamais fait et que je ne sais pas comment approcher. Un diagramme sagital peut-être ?
    Citation Envoyé par PRomu@ld
    Ne fais tu pas de projets dans ton université ?
    Si, mais ils sont tous guidés ; par exemple, on nous demande d'écrire la classe A, et on s'aperçoit qu'un jour elle finit par nous servir lors du codage de la classe C
    Je suis qu'en seconde année, donc peut être qu'un jour j'aurai un vrai projet à mener.
    Citation Envoyé par PRomu@ld
    L'UML permet de présenter ton projet, c'est une formalisation de ton programme, ça aide à faire comprendre ce que tu fais mais ça n'aide pas à la reflexion sur ton programme ( mais je n'ai pas dis que c'était inutile).
    C'est peut-être ce qu'il me faudrai, car mon problème s'articule autout du découpage de mon programme, dont je ne sait aucunement comment aborder.
    Citation Envoyé par PRomu@ld
    Si je peux te conseiller une chose avec un tel projet, utilises le modle MVC, c'est à dire séparer les données sur lequels tu travailles et ton interface. Ca permet de ne pas tout mélanger et ça te permet aussi de pouvoir changer d'interface graphique sans trop de problème.
    Je ne connais pas MVC, je vais googlé ça
    Citation Envoyé par PRomu@ld
    Plusieurs techniques, j'utilises la plupart du temps l'analyse descendante. Tu liste grossièrement ce que doit faire ton programme, ensuite, tu essais de faire un découpage grossier de ton programme (j'ai besoin de faire tel ou tel module). Après tu regardes module par module quels sont les fonctions dont tu auras besoin (peut être t'as t'on parlé dans ton université de fonctions minimales). Et enfin, fonctions par fonctions tu regardes les algos à employer s'il y en a.
    Oui, cela se rapproche de la notion de méthode 'agile' décrite par Emmanuel. Il est préférable pour mon premier projet de m'orienter vers ce type de technique, afin d'apercevoir le bout du tunnel
    Citation Envoyé par Emmanuel Delahaye
    C'est là qu'intervient la notion de méthode 'agile' (Comme eXtrem Programming, ou XP), qui considère qu'il faut au préalable découper le projet en une successions de mini projets cohérents (itérations courtes). Chaque itération nouvelle utilise la ou les itérations précédentes censée avoir été validée par la méthode en V.

    Le but est d'avoir très rapidement (< 1 mois) un résultat tangible qui permet de valider et de corriger la définition et la conception du projet. Si un choix technologique se révèle inadéquat ou désatreux, on est prévenu plus rapidement, et on peut envisager une nouvelle orientation.
    Ce type d'approche n'accentue pas les risques de bugs ? Je n'ai jamais réaliser de modélisation logiciel, et je pense à investir dans un livre à ce sujet. Peut être celui-ci correspondrait à mes besoins :
    http://www.eyrolles.com/Informatique...rogramming.php
    Ou celui-ci:
    http://www.eyrolles.com/Informatique...rogramming.php

    UML peut il réaliser le découpage que je cherche (et aussi en toute aisance) ?

    C'est là qu'on se rend compte que savoir programmer est une chose, concevoir un logiciel en est une autre.

    Ici, mon objectif est de porter un logiciel sous Linux, existant uniquement sous Windows. L'interface graphique reposera sur l'api GTK+-2.10. Ainsi, je connais déjà l'allure du logiciel, et ce qu'il réalise précisément. Ce qui me manque, c'est le découpage structurel.

  15. #15
    Expert éminent
    Avatar de PRomu@ld
    Homme Profil pro
    Ingénieur de Recherche
    Inscrit en
    Avril 2005
    Messages
    4 155
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2005
    Messages : 4 155
    Points : 6 486
    Points
    6 486
    Par défaut
    Citation Envoyé par Jean-Marc.Bourguet
    Maintenant, comme tout sujet qui a ete a la mode, il y a eu un usage marketing, il y a eu ceux qui ont cherche a mettre dans tous les programmes toutes celles du bouquin sans chercher a voir si elles s'appliquaient reellement a leur probleme, il y a eu ceux qui ont cherche a "inventer des DP" en partant de rien, sans remarquer que c'etait un non sens: une DP, c'est un schema recurrent dans la conception de programmes, on ne les invente pas, on les remarque apres les avoir rencontrees... Et comme toujours quand il y a une reflexion plus abstraite, ca peut etre aussi un moyen pour certains d'eviter de redescendre vers le concret.
    C'est ça que je voulais dénoncer, le coté énormément marketing, les design pattern à une époque faisaient tout (presque le café ...), C'était comme un peu tout : tout le monde en parlait, mais personne ne savait réelement à quoi celà consistait (beaucoup on brassé du vent en les évoquant ...), mais tout le monde était d'accord : "c'est génial".

    Oui, si on veut, le fait que les méthodes soient éprouvée est une bonne chose, leur donner un nom aussi, mais ça s'arrêtre là, pas la peine de créer un motif pour créer un motif (c'est surtout ça qui m'a embêter). Il faut en connaître quelques uns ( certains sont utilisés quasi quotidiennement sans en savoir le nom en fait ...), mais ne pas en faire tout un cinéma ...

    Citation Envoyé par _kal_
    Je suis qu'en seconde année, donc peut être qu'un jour j'aurai un vrai projet à mener.
    Ne t'inquiète pas, théoriquement dès l'an prochain tu devrais avoir un projet à faire sur plusieurs semaines (ça se fait beaucoup en troisième année), tu auras l'occasion de sortir du cadre purement académique. (oui, entre parenthèse, on dis qu'a la fac, on est pas assez guidé,encadré, perso je trouve que c'est le contraire en fait, mais bon passons.)

    Citation Envoyé par _kal_
    C'est peut-être ce qu'il me faudrai, car mon problème s'articule autout du découpage de mon programme, dont je ne sait aucunement comment aborder.
    Il faut que tu essais de sortir quelques parties de ton programme indépendantes : penses aux questions suivantes : j'ai besoin de faire ceci, c'est cette partie qui doit le faire, ceci, c'est cette partie qui doit le faire.

    Ce type d'approche n'accentue pas les risques de bugs ?
    Les méthodes comme XP intègrent d'autres caractéristiques qui permettent d'éviter les bugs : travail en binome, test unitaires et de non régression ...

    C'est là qu'on se rend compte que savoir programmer est une chose, concevoir un logiciel en est une autre.
    L'un est plutôt technique, l'autre est théorique.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Comment bien programmer en PHP ?
    Par Community Management dans le forum Langage
    Réponses: 257
    Dernier message: 01/12/2014, 16h48
  2. Comment bien déboguer son code ?
    Par D[r]eadLock dans le forum Débuter
    Réponses: 46
    Dernier message: 04/07/2013, 11h48
  3. Comment bien programmer web en java?
    Par lovelace dans le forum Développement Web en Java
    Réponses: 11
    Dernier message: 19/10/2008, 01h40
  4. Comment bien commencer la Programmation
    Par Le_Faya dans le forum Débuter
    Réponses: 6
    Dernier message: 01/12/2006, 19h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo