Bonjour, voilà j'apprends à coder tout seul, parce que j'aime ça, et je pense m'en sortir plutôt pas mal en C, php et bash.
Mais j'ai de grosses lacunes en ce qui concerne la modélisation. Je me rends bien compte que le fait de coder à l'arrache comme je le fait me faire perdre beaucoup de temps. Voila, ça c'était pour le background :)
En ce moment je suis en train de faire un jeu d'élevage en php/Mysql, juste par plaisir, et je me demande si l'UML est mon copain dans ce cas. Qu'en pensez vous ?
Quelqu'un pourrait t'il me conseiller sur un langage de modélisation pour un langage qui n'est pas orienté objet comme le C ?
J'avoue que je ne sait pas par où commencer, ça me retarde dans mon apprentissage. Quelqu'un pourrais me montrer moi des tutos ou des cours qui sont bien faits ?
J'ai souvent STFW à ce sujet, mais je me retrouve noyé de docs et je ne peux pas faire le tri rapidement alors je me permet de demander.
Voilà, a vot' bon coeur M'sieurs Dames :)
# Langages de modelisation
Posté par snt . Évalué à 2.
[^] # Re: Langages de modelisation
Posté par zouf . Évalué à 1.
Je vais jeter un rapide coup d'oeil à Merise, mais si je peux tout faire avec UML, autant me focaliser sur ça, même si c'est plus dur à appréhender. Est ce une bonne démarche, sachant que je ne suis pas pressé, selon toi ?
J'irai me procurer le bouquin d'O'REILLY sur le sujet au plus tôt pour faire ça un peu sérieusement.
Par contre, UML est il adapté si je cherche à créer une appli en C à ton avis ?
Je croyais qu'il était uniquement adapté aux langages orientés objet, mais après tout, peut être que l'idée "qui peut le plus peut le moins" fonctionne dans ce cas.
[^] # Re: Langages de modelisation
Posté par snt . Évalué à 2.
Pour le fait de faire du C à partir de schemas UML, moi ca ne me choque pas. UML est fortement orienté objet mais ca n'empeche pas que les phases de modelisation permettent de rendre les choses plus claires. Par exemple le diagramme de séquence qui spécifie les interactions entre les différents acteurs du système est pour moi tres utile pour eclaircir les choses indépendament du langage choisi pour l'implémentation.
Le diagramme de classe va t'etre un peu moins utile meme si il peut toujours servir pour constuire des structures de données pas trop mal fichues.
C'est parce que tu ne pourra pas utiliser tout UML que ce que tu utilisera ne te sera pas utile.
[^] # Re: Langages de modelisation
Posté par zouf . Évalué à 1.
Merci beaucoup.
# papier + crayon
Posté par Krunch (site web personnel) . Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: papier + crayon
Posté par zouf . Évalué à 1.
Ca m'interesse de savoir.
Je me trompe peut être, mais il me semble que je peux trés bien écrire une appli en UML sur papier, non ?
[^] # Re: papier + crayon
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: papier + crayon
Posté par FReEDoM (site web personnel) . Évalué à 1.
Non tu ne te trompe pas :)
Cependant, c'est mon avis personnel, UML me semble necessaire et efficace pour des projets impliquant plusieurs personnes. Pour un projet où tu est le seul developpeur, un papier , un crayon et de la reflexion sont tes meilleurs amis. Les schémas, même hideux, sont par exemples de très bon support à la conception.
[^] # Re: papier + crayon
Posté par totof2000 . Évalué à 4.
[^] # Re: papier + crayon
Posté par FReEDoM (site web personnel) . Évalué à 1.
Et en plus c'est relativement pour plein d'autre domaine autre que l'informatique ...
C'est malheureux mais c'est comme ça :) (je suis le premier à rechigner à faire de la doc)
[^] # Re: papier + crayon
Posté par totof2000 . Évalué à 2.
De toute facon, tot ou tard le temps passe a faire la doc est gagné: moins de temps a expliquer les grandes lignes du projet a un développeur qui voudrait s'y mettre, moins de temps pour ce nouveau développeur pour comprendre le fonctionnement du logiciel ... donc tant qu'a faire, autant prendre quelques minutes supplémentaires qui seront vites rentabilisées.
[^] # Re: papier + crayon
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: papier + crayon
Posté par zouf . Évalué à 0.
Je vois tout à fait ce que tu veux dire, mais, va savoir pourquoi, à chaque fois que je mets sur papier les idées de mon prog, je fini toujours par écrire directement du code à peine simplifié.
Et finalement je n'arrive pas à prendre assez de recul. Ce qui fait que au cours de l'écriture je me dis: "Ah tiens, ça je vais plutot le faire autrement."
Du coup me voilà en train de reprendre un bout de code, et de fil en aiguille, je ré-ecrit beaucoup de code. En fait je pense mon programme en codant, ce qui est absurde, je m'en rends bien compte maintenant.
Ce qui me manque en fait ce sont les bases.
tout ceci est obscur pour moi, sans doute parce que je n'ai suivit aucun cours, ni ne me suis réellement documenté sur le sujet.
En tout cas merci, mine de rien j'y vois un peu plus clair maintenant.
</ma_vie>
[^] # Re: papier + crayon
Posté par FReEDoM (site web personnel) . Évalué à 1.
Qqs autres conseils en vrac (attention je ne suis qu'à moitié développeur dans la vie de tous les jours donc tu en prends ce que tu veux)
- N'essaye pas de gagner du temps sur des astuces de programmation (j'entends les vielles ruses sioux), pense aux algorythmes derrieres qui doivent être le plus simple et le plus carré possible. ça t'aidera et ça aidera ceux qui veulent te relire. Ce genre d'optimisation sont en générales inutiles (à part pour des parties précises d'un OS) et génératrices de bug
- Evite le copier / coller : ça à l'air con , évident, MAIS la factoristion de ton code est une chose TRES importante. ça te permet d'être plus lisible, de faire évoluer ton code beaucoup plus simplement. (Par expérience quand tu programme un jeu 2D : les 4 directions doivent être souvent traités de la même manière)
[^] # Re: papier + crayon
Posté par totof2000 . Évalué à 2.
Au minimum, un projet libre devrait contenir un schema structurel de l'appli, et référencer les modules qui correspondent a chaque element de ce schema.
Et finalement je n'arrive pas à prendre assez de recul. Ce qui fait que au cours de l'écriture je me dis: "Ah tiens, ça je vais plutot le faire autrement."
Du coup me voilà en train de reprendre un bout de code, et de fil en aiguille, je ré-ecrit beaucoup de code. En fait je pense mon programme en codant, ce qui est absurde, je m'en rends bien compte maintenant.
Tu développe depuis longtemps? Ca en général c'est ce qui se passe pour ceux qui "débutent" en développement. Avec l'expérience ca va mieux (je me marre parfois lorsque je relis des bouts decode" que j'ai écrits durant mes études).
tout ceci est obscur pour moi, sans doute parce que je n'ai suivit aucun cours, ni ne me suis réellement documenté sur le sujet.
Il ne faut pas se décourager, ca vient avec la pratique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.