Discussion :

[souviron34]

Concernant la maintenabilité, je ne comprend très bien quand tu dis qu'on peut bien concevoir une application et la rendre difficile à maintenir. Une bonne conception conduit à un code lisible, compréhensible et maintenable.

En gros, on t'a donné les réponses au dessus, mais celle-ci est un des cas les plus fréquents (découpage taylorien des équipes oblige) :

Il suffit que le travail soit découpé et réparti à des développeurs différents des concepteurs pour se rendre que ce n'est pas le cas du tout.

Ce qui est le cas de la très large majortié des logiciels...

(ce qui est la raison, outre la perte de temps à faire des montagnes de documents et à perdre de l'information à chaque étage, pour laquelle je suis totalement contre les grosses équipes)


Ensuite, un dernier point : même un gars tout seul, si il aime "l'obfuscation", le code peut être bien découpé et illsibile...

J'ai eu un stagiaire qui m'a fait un lissage d'une image par une gaussienne en 2 lignes... Sans doute brillant, mais illisible et in-maintenable... par les techniciens du SAV..

[el_slapper]

(.../...)(ce qui est la raison, outre la perte de temps à faire des montagnes de documents et à perdre de l'information à chaque étage, pour laquelle je suis totalement contre les grosses équipes)

tu n'est pas le seul :

The trouble is that that assumption assumes productivity scales linearly with team size, which again observation indicates isn't the case. Software development depends very much on communication between team members. The biggest issue on software teams is making sure everyone understands what everyone else is doing. As a result productivity scales a good bit less than linearly with team size. As usual we have no clear measure, but I'm inclined to guess at it being closer to the square root.

Pour faire 10 fois plus de boulot, il faut 100 fois plus de personnes. De qualité égale. Or si il n'est pa si difficille de trouver un bon, trouver cent bons, c'est une autre paire de manches.....

Ensuite, un dernier point : même un gars tout seul, si il aime "l'obfuscation", le code peut être bien découpé et illsibile...

Ce qui est marrant, c'est que nos parcours n'ont rien à voir, et que pourtant bien des éléments de nos expériences semblent identiques...

J'ai eu un stagiaire qui m'a fait un lissage d'une image par une gaussienne en 2 lignes... Sans doute brillant, mais illisible et in-maintenable... par les techniciens du SAV..

Un stagiaire qui créée un écran complet de statistiques(15 lignes, 7 colonnes, avec des cumuls partout, des pourcentages, etc...) en une seule requête SQL, c'était joli aussi. Mais le tien me parait encore plus gratiné.

[chaplin]

S'il y a un traitement pour lequel il existe déjà une fonction dans une bibliothèque, je l'utilise, histoire de ne pas réinventer la roue.

Rien qu'en "implémetant" une fonction, sans s'en rendre compte on utilise un ensemble de fonctions provenant de bibliothèques, ce qui implique une certaine expérience dans l'utilisation d'un langage.

Un exemple, Windev, dans la manipulation des enregistrements, les fonctions s'inscrivent dans un concept qu'ils nous faut d'abord comprendre avant d'être sûr de les utiliser.

En conclusion, l'existence de bibliothèques, voir de framework pour des langages objets, nous conditionnent dans la façon d'écrire un code. A partir de là, il y a ceux qui sont influencés et ceux qui décident d'implémenter pour reprendre la formule qui va bien.

Perso, je préfère découper pour tester les fonctions individuellement dans l'objectif d'avoir un code robuste, ce qui n'empêche que j'y mette des bugs, mais ces bugs sont facilement corrigible et souvent ils sont idiots, mais le code est facile à maintenir parce que l'implémentation se veut logique.

[jeandido]

Enseignant chercheur est ton titre. Désolé, mais par rapport à des vieux briscards qui se sont tapés des codes de tout poil, tu n'est pas très bien plaçé pour comprendre la réalité du terrain.

Oui, en effet, je suis enseignant-chercheur à la fac. Cela ne m'empêche pourtant pas d'être "un professionnel" ; ce n'est pas incompatible. Sur mon CV, il y a aussi "Oracle Certified Master Java SE Developer", "Symfony Certified Developer" et "Cisco Certified Network Associate" au cas où tu serais intéressé de savoir.
Qu'à cela ne tienne, revenons-en au débat.

C'est ça, la réalité de la vie d'une appli. "Je conçois, j'implémente en suivant pas à pas la conception", c'est une vision de l'esprit. ça n'existe pas.

Tu devrais élargir tes horizons. Je te conseille de lire "P. Roques, Les cahiers du programmeur UML 2 : Modéliser une application web", "X. Blanc et I. Mounier, UML 2 pour les développeurs", "T. C. Lethbridge and R. Laganière, Object Oriented Software Engineering : Practical software development using UML and Java", "La traduction de B. Eckel, Think in C++ faite par développez.com, Penser en C++, p.39-40 particulièrement, paragraphe 1.9.3". La liste est longue ... Ce dernier est toujours disponible à http://bruce-eckel.developpez.com/li...on/ticpp2vol1/. Intéresse-toi aussi au "Model-Driven Architecture approach".

[jeandido]

Il suffit que le travail soit découpé et réparti à des développeurs différents des concepteurs pour se rendre que ce n'est pas le cas du tout.

Visiblement, tu accuse des lacune en conduite de projets : la coordination des équipes, la communication, le développement collaboratif, à quoi ça sert ? C'est fréquent, quand on apprend à programmer sur le tas et qu'on ne s'efforce pas d'encadrer ses projets de développement par le génie logiciel.
As-tu beaucoup d'expérience de vrais projets en équipe ?

[gangsoleil]

Tu devrais élargir tes horizons. Je te conseille de lire[...]

Certains de ces livres sont surement tres interessants, mais il faut aussi voir la realite des entreprises :
Certaines travaillent avec UML, vraiment, notamment avec UML2, et implementent les logiciels en fonction de ce qui est specifie.

Neanmoins, j'ai pu voir des SSII (donc avec pas mal de clients), des grosses entreprises, des PME, et des startups, et je n'ai eu qu'une seule experience d'UML : un diagramme de classe "dessine" a la main sur une feuille de papier, puis scanne.

Quid des autres diagrammes ? Jamais croise dans la vraie vie. Et pourtant, ils sont au moins aussi important, voir plus, que le diagramme de classe [non, ce n'est pas un troll].


Ce n'est pas le premier "outil" interessant qui n'est pas utilise. Je pense d'ailleurs que la plupart des outils qui sont orientes vers la conception sont tres peu utilises car, comme l'ont deja dit el_slapper et Souviron34, l'implementation a souvent lieu en meme temps que, ou avant, la conception.

[jeandido]

Certains de ces livres sont surement tres interessants, mais il faut aussi voir la realite des entreprises :
Certaines travaillent avec UML, vraiment, notamment avec UML2, et implementent les logiciels en fonction de ce qui est specifie.

Neanmoins, j'ai pu voir des SSII (donc avec pas mal de clients), des grosses entreprises, des PME, et des startups, et je n'ai eu qu'une seule experience d'UML : un diagramme de classe "dessine" a la main sur une feuille de papier, puis scanne.

Quid des autres diagrammes ? Jamais croise dans la vraie vie. Et pourtant, ils sont au moins aussi important, voir plus, que le diagramme de classe [non, ce n'est pas un troll].

D'accord que ça dépend de la culture d'entreprise et c'est le combat perpetuel du génie logiciel que de bousculer les choses de ce côté-là. Mais aussi, on est pas obligé de se taper tous les diagrammes, on a juste besoin du nécessaire (on parle souvent de la règle de 80%-20%). Par exemple, CU, activité, classes, séquence, communication, packages. C'est fréquent dans mon milieu académique et professionnel.
Il ne faut non plus alourdir le développement avec un excès de diagrammes et de paperasse. À ce sujet, les méthodes agiles proposent une solution intéressante.

[...], l'implementation a souvent lieu en meme temps que, ou avant, la conception.

Certains modèles de cycle de vie et modèles de processus le permettent.

[chaplin]

Visiblement, tu accuse des lacune en conduite de projets : la coordination des équipes, la communication, le développement collaboratif, à quoi ça sert ? C'est fréquent, quand on apprend à programmer sur le tas et qu'on ne s'efforce pas d'encadrer ses projets de développement par le génie logiciel.
As-tu beaucoup d'expérience de vrais projets en équipe ?

Si d'aventure je devais nouveau m'impliquer dans un projet je saurais à qui m'adresser.

En plus la loi 80-20, quand on se tape le 80 % de temps pour les 20 % de code pourris à remettre d'aplomb ou qu'il faut se prendre le temps de réfléchir parce que les gars te répondent tous, on a pas le temps mais c'est facile, c'est juste que depuis des années personne n'avait le temps de faire.

[souviron34]

Tu devrais élargir tes horizons. Je te conseille de lire "P. Roques, Les cahiers du programmeur UML 2 : Modéliser une application web", "X. Blanc et I. Mounier, UML 2 pour les développeurs", "T. C. Lethbridge and R. Laganière, Object Oriented Software Engineering : Practical software development using UML and Java", "La traduction de B. Eckel, Think in C++ faite par développez.com, Penser en C++, p.39-40 particulièrement, paragraphe 1.9.3". La liste est longue ... Ce dernier est toujours disponible à http://bruce-eckel.developpez.com/li...on/ticpp2vol1/. Intéresse-toi aussi au "Model-Driven Architecture approach".

Je vois que tu cites beaucoup de bouquins.

Ce qu'on te cite, c'est l'expérience...

Comme le dit l'adage :

Quelle est la différence entre la théorie et la pratique?
En théorie y'en a pas, mais en pratique si...

Ou comme disait Einstein :

"La théorie, c'est quand on sait tout et que rien ne fonctionne.

La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.

Mais ici, nous avons réuni théorie et pratique: rien ne fonctionne et personne ne sait pourquoi"

C'est bien pareil avec le développement... Quand tu dis :

Visiblement, tu accuse des lacune en conduite de projets : la coordination des équipes, la communication, le développement collaboratif, à quoi ça sert ? C'est fréquent, quand on apprend à programmer sur le tas et qu'on ne s'efforce pas d'encadrer ses projets de développement par le génie logiciel.
As-tu beaucoup d'expérience de vrais projets en équipe ?

C'est nous qui te retournons la question, parce que visiblement tes affirmations sont très théoriques, mais la réalité est bien différente....


En dehors de tes certifs, quid de vrais éveloppements dans de vraies équipes ??

D'accord que ça dépend de la culture d'entreprise et c'est le combat perpetuel du génie logiciel que de bousculer les choses de ce côté-là. Mais aussi, on est pas obligé de se taper tous les diagrammes, on a juste besoin du nécessaire (on parle souvent de la règle de 80%-20%). Par exemple, CU, activité, classes, séquence, communication, packages. C'est fréquent dans mon milieu académique et professionnel.
Il ne faut non plus alourdir le développement avec un excès de diagrammes et de paperasse. À ce sujet, les méthodes agiles proposent une solution intéressante.
...
Certains modèles de cycle de vie et modèles de processus le permettent.

Je reprend ci-dessus..

UML n'est qu'un OUTIL, et j'ai déjà vu bien des utlisations qui ne font que complexifier De même que utiliser le mot "classes" est extrêmement restrictif... et si tu vas faire un tour dans lle forum conception, tu seras (peut-être ? moi pas du tout) surpris de l'absurdité, complexité, et flou qu'amènent souvent ces notions dans des choses qui autrement seraient simples....

[souviron34]

Ce qui est marrant, c'est que nos parcours n'ont rien à voir, et que pourtant bien des éléments de nos expériences semblent identiques...

Normal...

C'est justement ce que je dis plus haut, et que j'arrête pas de répéter ici ou sur le forum "Méthodes" ou "Alm" comme il s'appelle maintenant..

On veut faire de la théorie, de l'industrialisation, mais on oublie qu'on a affaire à des humains, et que c'est de l'artisanat.

Du coup, toute personne ayant passé un certain temps dans des projets/environnements différents se rend bien compte du fait que ni la théorie, ni l'industrialisarion ne marche...




PS: il ne viendrait à l'idée de personne de faire un "guide du compositeur"... ou de "guide du peintre" ou "guide de l'ébéniste". Ils ont des formations de base et apprennent ensuite par des maîtres, et font fonctionner leur créativité...

[jeandido]

Si d'aventure je devais nouveau m'impliquer dans un projet je saurais à qui m'adresser.

En l'occurence, t'adresser à des vrais ingénieurs, pas des bricoleurs !

En plus la loi 80-20, quand on se tape le 80 % de temps pour les 20 % de code pourris [...]

C'est 80% de modélisation avec seulement 20% de diagrammes UML. T'est hors sujet là.

[souviron34]

J'ai compris !!!!

Monsieur est soit un enseignant débutant soit un étudiant.. 25 ans.. mais principalement un blogueur.. Son blog est ici ... et vide....

OK...

Pas besoin de perdre sa salive

[gangsoleil]

En l'occurence, t'adresser à des vrais ingénieurs, pas des bricoleurs !

Mais est-ce que tu connais seulement de vrais "ingenieurs" comme tu dis ? Qui ont fait de vrais projets, dans la vrai vie, c'est a dire des projets qui sont rellement utilises par des clients qui ont paye pour ca ?

Ce que tu decris, c'est un petit jeune qui sort d'ecole, bien docile, avec des reves pleins la tete, tout frais tout beau, qui est persuade qu'il va utiliser les derniers trucs a la mode, que le projet sera gere en agil/scrum avec de belles conceptions, un client qui sait ce qui veut, un commercial qui vend au bon prix, des developpeurs a qui on laisse le temps, etc etc.

Et puis le premier projet arrive...
La demande du client est plus que vague, car en fait il ne sait pas ce qu'il veut... Mais il ne veut pas payer cher
Le commercial fait donc un tour "a la technique", qui lui repond 50 jours de dev, donc 200 jours a vendre. Le commercial va donc vendre 100 jours au client, car la technique abuse toujours.
On commence donc a faire des specs (externes et internes) ainsi qu'un planning, et comme tout ca ne rentre pas, on commence a virer des bouts, se dire que ca, "on verra plus tard, dans un second temps", que la doc ca peut etre fait lorsque le projet sera livre, etc...
Et puis en meme temps, le client se rend compte que ce n'est pas tout a fait ca qu'il voulait, donc qu'il faut changer les specs externes, ce qui change les specs interne, ce qui fait que ce que notre jeune developpeur vient de finir doit etre tout refait, car ce n'etait vraiment pas ca.
Mais pour ne pas tout perdre, on fait une bonne grosse verue, qu'on corrigera "dans le second step".

J'ai surement oublie une ou deux etapes, mais je pense que l'idee est la.

[jeandido]

J'ai compris !!!!

Monsieur est soit un enseignant débutant soit un étudiant.. 25 ans.. mais principalement un blogueur.. Son blog est ici ... et vide....

OK...

Pas besoin de perdre sa salive

Merci de s'investir sur moi plutôt que sur mes idées si ça peut t'aider ; mais je ne pense pas que ça avance le débat. Les esprits inférieurs discutent des personnes ; les esprits moyens discutent des événements ; les esprits supérieurs discutent des idées.
Le blog dont tu parles, je l'ai créé quand j'étais encore étudiant et j'y ai jamais rien ajouté. J'en ai créé d'autres comme ça sur d'autres plate-formes que j'avais effacés quand c'était possible. Je ne suis donc pas blogueur. C'était un exercice que nous avait fait faire notre prof de développement web. Ça, ça date, mon cher.
Et si tu doute de mon statut d'enseignant-chercheur parce que j'ai 25 ans, alors je suis fier de moi. Aux âmes bien nées, la valeur n'attend point le nombre d'années.
Demain, je te scannerai ma carte de service en bonus et, si t'a besoin d'un prof, je suis dispo.

[chaplin]

Et puis en meme temps, le client se rend compte que ce n'est pas tout a fait ca qu'il voulait, donc qu'il faut changer les specs externes, ce qui change les specs interne, ce qui fait que ce que notre jeune developpeur vient de finir doit etre tout refait, car ce n'etait vraiment pas ca.
Mais pour ne pas tout perdre, on fait une bonne grosse verue, qu'on corrigera "dans le second step".

J'ai surement oublie une ou deux etapes, mais je pense que l'idee est la.

La vraie vie des projets, quand on est en régie dans une équipe chez le client, la grosse verue pette à la figure parce que client voit tout. En fait, il faut savoir se défendre sinon le client te vire même s'il est en tort. Il pense d'abord à son budget, pas à ses erreurs.

[jeandido]

Mais est-ce que tu connais seulement de vrais "ingenieurs" comme tu dis ? Qui ont fait de vrais projets, dans la vrai vie, c'est a dire des projets qui sont rellement utilises par des clients qui ont paye pour ca ?

Ce que tu decris, c'est un petit jeune qui sort d'ecole, bien docile, avec des reves pleins la tete, tout frais tout beau, qui est persuade qu'il va utiliser les derniers trucs a la mode, que le projet sera gere en agil/scrum avec de belles conceptions, un client qui sait ce qui veut, un commercial qui vend au bon prix, des developpeurs a qui on laisse le temps, etc etc.

Merci de si mal me cerner. Des projets du genre "Système de recensement national pour un PVD 4 fois plus grand que ta France", c'est scolaire ça ?
T'as combien d'année de dév déjà ? 50, 60, 70 ?

Et puis le premier projet arrive...
La demande du client est plus que vague, car en fait il ne sait pas ce qu'il veut... Mais il ne veut pas payer cher
Le commercial fait donc un tour "a la technique", qui lui repond 50 jours de dev, donc 200 jours a vendre. Le commercial va donc vendre 100 jours au client, car la technique abuse toujours.
On commence donc a faire des specs (externes et internes) ainsi qu'un planning, et comme tout ca ne rentre pas, on commence a virer des bouts, se dire que ca, "on verra plus tard, dans un second temps", que la doc ca peut etre fait lorsque le projet sera livre, etc...
Et puis en meme temps, le client se rend compte que ce n'est pas tout a fait ca qu'il voulait, donc qu'il faut changer les specs externes, ce qui change les specs interne, ce qui fait que ce que notre jeune developpeur vient de finir doit etre tout refait, car ce n'etait vraiment pas ca.
Mais pour ne pas tout perdre, on fait une bonne grosse verue, qu'on corrigera "dans le second step".

J'ai surement oublie une ou deux etapes, mais je pense que l'idee est la.

Quoi de plus normal ? Ça fait des années que les choses se passent comme ça et qu'on apprend à faire avec.

[chaplin]

Et si tu doute de mon statut d'enseignant-chercheur parce que j'ai 25 ans, alors je suis fier de moi. Aux âmes bien nées, la valeur n'attend point le nombre d'années.

Mxxde, j'ai fais mon premier programme à 25 ans, je me disais bien que j'étais un raté! Ma devise, "il vaut mieux tard que jamais". Ceci dit, avec l'âge on apprend la sagesse, hein souviron.

[jeandido]

@ gangsoleil : Un débat intéressant ici http://www.developpez.com/actu/54962...s-plus-jeunes/

[chaplin]

@jeandido: à quel âge as-tu commencé l'informatique?

Ensuite, il serait bien de revenir au sujet de la discussion. Ce qui limite la réflexion c'est le facteur temps, on est toujours à la bourre dans les développements, il faut toujours trouver des compromis, chacun se protégeant comme il le peut pour gagner sa croûte dans la vraie vie des projets.

S'il est vrai qu'un code existant de 50 lignes et plus apparaît plus facile à lire (je le reconnais), le codage peut poser des problèmes quand il y a beaucoup de règles. Je pense à certains algorithmes en Fortran, forcément les codes étaient long, mais si utilise 4 boucles (x,y,z,t), parfois on a pas le choix, les fonctions sont longues. Je pense également aux composants graphiques où les fonctions de tracé sont complexes et ne tiennent pas en 10 lignes. On est toujours dans le compromis.

[gangsoleil]

Quoi de plus normal ? Ça fait des années que les choses se passent comme ça et qu'on apprend à faire avec.

Je ne comprends pas ton discours... D'un cote, tu dis que ca fait des annees que les choses se passent comme ca (specs a l'arrache, pas de modelisation, ...), et que l'on a appris a faire avec.

D'un autre cote, tu parles d'UML, qui n'est pas tant utilise que ca en entreprise, et qui est le plus souvent mal utilise. Tu parles de temps de modelisation, de conception, ... qui permettraient, entre autre, de s'assurer de la qualite du code.

Pour moi, ces deux choses sont contradictoires : soit la majeur partie des projets sont geres a l'arrache, avec des temps de dev 2 a 3 fois trop courts pour faire les choses correctement, soit les projets sont realises dans le pays des reves merveilleux, mais les deux sont malheureusement incompatibles.