Introduction décente à l'orienté objet ?

[neuneu2k]

Il est a chier l'article Wikipédia, il oublie de préciser que c'est probablement le plus overabused de tous les patterns utilises par ceux qui veulent le mettre sur leur CV et/ou qui aiment faire du code inbitable parce qu'ils pensent que ça donne l'air intelligent.

PS: a tous, si un jour vous vous dites 'la, il faut un pattern XXX' vous n'avez pas pige les design patterns, le seul usage valide c'est 'j'ai écris du code pour faire YYY, pour expliquer ce q´il fait, je regarde si c'est pas un pattern référencé, ça permet de communiquer facilement'

PPS: ce n'est pas parce que je suis un expert Java que je ne déteste pas les côtés enterprise-buzzwords et OOP worship, au contraire !

[pankkake]

[Noob]

 il oublie de préciser que c'est probablement le plus overabused de tous les patterns utilises par ceux qui veulent le mettre sur leur CV 

PS: a tous, si un jour vous vous dites 'la, il faut un pattern XXX' vous n'avez pas pige les design patterns, le seul usage valide c'est 'j'ai écris du code pour faire YYY, pour expliquer ce q´il fait, je regarde si c'est pas un pattern référencé, ça permet de communiquer facilement'

 

 

Je pensais que c'était le singleton, en plus je l'ai déjà vu mal fait.

Et oui les design pattern ne servent à rien s'il ne sont pas utiliser pour communiquer. L'autre usage : c'est j'aurais besoin de faire XXX, je pense le faire comme ça. Existe-t-il un problème avec ma façon de faire ? 

[neuneu2k]

J'ai vu un visiteur monté a l'envers une fois, toute modification du code touchait TOUTES les classes :-)

[Rincevent]

Et l'article WP n'avance pas vraiment un type qui n'a jamais vraiment fait d'OO. M'enfin bref, un jour je comprendrai.

[Nirvana]

Bon, j'arrive à avoir la sortie suivante : http://pastebin.com/PnjDKe5L

 

