Discussion :

[agparchitecture]

Bonsoir à tous,

Je programme un petit peu pour le moment durant mes temps libres, et malheureusement je mélange toutes les fonctions et j'ai "du mal" avec l'ensemble des functions et class (plusieurs lignes de codes et plusieurs fonctions dans une même class.

Comment fais vous pour vous y retrouver et ne pas mélanger l'ensembles des fonctions que vous avez développées?

Merci pour votre expérience et partage.

[DonQuiche]

Bonjour.


Difficile de saisir quel est exactement ton problème, tu devrais nous montrer un peu de code pour que nous puissions te conseiller. Inutile d'être timide : nous avons tous fait des choses horribles au début.


Cela dit tu peux te renseigner sur certains principes de conception :

* Principe de responsabilité unique (SRP) : une classe ne devrait avoir qu'une seule raison de changer. Par exemple dans un jeu la classe "inventaire" ne devrait changer que si l'on veut changer le mode de fonctionnement de l'inventaire. Un changement d'interface ou l'ajout d'une nouvelle arme ne devraient pas nécessiter de changer l'inventaire.

Ce principe est également lié à d'autres : dans la mesure du possible une classe ne devrait pas se mêler des détails des autres classes. L'essentiel de ton code devrait ne pas avoir de références au reste de ton code.

* Fais les choses simplement (KISS) : si ça a l'air compliqué ou tortueux, arrête-toi de coder, lève-toi de ta chaise, prends du recul et remets en question ce que tu fais.

* Tu n'en auras pas besoin (YAGNI) : nous avons souvent tendance à ajouter des fonctionnalités qui ne seront finalement pas utilisées. Il est bon d'anticiper mais ne fais pas de plans sur la comète, n'ajoute une fonctionnalité que si tu es sûr d'en avoir besoin. En général tu devrais passer plus de temps à réfléchir à ce que tu vas faire et si c'est judicieux, plutôt qu'à le faire.

* Ne te répète pas (DRY) : si deux classes font la même chose, il est souvent bon de regrouper le comportement commun dans un même morceau de code. Attention à ne pas faire de grosse plomberie lourdingue toutefois, parfois mieux vaut se contenter d'une redondance.

* Privilégie les concepts du domaine (du "métier"). Autrement dit il est préférable dans un jeu d'avoir des classes "Joueur" et "Monde" plutôt qu'un "GestionnaireDeJoueurs" ou un "Contrôleur" chargé de tout piloter.

* N'optimise pas. Sérieusement, n'optimise pas. Cela conduit presque toujours à écrire un code sale et compliqué pour faire quelque chose de simple qui ne posait aucun problème de performances. Nous sommes en 2015 et nos processeurs exécutent des milliards d'instructions par seconde. Écris un code propre et c'est tout. Le jour où tu auras vraiment un problème de performances, là il sera tant d'optimiser - non pas avec des petits bidouilles mais en changeant d'algorithme ou de structure de données.


Et je peux aussi te recommander la lecture des livres de Robert Martin, à commencer par "Coder proprement". Écrire un code propre est effectivement une chose difficile.

[agparchitecture]

Bon voici le code complet (sous sharpdevelopp) de l'application qui est un petit gestionnaire de favoris. Celle-ci fait pour le moment ce qui lui est demandé.

WebMarkDev.zip

Le problème arrive à plusieurs niveaux

• J'ai du mal à mémoriser l'ensemble des noms de mes fonctions car elle commence a devenir nombreuses
• J'ai du mal lorsque le fichier d'une class commence à dépasser les +/- 200 lignes
• j'ai également du mal pour ce qui concerne la création de procédure. Je m'explique: je code un premier lieu la commande d'ouverture de fichier. jusque la pas de problème. Lorsque je veux implémenter un import de fichier, je me dit que c'est un peu le même principe que l'ouverture avec juste quelque changement. Donc j'adapte l'ouverture pour faire de l'ouverture et de l'import. Même fonction avec juste un ou deux paramètres. le cerveau a du mal à faire abstraction de l'ancienne fonction.
• J'ai décomposé en plusieurs fichiers ce qui me pose problème lorsque je dois me souvenir du quel fait quoi puisque je ne programme pas en permanence

Je suppose que c'est un manque d'habitude et des problème du à un apprentissage autodidacte;

Par contre je suis preneur pour toutes critiques permettant d'évoluer et d'approfondir mes connaissances.

Merci pour l'aide

[jopopmk]

Salut,

pour les régions j'ai rencontré deux philosophies dans le monde pro :
- le regroupement par fonctionnalité : on met dans une même région les attributs, accesseurs, méthodes et events qui ont un objectif commun,
- le regroupement par type : on met dans une même région selon le type (attribut, accesseurs, méthodes, event).

Dans ce deuxième regroupement (au saumon, mon préféré) on est indépendant des fonctionnalités ce qui fait :
- qu'on se demande plus où on a casé ce satané attribut/event qui sert dans n fonctionnalités,
- que le regroupement est identique pour toutes les classes, on sait à chaque fois comment atteindre rapidement ce qu'on cherche selon son type.
Et rien n'empêche de faire des sous-régions plus orientées fonctionnalité.

Je dis pas que c'est la bonne solution, simplement que je me suis jamais perdu en faisant comme ça (notamment sur un projet contenant pas loin de 200 fichiers sources).

[..][*]J'ai du mal lorsque le fichier d'une class commence à dépasser les +/- 200 lignes[..]

Mets toi pas au C alors (y'a quand même quelques outils/astuces de regroupement pour pas trop se perdre).

[DonQuiche]

Je viens de jeter un coup d’œil et cela me rappelle un peu le code que j'écrivais il y a dix ou quinze ans. Je diagnostique un cas de bureaucratite galopante. Tu cherches à trop bien faire.


* Tu cherches trop de granularité et de classification. Tes répertories sont trop petits, tes espaces de noms contiennent trop peu de choses, certaines classes sont trop petites, etc. Du coup tu te retrouves avec trop d'éléments parmi lesquels naviguer et l'intellisense ne peut pas t'aider du fait des espaces de noms éclatés. Cherche des ordres de grandeur idéaux : 10 à 20 éléments par dossier, 100 à 200 lignes par fichier. N'hésite pas à numéroter tes fichiers (01 abc.cs, 02 def.cs) s'il y a une séquence à mettre en évidence.

Toujours dans la même veine, si une classe n'est utilisée qu'à un endroit, ajoute-la en-dessous de la classe concernée, ne crée pas un fichier expressément pour ça. Sauf si elle est trop grosse.


* Préfère le domaine au code. Groupe ensemble ce qui relève de la même fonction du domaine plutôt que de catégoriser par type de classe (contrôle utilisateur, formulaire, outil, etc) car cela éclate les morceaux cohérents du code sur plusieurs endroits. Par ailleurs le domaine, lui, parle tout de suite au lecteur. Enfin cela facilite l'exploration du code et devrait résoudre ton problème de mémorisation.


* Tes noms ne sont pas descriptifs et pollués par des préfixes inutiles et des acronymes. Plutôt que UcMarkV préfère VerticalMarkEditor. Évite les abréviations et choisis des noms que tu comprendras tout de suite à leur relecture dans un an. Choisis des noms adaptés à une recherche naïve par Intellisense. Un bon code se lit comme de l'anglais (dans la mesure du raisonnable !).


* Tu as trop de bruit, ce qui rend tes fichiers deux fois trop longs, ce qui nuit à la lisibilité du code. Cherche quelque chose de plus compact où le lecteur peut voir d'un coup d'oeil de nombreux membres.

Tu as notamment trop de commentaires, presque tous inutiles. Oublie en particulier les commentaires XML : 99% du temps ils sont redondants avec les noms de la méthode et des variables. S'ils ne le sont pas c'est que ta méthode ou ces variables sont mal nommées.

Les commentaires dont tu devrais avoir l'usage sont presque exclusivement ceux qui explicitent le contexte : par exemple des commentaires en haut du fichier expliquant pourquoi tu as fait les choses ainsi : quel est le problème résolu ?

Les régions sont également un facteur de bruit pour moi. Soit ta classe est trop longue et il faut la diviser, soit elle est trop courte pour avoir besoin de régions. Dans tous les régions sont pour moi un facteur d'obscurcissement du code car elles me forcent à dérouler. Elles ne se justifient que rarement.

Tu peux avantageusement virer des blocs if avec accolades. Par exemple en utilisant des clauses de garde (if !condition return au lieu des if condition body). Et virer des etours de ligne ici ou là.



Par rapport à ce qui a été dit je ne pense pas que UML puisse t'aider : ton problème n'est pas lié à l'architecture. A la rigueur il est possible (je n'ai pas fait suffisamment attention) que certaines des méthodes statiques dans Tools gagnent à être refactorisées en un ensemble d'instances mais ce n'est pas dit. Difficile de dire sans examen approfondi si c'est un reste de prog procédurale ou si c'est simplement une façon adaptée au problème. A priori je miserais sur le second.

Enfin je sais que tout ça va à l'encontre de tes habitudes et de certaines soi-disant bonnes pratiques d'ailleurs utilisées dans certaines entreprises (pour certaines parce qu'elles ont mille employés de niveaux très divers à faire collaborer, pour d'autres pour de mauvaises raisons). Je sais que tu vas être sceptique, y rechigner, y voir une affaire de préférence personnelle, etc. Mais essaie et tu me remercieras. Et lis les bouquins de Robert Martin.


PS: VS place au-dessus du code des barres très commodes pour naviguer vers telle ou telle méthode de ton fichier. Note aussi Ctrl + K qui permet de facilement trouver un type ou un membre depuis son nom, dans toute ta solution.

[agparchitecture]

@DonQuiche

Merci pour les conseils: mais j'aimerais des précision sur certain point:

Tu cherches trop de granularité et de classification

:
Qu'est-ce que tu entend par granularité?

Préfère le domaine au code

qu'est-ce que le domaine ?

possible que certaines des méthodes statiques dans Tools gagnent à être refactorisées en un ensemble d'instances
c'est un reste de prog procédurale

Qu'elle est l'autre type de prog? et qu'entends tu exactement par procédural?

Enfin je sais que tout ça va à l'encontre de tes habitudes
Je sais que tu vas être sceptique, y rechigner, y voir une affaire de préférence personnelle

Pas vraiment sceptique ni à y rechigner mais bien a écouter l'expérience qui est ce qui est le mieux pour la pratique et résoudre mon problème. (je peux bien me passer de commentaire xml et faire des return directement après un if.

Merci bien.

[DonQuiche]

Qu'est-ce que tu entend par granularité?

En l’occurrence que tu utilises de trop petits grains : répertoires et espaces de noms avec trop peu d'éléments, etc. Tu te retrouves à chercher dans une mer de sable au lieu d'une étagère contenant une collection de beaux cailloux.

qu'est-ce que le domaine ?

Le domaine c'est le sujet de ton application. Ce sont les concepts que manipule l'utilisateur final, par opposition à ce qui relève du code lui-même. On parle également d'objets "métier".

Dans un jeu les objets du domaine sont les personnages, la barre de vie, les lieux, etc. Alors qu'au niveau du code cela va être des factories, octrees, singletons, worldProxy, inventoryManager, playerController, coloredBar, etc. Il est bon de rester proche du domaine, d'utiliser les noms du domaine et de ne pas s'enfoncer trop loin dans l'abstraction. Même si bien sûr c'est nécessaire et utile jusqu'à un certain point.

Ne pas rechercher le technique ou mathématique. Simple et idiot (KISS), en bon anglais, aussi compréhensible que possible par un béhotien. Le meilleur code est celui qui semble le plus évident, simple et naturel. Ce qui est très compliqué à faire.

Qu'elle est l'autre type de prog? et qu'entends tu exactement par procédural?

C'est l'ancêtre des styles de programmation, datant d'avant la programmation objet. Comme on n'avait pas d'objets on manipulait directement des fonctions sans instances en passant tous les arguments en paramètre. C'est équivalent à ce que tu as fait dans tools avec ces batteries de méthodes statiques.

Parfois ce code est adapté au besoin et je crois que c'est ton cas ici. Parfois on le rencontre chez des personnes qui ont été exposées à ces vieux langages et ont gardé des réflexes malvenus.

De nos jours on le rencontre rarement. La frontière actuelle est entre programmation objets et programmation fonctionnelle.

Merci bien.

Je t'en prie.



PS : j'ai vu que tu gardes des listes de tâches à faire dans ton code. VS est capable de lister automatiquement les commentaires commençant par "TODO:" et "BUG:". Et quelques autres. C'est personnalisable. Le résultat est affiché dans le panneau des tâches, en bas. Assez commode.

PPS : J'ai mentionné Ctrl + K tout à l'heure (ctrl + virgule en standard en fait, désolé). Il faut prendre conscience que passé une certaine taille toute ontologie fonctionne moins bien, ce qui est le cas de la hiérarchie des fichiers. Il faut utiliser l'IDE comme on utilise un moteur de recherche, via Intellisense et Ctrl + virgule, et via la navigation (clic droit sur un nom et go to definition). Et garde la hiérarchie de fichiers simple, peu profonde et intuitive.

[ranzoken]

Bonjour,

en continuant sur les éléments évoqués par "DonQuiche"

je rajouterai un principe et une méthode d'écriture :

le développement en couche

et utiliser les régions

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
#region TEXT_A_ECRIRE
// place ton code dedans
#endregion

Edit : UTILISER Visual Studio pour coder, la version 2015 Community est très bien fournis et gratuite, il n'y a aucune raison de ne pas l'utiliser

[ranzoken]

je reprend mon précédant poste, vus qu'entre deux les sources ont été postés.

- les région sont présente, c'est bien mais pas assez à mon goût
par exemple tu fait une région pour ton singleton, et après tu n'en met plus, continue d'en mettre.

-les noms sont bien mis il reste assez court même si on peut faire un peut mieux ^^

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
MarkNet.services.ServiceMark.ServiceMark.MakeSeve()
en changeant un petit peu ça peu devenir :
MarkNet.services.MgtMark.getInstance.Seve()

c'est pas nécessaire de changer mais c'est bien d'y penser pour une prochaine



Après avoir parcouru rapidement tes fichiers, je dirais qu'il te manque des diagrammes UML
ton code reste rangé, certes on peut toujours chipoter mais dans l'ensemble on s'y retrouve
tes classe ne sont pas grosse du tout, donc pour moi, il faut que tu pose tes idées sur un papier


Cordialement

[agparchitecture]

et utiliser les régions

...

Edit : UTILISER Visual Studio pour coder, la version 2015 Community est très bien fournis et gratuite, il n'y a aucune raison de ne pas l'utiliser

Ok pour les régions j'ai commencé à les utiliser (quelques unes sont présente ans le code fourni)

J'ai également utilisé des class partielle pour décomposer certaine class en partie en fonction du role des méthodes et fonctions

pourquoi vaut-il mieux utiliser Visual studio que Sharpdevelop? J'aime bien sharpdevelop car il y a une version portable que je peux prendre uand je vais chez mes parents sans pour autant devoir installer visual studio sur leur pc.

Sinon des avis sur le code (toutes remarques sont les bien venues)?

[ranzoken]

je continue de fouillez mais dans son ensemble c'est pas un code "fourtout"

dans t'as class "FilesReader" (et même ailleurs)
tu peux utiliser le mot clé using
exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
internal static List<string> GetFileLines(string fileName)
		{
			List<string> ret = new List<string>();
			StreamReader sr = null;
 
			try
			{
				sr = new StreamReader(fileName);
				while (sr.Peek() >= 0)
				{
					ret.Add(sr.ReadLine());
				}
			return ret;				
			}
			catch(Exception) { return null; }
			finally { if (sr != null) { sr.Close(); sr = null; } }
		}

deviens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
internal static List<string> GetFileLines(string fileName)
		{
			List<string> ret = new List<string>();
			try
			{
				using(StreamReader  sr = new StreamReader(fileName))
                                {
				    while (sr.Peek() >= 0)
				    {
					ret.Add(sr.ReadLine());
				    }
                                }			
			}
			catch(Exception) { return null; }
                        return ret;	
		}

le mot clé using n'est pas la pour réduire ton code, mais pour détruire ton objet en cas de problème, et cela évite toute étourderie
aussi la gestion des erreur est très mauvaise ici, si ça plante on renvoi null, mais est-ce parce que le fichier a été supprimer, n'existe pas, coupure réseaux ???
et désoler si l'indentation est pas terrible, j'ai écrit à la main

[agparchitecture]

je continue de fouillez mais dans son ensemble c'est pas un code "fourtout"

Donc si je comprend bien, le principe de codage et de division est bon?

aussi la gestion des erreur est très mauvaise ici, si ça plante on renvoi null, mais est-ce parce que le fichier a été supprimer, n'existe pas, coupure réseaux ???

Je sais mais c'est justement dans mon problème. Comme j'ai déjà pas mal de choses de faites, si j'intègre en plus (actuellement) la gestion des erreurs je ne m'en sors "plus du tout" . Je comptais les ajouter par après.

Le problème viens que du certaine façon l’ensemble des éléments est tellement nombreux que je m'y perds... (je fais de tels ou tels manière? Ah oui je viens de rajouter la gestion d'erreur, ou faut-il que je la traite. Ok je la traite à ce niveau tien non plutot la ...) que des changement qui "m'embrouille"...

En tout cas le code fais ce que je lui demande et sa me rassure