Recherche structure d'un programme!

Bonjour à tous!

Un peu de ma life, j'ai un diplôme d'analyste programmeur de niveau2 eut en 9 mois, du coup ça donne des bases très friables, de plus je suis dans une petite entreprise où je suis le seul développeur, en faite on est deux mais l'autre fait du vb6 non objet sans aucune analyse!

Ayant peur de devenir seulement un "bricoleur" je me met à acheter des bouquins sur la POO et des tutos sur UML!

Mais il y a un point commun, jamais de présentation de la structure d'un programme tout fait, sans implémentation des méthodes, juste la structure présentant les attributs les méthodes et les différentes couches du programme!

Alors voila je cherche simplement des exemples de programmes qui ont une structure correct à titre d'exemple et pour avoir une meilleure représentation lors de mes lectures!

Merci d'avance! (en espérant ne pas m'être trompé de section, je ne code pour le moment qu'en c#)

salut

poses une question précise, genre quelque type de structure ou d'architecture tu veux réaliser et on te donnera des pistes plus précises...

PArce que des "bibliothèques" toute faite pour résoudre toutes les situations, ya pas à ma connaissance !

Par contre, si tu nous dis : Je voudrais faire un logiciel de traitement de données, ou bien de calcul d'équation du 2nd dégré :), et beh, ma foi, on pourra te filer des pistes ou des idées :)

The Monz, Toulouse

Salut TheMonz!

Ma requête n'est pas destinée à avoir un modèle pour directement le copier pour mon usage personnel mais juste pour avoir la vision d'une structure propre!
Je ne veux pas d'un modèle qui résoudrait toutes les situations mais voir deux trois modèles qui respectent une vision d'un code correctement réalisé afin d'en avoir une vision concrète!

C'est en lisant les pages 164 et 165 de ce document que je me suis senti dans le besoin d'avoir des exemples:
ftp://ftp-developpez.com/laurent-aud.../Cours-UML.pdf

ok

tu as le tutoriel sur le MVC ici qui pourrait te servir de base dans la mesure ou il est bien écrit.

The Monz, Toulouse

Salut,

Fais une recherche sur "Design patterns" et des tutoriaux sur leurs implémentations et dans tes développements fais l'effort de systématiquement chercher quels Design pattern pourrait être appliqué.

Tu peux aussi rechercher "modèle en couche", "Model Driven Architecture (MDA)" et comprendre comment ça marche derrière, tout en faisant systématiquement l'effort de chercher à comprendre comment ca s'applique dans ton cas à toi (sinon ca ne sert à rien, ca restera trop théorique dans ta tête et tu ne feras jamais le pont entre théorie et pratique)

A force de pratiquer, tu apprendras automatiquement à structurer les choses, mais ca ne se fera pas du jour au lendemain, mais à force d'essayer, faire des erreurs et corriger.

Merci de ta réponse Harry_polin !

En effet je vais me diriger vers les design patterns pour avoir une idée!

Dernière question avant le résolu:

des ouvrages ou sites à proposer?

J'ai acheté récemment ce bouquin : C# 3.0 Design Patterns (Broché) . Il m'a raffraichi les idées sur les principaux design patterns et tout ça en C#.

Après c'est de l'anglais :) Mais bon, ya pas de secret, les meilleurs bouquins sont dans la langue de Shakespeare.

sinon, sur le net, tu cherches "design pattern" ou "GOF", et tu devrais trouver de la littérature :)

Après, faut pas non plus tomber dans le stéréotype suivant :

"Connaitre les designs patterns, c'est savoir programmer"

C'est archi faux.. Les design patterns ne sont là que pour résoudre des situations classiques et fréquentes que l'on rencontre au cours d'un développement... On peut être TRES bon développeur sans les connaitres !
(d'ailleurs souvent, un bon développeur les utilises sans forcément savoir que c'est un design pattern... mais ça doit faire bien dans les discussions mondaines de dire, j'ai utilisé le DP singleton , histoire de "se la péter")...

Perso, j'ai découvert les DP ya quelques années (après près de 15 ans de dev) et en les lisant, je me suis dit : "Ah, c'est ça.. beh, je le fais depuis longtemps sans le savoir" !!!


Pour moi, la meilleure approche pour devenir un "bon" développeur, c'est d'avoir des problématiques à résoudre et de se dire : "Comment je pourrais faire cela"... plutot que de se dire "Qui sur internet va me donner la solution"...

Chercher une solution et en inventé une te permettra de t'aguerrir en programmation... en tout cas, c'est le conseil que je donnerais aux "jeunes" développeurs... codez, codez et codez encore... et de tant en tant, demandez de l'aide sur le net... mais codez et codez encore.. Et surtout, réfléchissez et n'attendez pas trop en permanence de l'assistanat :)

The Monz, Toulouse

Je crois que je vais devoir me mettre sérieusement à l'anglais moi, j'ai de bonnes bases mais de là à lire un bouquin technique!

Sinon TheMonz je suis tout à fait d'accord avec toi, le seul problème c'est que comme je n'ai personne pour juger de la qualité de réalisation de mon travail ça m'inquiète un peu, les trucs tournent, mais ça veut pas forcement dire que c'est bien codé!

sinon Merci pour les réponses!

Ce qui est important de comprendre avec la mise en place des designs patterns, c'est que ca te permet de gagner de la souplesse de refactorisation.
C'est à dire que ça te permet de changer certains pans de ton programme, sans être obligé de changer toutes les dépendances.
Donc il faut voir par rapport à l'utilisation de ton programme : soit tu vises le court terme et le one shot, dans ce cas pas la peine de te prendre le choux et tu codes comme tu peux. Soit tu vises le long terme, l'évolution de technologies, la modularité, la réutilisabilité de ton code, ainsi que la qualité, et dans ce cas là l'architecture en couche, modèle MVC, design patterns et MDA, il vaut mieux les connaitre avant un minimum et faire l'effort de les appliquer correctement. Ça évite de tout reprendre de zéro et de faire perdre temps et argent à l'entreprise à qui tu rends des comptes et de passer pour un gros amateur auprès du gars qui reprend tes modules pour intégration ou amélioration.

Moi en tout cas ça m'aurait éviter quelques années de prise de tête et de "je reprends tout de zéro" si on m'avait expliqué ca au début.

Donc je tempère les propos de theMonz31, à mon sens il vaut mieux lever la tête, chercher les bonnes pratiques et tenter de les mettre en place, plutôt que de partir bille en tête avec des ornières pour faire en plus mal quelque chose que tout le monde à déjà fait, et qui ne pourra pas se faire évoluer facilement ni être réutilisé ailleurs de part les fortes dépendances et la maladresse du code qu'on y a introduit.

Qui plus est, au niveau des sociétés de plus en plus l'accent est mis sur l'architecture logicielle et l'intégration que sur la programmation pure (qui a tendance à se retrouver de plus en plus "déléguée")

En ce sens, je pense que NejNej se pose les bonnes interrogation et à les bons réflexe.