C'est quasiment pareil que ce qu'attendait le prof, sauf que dans sa version (http://pastebin.com/RptWvv0n) il y a des sauts de ligne là où il faut, alors que chez moi tout est sur une ligne.

 

Vu que je n'y connais rien à DOM, je ne sais pas ce qu'il manque dans mon code pour régler ça : http://pastebin.com/x6ed3ubL

[pankkake]

J'irai essayer http://docs.oracle.com/javase/6/docs/api/javax/xml/transform/OutputKeys.html#INDENT

        trans.setOutputProperty(
                OutputKeys.INDENT,
                "yes");

Diverses réponses dont la mienne sur http://stackoverflow.com/questions/139076/how-to-pretty-print-xml-from-java

[Nirvana]

J'irai essayer http://docs.oracle.com/javase/6/docs/api/javax/xml/transform/OutputKeys.html#INDENT

        trans.setOutputProperty(
                OutputKeys.INDENT,
                "yes");

Diverses réponses dont la mienne sur http://stackoverflow.com/questions/139076/how-to-pretty-print-xml-from-java

 

 

Merci, c'est parfait.

[Nirvana]

C'est trop long pour un copier-coller, mais que pensez-vous de ces commentaires et conseils évoqués dans cet article ?

 

The Exceptional Beauty of Doom 3’s Source Code : http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code

[Greg42]

C'est trop long pour un copier-coller, mais que pensez-vous de ces commentaires et conseils évoqués dans cet article ?

 

The Exceptional Beauty of Doom 3’s Source Code : http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code

 

Je pense qu'il a raison sur la majorité des points (je ne suis pas d'accord sur la critique d'Alexandrescu, ni avec sa règle des accolades).

Mais oui écrire un programme est avant tout un travail d'équipe, on écrit surtout pour les autres membres de l'équipe. Il faut donc que ce soit propre et lisible. Le plus important n'est pas vraiment la technique, mais la communication.

[Yozz]

Je pense qu'il a raison sur la majorité des points (je ne suis pas d'accord sur la critique d'Alexandrescu, ni avec sa règle des accolades).

Mais oui écrire un programme est avant tout un travail d'équipe, on écrit surtout pour les autres membres de l'équipe. Il faut donc que ce soit propre et lisible. Le plus important n'est pas vraiment la technique, mais la communication.

Tu Veux pas venir coacher mes devs?

[pankkake]

Je pense qu'il a raison sur la majorité des points (je ne suis pas d'accord sur la critique d'Alexandrescu, ni avec sa règle des accolades).

Mais oui écrire un programme est avant tout un travail d'équipe, on écrit surtout pour les autres membres de l'équipe. Il faut donc que ce soit propre et lisible. Le plus important n'est pas vraiment la technique, mais la communication.

C'est entre autres pour ça qu'on fait du code bien meilleur quand on sait que nos collègues vont le subir

Tu Veux pas venir coacher mes devs?

C'est des petits jeunes ?

[Yozz]

C'est des petits jeunes ?

Non, au contraire, des vieux qui ont eu l'habitude de maintenir du code tout seul pendant des années donc l'attitude c'est "tant que je m'y retrouve, c'est bon". Ce qui signifie donc que personne d'autre ne s'y retrouve maintenant que la boite change, et qu'en plus honêtement ils ne s'y retrouvent pas eux-mêmes s'ils doivent rentrer dans un vieux truc...

[neuneu2k]

J'ai été un moment convaincu que le code devait être lisible, maintenant, je n'en ai plus rien a foutre, ce que je lui demande c'est juste d’être modulaire.

 

Je veux des contrats, des interfaces nettes, documentées  et stables entre les modules, que personne ne modifie sans une deuxième paire d'yeux.

 

Et ce qu'il y a dans le module, a partir du moment ou y'a DEUX personnes qui le comprennent, c'est bon, et si il n'y en a q'une, tant pis, au pire on réécrira le module. (mais on se colle une alerte dessus si il semble dur a réécrire)

 

Attendre a la fois de la compétence et de la discipline de milliers de développeurs, c'est s'exposer a l'échec majeur, je préfère partir du principe que ceux qui sont disciplinés sont en majorité incompétents et que ceux qui sont compétents sont très rarement disciplinés, c'est plus réaliste.

 

Bien entendu, il est possible de faire autrement, je n'ai pas dit que c'était une bonne idée ™ d'avoir des développeurs par centaines...

 

 

[Yozz]

C'est une question d'équilibre, non? Toujours difficile à atteindre, c'est sûr, mais essayer d'y tendre me semble pertinent.

[h16]

Même avis que Neuneu.

Ayant des exigences très fortes limite casse-couille pour le code, j'ai rapidement laissé tomber. Maintenant, je veux que les modules sont "self-contained", autrement dit, on sait ce qu'on doit pousser en entrée, on sait ce qu'on doit recevoir en sortie, et démerdez vous pour le milieu.

En pratique, vu l'environnement, ça part souvent en vrille, mais l'idée est là.

[Greg42]

Je veux des contrats, des interfaces nettes, documentées  et stables entre les modules, que personne ne modifie sans une deuxième paire d'yeux.

Donc tu milites donc déjà pour un peu de lisibilité ;-)

 

Note que pour la documentation, à l'usage je suis devenu presque contre. Les 3/4 du temps elle n'était pas maintenue, et obsolete. Désormais, je ne demande (force) un commentaire que lorsqu'il s'agit d'expliquer une situation tricky. Le reste du temps des contrats (assurés par des unit-tests) suffisent.

 

Et ce qu'il y a dans le module, a partir du moment ou y'a DEUX personnes qui le comprennent, c'est bon, et si il n'y en a q'une, tant pis, au pire on réécrira le module. (mais on se colle une alerte dessus si il semble dur a réécrire)

 

