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
Je dirai qu'il vaudrait mieux 80 répertoires contenant chacun 50 fichiers de 500 lignesEnvoyé par souviron34
Vaut-il mieux 80 fichiers de 25 000 lignes chacun portant des noms aisément compréhensibles et une structure claire ou 4000 fichiers de 500 lignes chacun ??
C'est un objectif à atteindre, ne serait-ce que pour l'efficacité de la fonction recherche/remplace et d'autres outils.
+1 au premier jet.
Vaut-il mieux 80 fichiers de 25 000 lignes chacun portant des noms aisément compréhensibles et une structure claire ou 4000 fichiers de 500 lignes chacun ??
La clarté et facilité de maintenance n'est pas forcément là où on pense...
Mais en fait, ma réponse est : "ça dépend". Ca dépend de la pertinence fonctionelle et/ou technique des 4000 sous-bidules. Faut voir aussi qu'il est très compliqué de bosser à 2 sur un seul fichier(ça dépend des systèmes). Quand on bosse en équipe, ça peut être déterminant.
Pour moi, l'erreur et de dire "la longueur dépasse la norme, on coupe!". La bonne démarche, c'est de dire "oulàlà c'est un gros truc, est-ce qu'il n'y aurait pas un moyen de couper tout ça de manière logique et cohérente?". Il est arrivé que la réponse soit "non" pour un monstre de 35000 lignes(parceque tout y était rigoureusement interdépendant), mais la question a été posée, et c'est une bonne chose.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
J'avais un projet en langage C qui avait des sources de plusieurs milliers de lignes. Ca devenait impossible à maintenir pour une seule personne. Je me suis fait exactement cette réflexion et je l'ai réécrit totalement en C++, divisant à l'occasion la taille du source par deux avec les mêmes fonctionnalités.
il est courant dans l'industrie d'avoir des codes de plusieurs centaines de milliers, voire plusieurs millions de lignes..
A 500 lignes par fichier, la complexité introduite est très largement supérieure à un découpage propre de modules de 20000 lignes...
Je te donne un exemple : un code (opérationnel, critique) que j'ai fabriqué, avec interface temps réel, BD répartie, production de films, messages d'alertes, etc etc.. (affichage TR de données météo pour une météo nationale)
Taille : 700 000 lignes
Nombre de répertoires : 7
Nombre de modules par répertoire : environ 25
Taille de chaque module : environ 25 000 lignes.
Nombre de fonctions : 14 000.
Outil interactif ou en mode "script"
Tout les menus et les structures de données sont dynamiques et fonction de ce que rend éventuellement un serveur ou des fichiers de config.
Le découpage est logique et basé sur la fonctionalité : un seul module DrawData, un seul module LoadData, un module par panneau de l'IHM, un module pour gérer les symboles utilisateurs, un pour lire les fichiers cartographiques, un pour le calcul des projections, un pour le maillage 2D, etc etc..
Très facile de savoir dans quel module aller.
Dans chaque entête de module, une liste des fonctions, classées par usage : externes pures, internes et externes, internes pures, sous-regroupées par sous-fonctionalités.
Autre exemple industriel : un logiciel d'apprentissage pour contrôleurs ariens
Taille : 7 millions de lignes
Nombre de répertoires : environ 60
Nombre de modules par répertoire : environ 10
Nombre de fonctions : environ 20 000
Taille de chaque module : environ 10 000 lignes
etc etc..
Déjà qu'il est très complexe de s'y retrouver alors que c'est bien découpé (souvent au minimum un mois ou 2), si tu multiplies le nombre de fichiers par 200, je te dis pas
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Je ne suis pas d'accord avec cette affirmation. Pour information voici quelques projets célèbres dont la métrique a été calculée, on retrouve approximativement une moyenne de 400 à 500 lignes (de code) par fichier, ce qui est tout à fait raisonnable, étant donné la difficulté intellectuelle que représente la compréhension d'un fichier de 20000 lignes, sans parler des cauchemars que cela représente en termes de gestion de projet.
http://msquaredtechnologies.com/m2rs...ct_metrics.htm
Hmm à voir comme ça le nombre de lignes par fonction augmentent dangereusement avec le nombre de lignes du projet. Ca serait intéressant que tu regardes sur d'autres projets si il y a une vraie corrélation.il est courant dans l'industrie d'avoir des codes de plusieurs centaines de milliers, voire plusieurs millions de lignes..
A 500 lignes par fichier, la complexité introduite est très largement supérieure à un découpage propre de modules de 20000 lignes...
Je te donne un exemple : un code (opérationnel, critique) que j'ai fabriqué, avec interface temps réel, BD répartie, production de films, messages d'alertes, etc etc.. (affichage TR de données météo pour une météo nationale)
Taille : 700 000 lignes
Nombre de répertoires : 7
Nombre de modules par répertoire : environ 25
Taille de chaque module : environ 25 000 lignes.
Nombre de fonctions : 14 000.
Outil interactif ou en mode "script"
Tout les menus et les structures de données sont dynamiques et fonction de ce que rend éventuellement un serveur ou des fichiers de config.
Le découpage est logique et basé sur la fonctionalité : un seul module DrawData, un seul module LoadData, un module par panneau de l'IHM, un module pour gérer les symboles utilisateurs, un pour lire les fichiers cartographiques, un pour le calcul des projections, un pour le maillage 2D, etc etc..
Très facile de savoir dans quel module aller.
Dans chaque entête de module, une liste des fonctions, classées par usage : externes pures, internes et externes, internes pures, sous-regroupées par sous-fonctionalités.
Autre exemple industriel : un logiciel d'apprentissage pour contrôleurs ariens
Taille : 7 millions de lignes
Nombre de répertoires : environ 60
Nombre de modules par répertoire : environ 10
Nombre de fonctions : environ 20 000
Taille de chaque module : environ 10 000 lignes
etc etc..
Déjà qu'il est très complexe de s'y retrouver alors que c'est bien découpé (souvent au minimum un mois ou 2), si tu multiplies le nombre de fichiers par 200, je te dis pas
Ceci ne contredit pas le fait qu'un découpage correct (au sens de l'architecture logicielle) est plus efficace qu'un découpage forcé (guidé par la taille maximale du fichier). Il indique simplement, qu'en moyenne, les modules/classes sont de tailles raisonnables, ce qui reste bien sur, un objectif en général, mais qui doit rester souple pour le cas d'objets complexes (pour qui un découpage serait un élément supplémentaire de complexité).
Plus j'apprends, et plus je mesure mon ignorance (philou67430)
Toute technologie suffisamment avancée est indiscernable d'un script Perl (Llama book)
Partagez vos problèmes pour que l'on partage ensemble nos solutions : je ne réponds pas aux questions techniques par message privé
Si c'est utile, say
Dans le cadre du 2ème projet la moyenne est à 350 lignes par fonction, selon les critères actuels ce n'est pas raisonnable.
Je parlais de taille de module/classe, pas de taille de fonction/méthode.
Plus j'apprends, et plus je mesure mon ignorance (philou67430)
Toute technologie suffisamment avancée est indiscernable d'un script Perl (Llama book)
Partagez vos problèmes pour que l'on partage ensemble nos solutions : je ne réponds pas aux questions techniques par message privé
Si c'est utile, say
Je suis d'accord sur la flexibilité des tailles modules/classes qui sont forcément liées au fonctionnel et à la logique de l'ensemble.
C'est ce que je veux dire. 25000 lignes, c'est possible si c'est cohérent, mais ça doit rester l'exception. Le nanar de 35000 lignes dont je parle au dessus avait un rôle centralisateur au milieu du batch. 150 chaines en amont(qui toutes produisent le même format commun et standardisé d'enregistrement), 90 chaines en aval(chacune exigeant son propre format), 72 modules accesseurs appelés(avec chacun sa signature), et le tout indécoupable. Mais le reste de l'appli, c'était 2-3 modules à 5000 lignes, et une myriade inférieure à 2000 lignes. Parceque ç'était cohérent comme ça.
Les gens du "métrique" faisaient un caca nerveux tous les 6 mois au sujet de la bête(qui nécéssitait une ressource à plein temps pour sa maintenance, dont j'étais le back-up à plein temps quand il n'était pas là), alors on a chercher tous les moyens de la découper. En vain. Car il était nécéssaire de garantir un traitement standardisé de tous les flux entrants.
Mais oui, tout ce qu'on peut découper proprement, il faut le faire, au vu des couts engendrés par le seul monstre sur lequel on a pas pu le faire(250 jours de maintenance annuelle).....Juste, exiger une découpe, ça ne fonctionne pas, de même que toute règle trop rigide.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Eh bien encore une fois :
- Primo le "cauchemar" l'est beaucoup moins pour gérer 400 fichiers que 4000 ou 12000.
- Secondo, la difficulté intellectuelle pour comprendre un fichier de 20 000 lignes bien construit est bien moindre que celle nécessitée par la compréhension de 6000 fichiers mal construits....
N'importe quelle personne ayant travaillé sur des gros softs te le dira...
Oui il y en a une : c'est même publié (je crois que j'avais inclus le schéma dans un des débats sur ce forum), je crois dans Scientific American : la courbe est exponentielle en volume, en points de fonctions, en durée, et en budget (et en taux d'annulation).
Cependant, tous les très gros projets sont très complexes .
Et les "normes" , comme par exemple à la NASA avec 50 lignes max par fonction, et une fonction par fichier, ne rendent pas la maintenance plus facile : 3000 ingénieurs à temps plein, un budget plus gros que celui de la France, environ 800 000 fichiers à gérer, c'est pas forcément mieux.... et à la portée de toutes les bourses...
Encore une fois le "critère" (je me répète par raport à l'autre débat) est que cela soit compréhensible.
Ces critères "absolus" sont une absurdité en soi.
D'autant plus si les fonctions sont dans des fichiers différents. Jongler entre des dizaines de fichiers pour établir l'organigramme d'une fonctionalité est bien plus casse-tête (pour ne pas dire emm.rdant) que suivre un fil sur 300 lignes consécutives..
Je prend date, et vous donne rdv dans 20 ans, quand vous aurez eu (peut-être) à reprendre de vrais gros codes construits aujourdhui avec ces règles...
En conclusion : toute norme absolue est stupide dans notre domaine...
Comme pour tout, le bon sens est la règle qui devrait prédominer...
- Sur un petit projet, pas de problèmes.
- Sur un gros, tout dépend de l'architecture fonctionnelle, des objets manipulés, de la durée de vie, du langage utilisé (une des raisons pour lesquelles j'ai une très mauvaise expérience du C++ en très gros projet industriel (celui des contrôles aériens cité ci-dessus) : les "factories" sont une étape de complexité supplémentaire, qui n'ont aucun lien avec la fonctionalité, et rendent la compréhension d'un code source encore plus difficile), du futur qu'on attend de cette application..
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
J'ai déjà eu à travailler sur un gros code (plus d'un million de ligne pour la partie C++ qui ne représentaient pas du tout la totalité de l'appli).
Autant sur la taille des modules je suis d'accord, autant sur la taille des fonctions/méthodes je ne le suis pas. 99,99% des traitements sont "atomisables" ce qui simplifie la maintenance. Mais bon, probablement que tous ceux qui tiennent le même type de raisonnement depuis maintenant plus de 10 ans ont torts ? Même s'il y a une fonction critique que tu ne peux pas diviser (je demande à voir) ce n'est pas ça qui fait exploser la moyenne LoC par méthodes. Les critères absolus sont peut être idiots mais une moyenne sur 7millions de LoC ça commence à donner des infos...
Dans les méthodologies de développement pour logiciels critiques (DO178 pour l'avionique par exemple), il existe des règles de codage, de conception, ...
Il est toujours possible de violer ces règles, dans la mesure où :
- on justifie cette violation
- on trace l'ensemble des conformités/non conformités
Plus j'apprends, et plus je mesure mon ignorance (philou67430)
Toute technologie suffisamment avancée est indiscernable d'un script Perl (Llama book)
Partagez vos problèmes pour que l'on partage ensemble nos solutions : je ne réponds pas aux questions techniques par message privé
Si c'est utile, say
C'est là où on ne se comprend pas. Je parle des gros projets avec 200 ou plus intervenants dessus. Même avec des systèmes modernes de version 80 fichiers de 20 000 lignes n'est pas tenable.
Dès qu'un développeur s'approprie un fichier pour travailler dessus, il devra soit le verrouiller et donc avoir 199 développeurs travailler sur autre chose (mais il ne reste que 79 fichiers), soit prendre une copie du fichier et faire un merge des différences. Et un diff sur 20 000 lignes avec un nombre inconnu de développeurs ayant travaillé dessus c'est invivable car des télescopages sont inévitables.
Avec les outils modernes, une structure en répertoires n'offre que des avantages, les EDI de nos jours font des recherche/remplace sur l'ensemble du projet et non un seul fichier.
J'ai travaillé personnellement (et modestement) sur le GCC et c'était parfaitement bien organisé.
Et je n'ai absolument pas eu à ingérer l'ensemble du projet, je me suis uniquement occupé de repérer où se trouvait le fichier que je cherchais pour le modifier, lequel ne faisait qu'une dizaine de lignes.
L'utilisation de fichiers de 20 000 lignes se défend uniquement pour un petit groupe de programmeurs.
D'autre part la POO amène la logique : une classe pour un fichier, c'est un découpage naturel qui me convient parfaitement, 500 lignes étant pour moi un objectif à atteindre plus qu'une règle gravée dans le marbre.
Pour quelqu'un qui cite "les outils modernes", je crois que là tu ne sais pas de quoi tu parles....
que ce soit cvs, svn, ou Rational ou autres outils du même acabit, tous ces outils te permettent de travailler à 200 sur le même fichier si tu en as envie, avec des merges automatiques et détection de conflit (et résolution personelle ou après discussion) avant rentrée finale...
je ris.. Eternel argument des défendeurs inconditionnels de la POO...
Comme nous en avons maintes fois débattu, il n'y a rien de plus logique et naturel dans la POO que dans le procédural..
Pour citer Garulfo dans un autre débat : "la POO se concentre sur les objets, le procédural sur la fonctionalité" :
Je suis scientifique à la base, une architecture et un découpage fonctionnel me sont tout à fait naturels et logiques.
Tu es informaticien ayant eu des cours de POO : elle te semble naturelle et logique.
Les 2 sont équivalents, et il n'y a pas de "panacée", juste des préférences de pensée.. de formation, ou de mode..
Quant au nombre de classes, cela peut-être carrément insupportable si le découpage a été mal fait ou l'héritage mal conçu..
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
C'est autant populaire ou cela t'es une difficulté personnelle ? Parce qu'au final on pourrait avoir le même nombre de ligne de code donc chercher une punaise (ou une aiguille) dans 4000tonnes de foin c'est moins cauchemardesque que de la chercher dans 400 ?
Tu exagéres car dans ta comparaison chaque fichier n'aurait que 2-3 lignes de code, tu insultes l'intelligence des développeurs pas bien.[*]Secondo, la difficulté intellectuelle pour comprendre un fichier de 20 000 lignes bien construit est bien moindre que celle nécessitée par la compréhension de 6000 fichiers mal construits....
Ok. Attendons alors qu'ils répondent...Sinon des références de personne qui disent cela publiquement (dans un livre par exemple ou un blog)N'importe quelle personne ayant travaillé sur des gros softs te le dira...
Bizar pour quelqu'un orienté extréme documentation d'imaginer qu'on ne puisse documenter l'organisation logique par groupe de fonctionnalité les fichiers source d'un projet.D'autant plus si les fonctions sont dans des fichiers différents. Jongler entre des dizaines de fichiers pour établir l'organigramme d'une fonctionalité est bien plus casse-tête (pour ne pas dire emm.rdant) que suivre un fil sur 300 lignes consécutives..
+10000Comme pour tout, le bon sens est la règle qui devrait prédominer...
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Le nombre de collisions reste toutefois dépendant de l'architecture. Et si on peut travailler en solo sur un fichier c'est beaucoup mieux, comme ça pas de merge à effectuer.que ce soit cvs, svn, ou Rational ou autres outils du même acabit, tous ces outils te permettent de travailler à 200 sur le même fichier si tu en as envie, avec des merges automatiques et détection de conflit (et résolution personelle ou après discussion) avant rentrée finale...
C'est vrai, mais de l'autre côté quand tu as énormément de fichiers, juste passer à travers les noms (sur une quantité > 1000 ou 2000) est "mind buggling" : ta mémoire ne retenant que 7 (chiffre officiel académique) choses court terme, ça va être dur..
Si c'est une organisation par fonctionalité, tu t'y retrouve plus vite (pourvu que les fichiers soient bien nommés).
Je n'ai pas fait de divisions mathématiques. C'était un ordre de grandeur...
Mais puisque tu l'as fait, cela veut dire 300 fichiers quand même.. Contre un..
Et donc si ton soft fait 80 fois 1 fichier de 20 000 lignes, tu te retrouves avec.... 24 000 fichiers !!!!
Attendons effectivement...
Mais c'est de la pure pratique : sais-tu tous les fichiers pris en compte par l'OS Windows ? ou tous les fichiers de la JDK (60 000 au bas mot) ??
je ne parlais pas de moi mais d'exemples vécus de codes que j'ai vu ..
Comme je mentionnais à propos des classes.. Supposons un outil manipulant 85 classes différentes d'objets..
Suivant l'architecture des répertoires, si c'est orienté classes, tu peux avoir 85 répertoire, ou 85 modules, avec dans chacun une méthode Display par exemple.
Ce qui veut dire que si tu veux suivre ce qui se passe quand l'écran est raffraîchi, il te faut 85 fichiers ouverts, et passer de l'un à l'autre en fonction de l'objet affiché..
Sauf que dans justement les grosses équipes (que tu sembles citer par ailleurs), cela n'est quasiment jamais le cas...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
C'est vrai, mais de l'autre côté quand tu as énormément de fichiers, juste passer à travers les noms (sur une quantité > 1000 ou 2000) est "mind buggling" : ta mémoire ne retenant que 7 (chiffre officiel académique) choses court terme, ça va être dur..C'est quoi encore ce truc du chapeau qui sort de l'académie. On utilise des outils non qui intégre des interfaces et fonctions de recherche soit avec les mots qu'il faut on peut très bien avoir une gridtable avec 7 noms de fichiers.
Référence ? Source ? Stat ?Si c'est une organisation par fonctionalité, tu t'y retrouve plus vite (pourvu que les fichiers soient bien nommés).
20000 lignes de code dans un fichier ou plus ne me choque pas tout dépend jusqu'à quel point nous pouvons le relire x fois avec facilité et rapidité.Je n'ai pas fait de divisions mathématiques. C'était un ordre de grandeur...
Mais puisque tu l'as fait, cela veut dire 300 fichiers quand même.. Contre un..
Et donc si ton soft fait 80 fois 1 fichier de 20 000 lignes, tu te retrouves avec.... 24 000 fichiers !!!!
Oui et alors ?Mais c'est de la pure pratique : sais-tu tous les fichiers pris en compte par l'OS Windows ? ou tous les fichiers de la JDK (60 000 au bas mot) ??
Beh non tu lis la documentation technique qui raconte toutes ces histoires de classe et de méthode. Mince y'a jamais de doc tu vas me dire mais je ne pense pas que c'est la raison qui te pousse à cette pratiqueje ne parlais pas de moi mais d'exemples vécus de codes que j'ai vu ..
Comme je mentionnais à propos des classes.. Supposons un outil manipulant 85 classes différentes d'objets..
Suivant l'architecture des répertoires, si c'est orienté classes, tu peux avoir 85 répertoire, ou 85 modules, avec dans chacun une méthode Display par exemple.
Ce qui veut dire que si tu veux suivre ce qui se passe quand l'écran est raffraîchi, il te faut 85 fichiers ouverts, et passer de l'un à l'autre en fonction de l'objet affiché..
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager