Réinventer la roue, refaire un existant à sa propre sauce, c'est tellement jouissif!
Problème : ça n'apporte rien à l'utilisateur. Le développeur qui fait ça est donc un mauvais développeur. En tout cas c'est ce qui sera retenu.
Réinventer la roue, refaire un existant à sa propre sauce, c'est tellement jouissif!
Problème : ça n'apporte rien à l'utilisateur. Le développeur qui fait ça est donc un mauvais développeur. En tout cas c'est ce qui sera retenu.
Bah, il suffit de lire le manifeste agile, qui permet de répondre à ces assertions. Il a au moins le mérite de parler du projet, et pas seulement du développeur, qui n'en est qu'un maillon. Et de là à classer les développeurs entre très bons (forcément moi ) et les mauvais (les autres )...
http://agilemanifesto.org/
Rien à redire sur cette étude.
Sauf peut-être que les entreprises préfèrent les mauvais développeurs, qui donnent l'impression de toujours travailler, en massacrant leurs claviers, aux bons développeurs qui cherchent des solutions.
Une histoire de culture, vraisemblablement...
Oui j'ai vu une présentation sur cette manière de travailler qui est assez originale et plutôt intéressante. Par contre ça va actuellement à l'encontre de toutes les doctrines managériales actuelles . Maintenant il faut voir ce que ça va donner dans le futur mais ça a le mérite de responsabiliser chacun. J'aime bien aussi le petit coté pervers de cette méthode où chacun se met sa propre pression
Il y a des jours où j'éprouve une haine profonde envers microsoft et Apple c'est pas mieux
Mon modeste site et mes modestes oeuvres sont là
Rémi
... sont probablement ceux qui se refusent à l'affirmer haut et fort ?
Je pense qu'il ne s'agit là que d'un avis personnel, pas d'une vérité générale!
Celà devrait surtout nous amener à nous remmettre un peu en question sur nos pratiques et plus que de se focaliser "bon" ou "mauvais" programmeur, il est plus important dechercher perpétuellement à s'améliorer, c'est ça le crédo
Effectivement, que veulent réellement signifier les concepts d'être "bon" ou "mauvais" ?
Des personnes compétentes peuvent très bien être qualifiées de "mauvais" programmeurs pour diverses raisons, comme par exemple:
- La difficulté de s'intégrer dans une équipe ou se sont formés des clans,
- La préocupation unique de la hiérarchie ou du chef de projet de l'aspect financier d'un projet,
- La différence de culture au sein d'une équipe (ce qui revient à trahir un manque de management pour garder la cohésion de son équipe),
- Le fait que personne n'est parfais, mais jusqu'à quel point est-ce acceptable ?
- ...
Dans mon expérience, j'ai maintes fois remarqué des "bons" et des "mauvais", mais très souvent j'ai aussi constaté que les "bons" ne savent pas toujours qu'ils le sont et que les "mauvais" n'aspirent sincèrement qu'à mieux faire. Or, dans une organisation, la définition du "bon" et du "mauvais" peut être très facilement remise en cause, puisque ce n'est pas une notion qui semble être très bien définie en fonction des individus...
On peut donc se rabattre sur des critères dits "objectifs" en alignant des chiffres du nombre de lignes à coder, etc... Mais entre-nous, dites-moi entre ces 2 exemples (si l'on retient le critère du nombre de lignes de code), lequel est un code de "bon" programmeur et lequel est un code de "mauvais" programmeur (les exemples sont donnés en java et non commentés volontairement !) ?
A l'intention des non javaistes !
Cette méthode contrôle si un nombre quelconque entier est pair ou impair. Si le nombre est pair, la méthode retourne "true" donc la valeur booléenne "vrai", sinon elle retourne "false", donc la valeur booléenne "faux".
Exemple 1:
Exemple 2:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 public boolean isEven(int number) { int _val = number % 2; if(_val == 0) { return true; } return false; }
Merci pour vos commentaires.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 public boolean isEvent(int number) { return (number % 2) == 0; }
C'est pas une tare... Je considère que dans ce métier, on est "bleu" pendant au moins dix ans (pour les meilleurs).
En 25 ans de métier, j'ai pas connu bcp de projets faciles...mais j'ai compris que souvent, pour rattraper un retard, il fallait... prendre son temps. Prendre le temps de l'analyse, de la projection à long terme, et surtout, de la réorganisation en couches (au minimum métier /présentation/contrôle), car à partir de 50000 lignes, si le code ne respecte pas ça, on ne s'en sort pas, et les retards continuent de s'accumuler.
Ca n'a pas toujours été vrai. Pendant longtemps, les techniciens étaient impliqués dans la phase commerciale, et les évaluations étaient grosso modo réalistes. Mais on constate depuis qq années une dévalorisation technique de la phase commerciale. Elle est volontaire et touche tous les secteurs : les têtes pensantes du commerce on établi que c'était rentable de mentir... Nous, techniciens, devont nous battre contre ça, en disant dès le début d'un projet : voilà sur quoi je peux m'engager, et mes engagements, je les tiens, pas vos engagements. Ce discours a, au début, du mal à passer, mais comme il implique que tu t'engages sur qq chose, tôt ou tard il te rend crédible.
Dans ce métier, on n'est pas bon tout seul, on doit être bon en équipe. Une solution technique peut te paraître bonne et élégante pour résoudre ce que tu as à faire, mais mauvaise quand elle va être intégrée au projet. Il faut donc OBLIGATOIREMENT un référent, un chef d'orchestre.
Le "débrouillard" qui fait tout dans son coin sans en parler peut donc être une véritable catastrophe dans un projet, j'en ai connu qquns, et la plupart étaient vraiment "bons" techniquement parlant.
Dans mes équipes, les programmeurs avaient pris l'habitude de :
-ne jamais perdre plus d'une journée à trouver une solution technique : au-delà, ils venaient me demander. Au début, par fierté, certains s'acharnaient pendant trois jours avant de jeter l'éponge. Quand ils voyaient ensuite que j'avais tout de suite la solution, t'inquiète pas, ils avaient compris.
-de me soumettre la solution avant de l'appliquer : 2 fois sur 3, c'etait la bonne, parfois même elle était meilleure que ce à quoi j'aurai pensé. Mais 1 fois sur 3, elle avait un défaut plus ou moins grave qui aurait tôt ou tard plombé le projet.
Ceux qui n'avaient pas le pli le prenaient vite, car je faisais des revues de code régulières et je leur expliquais pourquoi ils avaient pris un mauvais chemin, et je leur faisais refaire... mais tous finissaient par trouver ce mode de fonctionnement logique et confortable, à part 2 fois en 25 ans (des irréductibles qui ont par la suite été d'échecs en échecs).
Bref, faut arrêter avec les "bons" et les "mauvais", la vérité, c'est que, bien encadré, le niveau moyen est assez homogène. Il y a qq surdoués et qq sous-doués, mais ils sont très rares.
Mal encadrés, les comportements sont plus hétérogènes et sont en fait fonction de la personnalité, les fameux "débrouillards" ayant alors l'air de tirer leur épingle du jeu (tant que le projet n'est pas trop gros), tandis que d'autres peuvent carrément partir en panique et faire n'importe quoi. Mais si tu m'as compris, ça veut pas dire que les premiers soient bons, ni que les seconds soient mauvais...
De mon point de vue : aucune importance. La seconde écriture témoigne simplement d'un peu plus d'expérience. Mais dans les deux cas la fonction fait le job, et c'est tout ce qu'on lui demande.
Ce qui serait grave, ce serait par exemple de créer qq part "IsEvent", et ailleurs "IsOdd", ou "IsNumberEvent", bref, plusieurs fonctions pour faire le même job, dégradant ainsi la maintenabilité du code.
Dans mes premières années de programmation, j'étais moi aussi attaché à l'efficacité et la concision. Je me suis rendu compte ensuite que c'était loin d'être primordial. C'est même carrément secondaire.
A noter quand même que la plupart des outils de vérification de code tiqueraient sur la première écriture (plus d'un return dans la fonction). A un moment, on utilisait ce type d'outil dans les process (me rappelle plus le nom, faudrait que je recherche) pour qualifier le code. Au final, bcp de temps passé, mais vraiment peu de retombées positives...
Faut vraiment rester concentré sur la conception et le respect des règles d'architecture (ISP, ADP, LSP, SDP, SAP, OCP, CCP, CRP, REP), c'est dix mille fois plus important.
Tout-à-fait vrai (le texte en début de fil).
Vrai aussi que ça paraît incohérent de conseiller d'être prêt à réécrire constamment son code, après avoir consenti des efforts pour qu'il s'adapte partout.
Après qu'on ait dit "it is not a bug, it is by design", on ne va pas se gêner pour dire qu'il peut être bon d'adapter un code, sans pour autant que ça oblige à tout réécrire. D'ailleurs en faisant ça on doit être attentif à rester compatible avec les appels existants. Si je ne m'abuse Developpez a écrit une chronique là-dessus l'année dernière.
En étant attentif à écrire du code réutilisable et à le répertorier de façon à le retrouver, on élimine une bonne partie des causes d'échec. Ensuite, on ne se débarrasse pas des causes inhérentes au client, entre celui qui vous impose une méthode d'évaluation ultra-lourde reposant sur des indices impossibles à obtenir et qui ainsi vous empêche de travailler, celui qui n'a pas l'aval de sa hiérarchie et qui se fait taper sur les doigts à la fin du projet, n'ayant pas anticipé des changements dans l'énoncé du problème ...
Alors prendre de la hauteur, perte de temps ?
Il y a peu j'aurais pu engager une mise en cause sur la question, mais en ce moment, le marché de l'emploi étant ce qu'il est, je suis avec quelqu'un qui envisage sans sourciller de charger dix fichiers qui vont mettre deux heures à se charger et tout planter au moindre incident réseau, pour des informations dont seul le dernier dixième évolue, plutôt que de mettre sur pied un mode de mémorisation, et ça juste pour économiser une demi-journée de développement au début. Alors forcément, on gagne sa vie comme en Inde.
Ce qui est discutable en fait est surtout le lien de cause à effet du précédent post souligné par la citation que tu fais.
Je pense que tout le monde est d'accord. Sauf les chefs (non techniques) bien souvent, donc le temps on ne l'a quand même pas. Rien ne change.
En outre, c'est bien gentil de compter les lignes de code, mais la complexité du système joue autant (voir plus).
Il me semble que ça fait quand même 40 ans qu'on cherche à faire des choses de plus en plus complexes en moins en moins de temps. A l'échelle de l'informatique qui est un domaine "jeune", ça fait presque une éternité.
Quand on a la chance d'avoir une hiérarchie à l'écoute, le technicien a tout intérêt à s'imposer pour trouver un compromis.
Mais on ne peut raisonnablement pas dire que c'est le cas de tout le monde.
Il y a une nette différence entre être dépendant d'un "architecte" et travailler en équipe.
La débrouillardise qu'on attend d'un ingénieur (avec l'indépendance qui suit) est de s'intégrer dans une équipe et de savoir communiquer - sur ce point on est d'accord, mais pas sur les mots.
[|]
Nous touchons un point intéressant ici sur la problématique de concision du code. Je me suis toujours demandé jusqu'à quelle limite la concision pouvait être utilisée et son degré d'importance.
Tu écris :
Puis plus loin... Mais dans les deux cas la fonction fait le job, et c'est tout ce qu'on lui demande.Pendant quelques temps j'avais aussi adopté ce point de vue, or ces dernières années je reviens sur cette affirmation après avoir été arrosé plusieurs fois par du code type du premier exemple donné dans mon message précédent. Le problème est que la maintenance de code devient très ardue, car il s'agit pour la personne qui débarque dans un projet de faire un gros effort intellectuel pour ne pas perdre le fil du code dont il prend connaissance. Parfois, on se demande même si dans un tel code, ne se cacherait pas autre chose que nous n'aurions pas compris.... Dans mes premières années de programmation, j'étais moi aussi attaché à l'efficacité et la concision. Je me suis rendu compte ensuite que c'était loin d'être primordial. C'est même carrément secondaire.
Il est vrai que nous avons aussi l'extrême inverse, probablement mieux connu, d'une trop grande concision qui conduit à une écriture énigmatique du code. Au final ce n'est pas mieux que du code verbeux.
Aussi, à la lumière de ta réponse, et de celles des autres personnes sur ce forum, il est clair qu'une règle de concision doit exister dans l'écriture de son code, le tout étant de savoir où l'on doit s'arrêter. Et là c'est aussi un autre problème : comme la limite dépend de beaucoup du point de vue de chacun, il est évident que nous n'aurons jamais de "bon" code qui permettra de définir un "bon" programmeur et donc aussi par conséquent un "mauvais". Néanmoins 2 règles peuvent être empiriquement définies et suivies (après plusieurs années d'application de ces règles les résultats sont globalement bien acceptés par beaucoup) :
- La vie est très compliquée : simplifiez, simplifiez, simplifiez...
- Vous n'écrivez pas du code pour vous mais pour les autres
La première règle est inspirée d'un auteur dont j'ai malheureusement oublié le nom ! La deuxième est le fondement même du vrai travail d'équipe.
Le travail du développeur, ce qui fera sa compétence et son métier (entre autre chose), étant de trouver le juste milieu entre ces 2 règles.
Un dernier petit commentaire à l'attention de ceux qui ont pris la peine de me répondre.
@maske :
1/ Dans ce métier, on n'a pas le choix. Soit on impose ses idées, soit on subit celles des autres, et faut pas venir se plaindre. La culture du semi-échec récurrent, dont tu te fais le porte-parole un peu désabusé n'est pas une fatalité, mais malheureusement elle conduit souvent à "laisser-faire", avec dans l'inconscient : "si ça foire, au moins ce ne sera pas de ma faute". Mauvais calcul : y'en aura toujours des plus forts que toi quand il faudra se dédouanner. Et de toute façon, dans une équipe qui perd, personne ne sort grandi.
Même si on n'y arrive pas toujours, surtout face à des non-techniciens, faut toujours se battre pour convaincre, quitte à se faire virer du projet (je parle d'expérience). C'est mon conseil, après c'est toi qui voit.
2/ A qualité d'écriture et de conception égale, il y a une relation directe entre nombre de lignes et complexité, c'est pas moi qui le dit.... Le chiffre de 50KLOC est bien sur une moyenne. C'est à partir de là que le cerveau humain n'arrive plus à appréhender en permanence l'ensemble, et que les artefacts de conception (schémas UML) deviennent indispensables pour maintenir la cohérence.
Le deux + gros softs que j'ai conçus atteignaient 1MLOC. Ils ont tous les deux été livrés dans les délais & sans dépassement de budget. C'est impossible à faire sans architecte référent. Enfin moi j'ai jamais vu.
Travailler en équipe sans architecte, ça va pour les petits projets, pour les autres c'est retard assuré, voir pire.
C'est marrant, dans les autres industries, il ne viendrait pas à l'idée de contester ça (on peut faire sa cabane au fond du jardin sans architecte, mais pas un building), mais dans l'informatique, c'est vraiment pas encore acquis, t'es pas le premier à se montrer dubitatif.
@jsnooper : je suis d'accord, faut savoir positionner le curseur, et c'est d'ailleurs en ça que les outils de vérification de code peuvent être utiles, comme les relectures croisées : ça homogèneïse l'écriture.
Mais, à part pour une recherche ponctuelle de performance pour un bout de code critique, ça fait longtemps que je ne m'excite plus sur un gazier qui écrit du code à rallonge ou au contraire, comme tu dis, énigmatique. Dès l'instant que les interfaces sont claires et respectent le design, c'est tout ce qui m'importe. Après, je sais qu'en prenant de la bouteille, et à force de voir le code des autres, il va progresser...
ça me rappelle qu'il y a deux gros boulets dans la boîte ou je suis.
Pour l'anecdote. Je regardais le travail d'une autre équipe de Dev. sur un source commun et là je remarque que l'un des développeur à livré une fonction identique au LeftStr de Delphi. En fait, la seule chose qui changeait était les nom des variables sinon c'était rigoureusement la même. J'envoie donc un mail à cette personne en mettant les forme afin de ne pas le contrarier pour lui dire que la fonction qu'il avait codé était déjà native à Delphi. Il me répond que ce n'est pas lui qui avait codé cette fonction, mais qu'il s'était contenté de déplacer cette fonction du source d'un autre collègue parce que l'unité où elle se trouvait avait de l'IHM et que son plugin ne compilait plus.
ça fait donc deux boulets, un qui s'amuse à recoder les fonctions de bases incluses dans delphi et un autre qui l'utilise dans plusieurs de ces sources en ajoutant pour l'occasion des tonnes de uses inutiles !
Mes tutoriels
Avant de poster :
- F1
- FAQ
- Tutoriels
- Guide du développeur Delphi devant un problème
Cette anecdote est un cas d'école, non pas pour stigmatiser l'incompétence d'un tel ou un tel, mais parce qu'elle témoigne d'une organisation particulièrement défaillante, sans aucun processus de contrôle.
Ce type d'erreur n'aurait en effet pas pu se produire si les projets avaient mis en place des relectures croisées et des revues de design. Vous êtes loin du CMMI2 dans ta boîte.
Et faut pas venir me dire "on peut pas faire ça, on nous pousse au cul et on n'a pas le temps". Car l'effort de qualité qu'on ne fait pas pendant les dev, on le paye puissance 10 sur les dernières fonctionnalités, les intégrations, et surtout en alpha tests avec une déferlante de bugs, qui de surcroît deviennent au fur et à mesure de plus en plus compliqués à corriger. Vous avez sans doute tous pu constater que c'est là que les plus gros retards sont pris.
Soit dit en passant, l'erreur initiale la plus grave n'est pas la duplication de fonction native, mais sa dépendance par rapport à un module de présentation.
Il faudrait être sacrément vaniteux pour pouvoir dire de soi-même qu'on est un bon développeur, et encore plus sacrément chanceux pour que ce soit vrai...
Pour moi, on ne peut vraiment être jugé sur ce point que par ses pairs, et encore, par ceux qui ont pu parcourir et expérimenté des pans de code suffisants dans ses applications...
(tellement jugent directement mauvais ou bon développeur des gens dont ils n'ont pas lu une seule ligne de code... Et ce sont des développeurs, en plus, la plupart du temps...)
"Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live." (Code for the Maintainer)
I usually maintain my own code, so the as-if is true!
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.
Partager