Attendre a la fois de la compétence et de la discipline de milliers de développeurs, c'est s'exposer a l'échec majeur, je préfère partir du principe que ceux qui sont disciplinés sont en majorité incompétents et que ceux qui sont compétents sont très rarement disciplinés, c'est plus réaliste.

Sur tes modules, combien de devs travaillent dessus ? Si c'est plus de deux, je continue de penser que du code propre et lisible est important. Car autrement, la maintenance corrective fini par coûter extrêmement cher. Surtout, intégrer un "nouveau" sera plus long. Exit donc les aides extérieures pour palier à un rush.

Note qu'il est relativement "facile" de forcer des devs à produire du code propre et lisible. Il faut :

• Un doc avec des règles de nomenclature de code.
• Appliquer le théorème du singe   (http://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_du_singe)
• Et un bon lead.

 

Bien entendu, il est possible de faire autrement, je n'ai pas dit que c'était une bonne idée d'avoir des développeurs par centaines...

Oui de toute façon j'imagine que lorsque tu travailles sur le même projet qu'une centaines d'autres dev (je n'ai jamais fait, je suis plus un profil start-up), ceux ci sont splittés en petites équipes. Chaque petite équipe sur un module.

 

Même avis que Neuneu.

Ayant des exigences très fortes limite casse-couille pour le code, j'ai rapidement laissé tomber. Maintenant, je veux que les modules sont "self-contained", autrement dit, on sait ce qu'on doit pousser en entrée, on sait ce qu'on doit recevoir en sortie, et démerdez vous pour le milieu.

En pratique, vu l'environnement, ça part souvent en vrille, mais l'idée est là.

Ah mais j'ai pas dit qu'il fallait être trop casse-couille non plus.

J'ai déjà entendu des lead pester contre les fonctions de plus de 20 lignes ou avec plus de 5 arguments. C'est quelque chose que l'on peut demander d'éviter, mais qu'il faut savoir accepter quand surtout lorsque c'est justifié. Un peu comme le goto ;-) (Normalement j'arrive à lancer un troll avec cette phrase ! :-p )

Et de toute façon, oui il faut être pragmatique, je suis d'accord avec Yozz, c'est une question d'équilibre.

 

Edit : Ce fil ne devrait pas être dans la taverne ?

[pankkake]

Non, au contraire, des vieux qui ont eu l'habitude de maintenir du code tout seul pendant des années donc l'attitude c'est "tant que je m'y retrouve, c'est bon". Ce qui signifie donc que personne d'autre ne s'y retrouve maintenant que la boite change, et qu'en plus honêtement ils ne s'y retrouvent pas eux-mêmes s'ils doivent rentrer dans un vieux truc...

FUIS

[neuneu2k]

Si ça ne dépendais que de moi, aucun projet ne comporterai plus de trois développeurs, ca ne signifie pas que l'équipe projet ne peut pas atteindre la bonne dizaine, mais pas plus de trois devs, si ce n'est pas possible: découper en sous projets.

 

Mais ça ne dépends pas que de moi, et il y a un soft interne en particulier, mal modularisé  sans interfaces formelles, sur lequel bossent plus de 300 personnes qu'il va falloir modulariser dans les années qui viens, c'est mon cauchemard...

 

 

[pankkake]

L'avantage d'un module bien isolé incompréhensible, c'est qu'on peut toujours le jeter et le réécrire.

C'est parfois plus rapide.

Les 3/4 du temps elle n'était pas maintenue, et obsolete.

C'est le pire de loin.

Et comme ce n'est pas mesurable, c'est un produit des règles « il faut 20% de commentaires » et autres.

[pankkake]

Si ça ne dépendais que de moi, aucun projet ne comporterai plus de trois développeurs, ca ne signifie pas que l'équipe projet ne peut pas atteindre la bonne dizaine, mais pas plus de trois devs, si ce n'est pas possible: découper en sous projets.

 

Mais ça ne dépends pas que de moi, et il y a un soft interne en particulier, mal modularisé  sans interfaces formelles, sur lequel bossent plus de 300 personnes qu'il va falloir modulariser dans les années qui viens, c'est mon cauchemard...

Heureusement que je ne bosserai jamais dans ce genre de boîte dans lesquelles 3 femmes font un enfant en 3 mois

[Yozz]

FUIS

 

J'aurais dû...

[Poil à gratter]

Ce n'est pas indépendant. Il me semble que les bonnes pratiques de Java, c-à-d. toujours factoriser, toujours abstraire un niveau plus haut, mènent aux frameworks Java et à un cadrage toujours plus strict du métier de programmeur. C'est de l'industrialisation. D'artisan créateur dans un atelier, le programmeur devient ouvrier spécialisé dans une usine. Je comprends bien l'évolution, je mesure sa valeur, sauf que le nouveau métier ne me plait pas. Et je reste sur l'ancien, même s'il faut pour cela revenir à des technologies elles-mêmes plus artisanales.

 

Alors tu seras peut-être intéresse par le Software craftsmanship, un blogueur français en parle ici:

 

http://www.touilleur-express.fr/2011/01/20/craftsmanship/

 

Mais bon, il faut savoir qu'il y a une légère différence entre le métier de programmeur Java pour une SSII dans une banque/assurance/industrie et chez un éditeur de logiciel.

[L'affreux]

Merci, je ne connaissais pas ce "mouvement".

Mais bon, il faut savoir qu'il y a une légère différence entre le métier de programmeur Java pour une SSII dans une banque/assurance/industrie et chez un éditeur de logiciel.

Je n'ai travaillé que chez des éditeurs et des utilisateurs réalisant en interne des solutions maisons. Huit ans de Java, treize expériences (je m'ennuie vite). J'avais un CV idéal pour les boites à la bourre dans leurs livraisons.

Mais les éditeurs développant de manière artisanale se font rares. Tous veulent faire du lourd.

[Poil à gratter]

Sinon il y a un bon bouquin sur les normes de codage: Clean Code:

 

Il parlent justement des commentaires en disant qu'il est préférable de ne pas en abuser puisque c'est du code mort qui va forcement finir par diverger d'avec le code vivant. En fait plutôt que mettre un commentaire, il vaut souvent mieux refactorer en introduisant une méthode avec un nom qui explique précisément ce que fait la méthode: ca fait d'une pierre 2 coups puisqu'on satisfait aussi la règle des méthodes courtes (<25 lignes).

 

M'enfin une méthode efficace consiste finalement a faire bosser les développeurs en open-source: ca garanti rien par défaut, mais s'ils ont un minimum de fierté et de conscience professionnelle ils vont éviter de committer du code pourri que le monde entier pourra voir

[Poil à gratter]

Merci, je ne connaissais pas ce "mouvement".

Je n'ai travaillé que chez des éditeurs et des utilisateurs réalisant en interne des solutions maisons. Huit ans de Java, treize expériences (je m'ennuie vite). J'avais un CV idéal pour les boites à la bourre dans leurs livraisons.

Mais les éditeurs développant de manière artisanale se font rares. Tous veulent faire du lourd.

 

T'aimes les frikandels ? Les canaux et les vélos ? Envie de te barrer de France ?

 

Tente ta chance: on recrute et on fait dans l'artisanal !

 

PS: c'est pas une blague.

[L'affreux]

Je suis déjà parti, et trop loin pour revenir vers les Pays-Bas, mais maintenant je serais curieux d'en savoir plus.

[Brock]

je reclame une introduction indecente a l'oriente femme-objet

[POE]

je reclame une introduction indecente a l'oriente femme-objet

 

macho ! Retourne à tes magazines coquins

[Poil à gratter]

Je suis déjà parti, et trop loin pour revenir vers les Pays-Bas, mais maintenant je serais curieux d'en savoir plus.

 

Repondu en MP !