Qu'est ce que les hacks en developpement?Citation:
Envoyé par Amnell
Version imprimable
Qu'est ce que les hacks en developpement?Citation:
Envoyé par Amnell
Cette classification me rappelle assez celle des modèles de maturités :
Niveau de maturité:
- +5 : Optimised
- +4 : Managed (quantified)
- +3 : Defined (standardized)
- +2: Repeatable (disciplined)
- +1 : Initial (chaotic, ad hoc, heroic)
- 0 : Negligent
- -1 : Obstructive
- -2 : Contemptuous
- -3 : Undermining
Je me retrouve dans la catégorie 2.
Alors "hack" synonyme: bidouille, "truc et astuce" ou encore un truc foireux :)Citation:
Envoyé par plouiserre
Definition : petit bout de code que tu glisses dans ton application pour corriger souvent un bug ou pour mettre en place une évolution de la mort de derniere minute sorti par ton chef. Comme souvent ces petites mise à jour t'obligent à casser la belle architecture de la mort que tu as concu, ce qui te fendrait le coeur, tu préferes mettre en place une petite bidouille, un truc foireux qui n'est généralement pas documenté mais qui fait que tout marche. Tant que c'est toi qui maintient l'appli, il n'y a pas de souci.
Les problèmes surviennent lorsqu'un autre développeur reprend l'application.
Car le hack est bout de code qui laisse généralement perplexe, on a souvent l'impression que ca sert à rien et on a souvent envie de le supprimer, c'est la que les ennuies commencent.
Il y a ceux qui produisent des codes élégants dans le respect des délais et avec un souci commercial évident...
Wow... non seulement le Père Noël existe, mais en plus il travaille dans une SSII. :aie:Citation:
Envoyé par ThomasR
ou chez Apple... :langue2:Citation:
Envoyé par pcaboche
Je reprends un peu la définition de notia car je n'ai pas exactement la même.Citation:
Envoyé par plouiserre
Un hack est une manière de modifier le comportement normal d'une application.
En développement, c'est donc quelque chose qui va sortir du cycle de fonctionnement classique.
Exemple : j'ai une appli qui récupère des données dans une database et qui les affiche. Mais pour X ou Y raison, la base n'a pas les données du mois de novembre. Je connais ses données mais je n'ai pas le droit de modifier la base. Je fais donc rajouter "en dur" dans mon code quelque chose du genre "si le mois demandé est novembre alors ne va pas chercher les données de la base mais prend les ici", en écrivant directement les données dans les fichiers du programme.
Bien sûr, ça marche, mais c'est épouvantable pour la maintenance...
Parce que tu trouves çà paradoxal ? Moi pas.Citation:
Envoyé par pcaboche
Lorsque ca fait des années que tu développes avec un language, si t'arrives pas à faire des codes optimisés, élégants et à les pondre dans le respect des délais c'est qu'il faut arrêter ce métier.
Dans le fond sa catégorisation est marrante, c'est à sortir devant la machine à café.
(je sens que ma prétention va me couter cher ;))
Je suis d'accord... tant que tu travailles tout seul. :aie:Citation:
Envoyé par ThomasR
Le problème, c'est que ce cas est rare. Le plus souvent, tu travailles au sein d'une équipe et là, les choses se gâtent.
Tout d'abord, il y a la hiérarchie. Tu as un chef qui veut que les choses soient implémentées d'une certaine façon et si tu entrevois que ça va poser des problèmes à l'avenir (ex: problèmes de performance), il va falloir parlementer pendant des heures avec ledit chef. S'ensuivent des discussions souvent houleuses qui finissent presque invariablement par "c'est moi le chef, tu fais ce que je dis et tu discutes pas".
Variante: l'entreprise est organisée de telle façon que tu as les concepteurs d'un côté (qui sortent de beaux diagrammes UML, toussa) et les développeurs de l'autre (qui sont confrontés aux problèmes d'implémentation que les beaux diagrammes UML ne pouvaient prévoir).
Ensuite, tu as les autres collègues. La directive, c'est : "il faut écrire du code qui soit facilement compréhensible par tous, au cas où quelqu'un devrait reprendre ton code" (ce que j'appelle vulgairement : "apprendre à programmer pour les nuls").
Traduction d'un point de vue IT : "Fais une implémentation naïve, même si c'est pas performant, de manière que même un stagiaire pourrait comprendre"
Traduction d'un point de vue RH : "Si tu continues à remettre en question les choix de ton chef (alors que tes arguments sont parfaitement fondés), tu risques de prendre la porte, même si tu es considéré par tous comme le meilleur développeur de la boite... Donc ça serait sympa si quelqu'un pouvait maintenir ton appli après ton départ"
Du coup, sur ordre du patron, on part pour l'implémentation naïve, ultra compréhensible, mais qui est tellement peu performante qu'elle en est complètement inutilisable ("pourtant j'vous avais prévenus" :whistle:). De là tu dois subir les foudres des utilisateurs mécontents et ton patron viens te demander "t'aurais une solution pour résoudre ce problème ?" (par "solution simple" il pense bien évidement : "un petit hack qui me permettrait de ne pas perdre complètement la face") et toi de lui répondre: "oui, j'ai une solution : TOUT CASSEEEEEEEER !"
Par chance, ce n'est pas une grosse appli (d'un point de vue taille du code. Par contre pour la boite, c'est crucial pour le business) et certaines parties de code peuvent être récupérés (les bouts de code adaptés des exemples fournis dans la doc officielle de la bibliothèque qu'on est en train d'utiliser). Tu refais l'appli et ô miracle, ça marche nickel ! (et ça prend vraiment peu de ressources)
En plus le code est beau et élégant... pour ensuite te rendre compte que tes charmants collègues pourtant "expérimentés" ne savent pas ce qu'est un Generic et n'ont jamais écrit d'application qui s'exécutait sur plus d'un thread à la fois. :?
Avis du patron: "de belles réalisations, mais souvent un peu complexes et une tendance à tout réécrire". Boulet, va ! :furax:
Si, à la lecture de ce pamphlet, vous avez l'impression que ça sent le vécu, c'est parfaitement normal... :aie:
Bonjour à tous!
J'ai l'impression qu'on forme de plus en plus de développeurs de la troisième catégorie, ceux qui cherchent une "fonction" toute faite. Pour vous en rendre compte, je vous conseille d'aller voir les questions posées dans le forum Matlab.
Jean-Marc Blanc
Personnellement (récemment diplômé) j'aurais dit la 4ème :cry:Citation:
Envoyé par FR119492
Non ça dépend à fond du programmeur. Sur mes projets, j'ai eu des gars, impossible de leur faire pondre une analyse technique de ce qu'ils devaient faire. Directement dans le code. Je ne dis pas la qualité du code, en termes de maintenance, performance et évolutivité !Citation:
Envoyé par Psycha
Quelle image de merde tu as des chefs de projet ! Les bons techniciens (ie développeurs, architectes, ...) sont là pour être écoutés et conseiller leur hiérarchie immédiate sur les pros et les cons des choix et solutions techniques. Mais bon forcément, il y a des gars qu'on est plus prompt à écouter que d'autres, et pas forcément ceux qui abondent dans notre direction.Citation:
Envoyé par pcaboche
Quelle est votre définition du « vrai développeur » et comment le trouvez-vous ?
Un blogueur expose son point de vue
Mise à jour du 23/11/2010
Nous avons passé en revue hier (lire ci-avant) un billet du blogueur Steven Benner. Son article a suscité sur Développez.com de nombreuses réactions et un débat intéressant.
Mais il a une suite.
Après s'être attaqué (d'une manière assez caricaturale) aux catégories des développeurs, l'auteur expose, dans un billet plus recherché, sa propre définition du « vrai développeur », comprendre les qualités qui doit réunir un bon développeur.
Selon lui, les vrais développeurs sont ceux qui peuvent apprendre vite, apprendre par la pratique, et ne jamais arrêter d'apprendre.
La définition de Benner ne serait donc pas incompatible avec les développeurs qui utilisent du code trouvé sur Google (ou Bing). Bien au contraire.
Ces développeurs, en arrivant à trouver et à adapter rapidement des solutions à leur travail font justement preuve de capacités d'apprentissage et d'adaptation.
Pour trouver les vrais développeurs, Benner donne quelques pistes. Parmi lesquelles, il recommande de mettre les candidats à l'épreuve mais sur des compétences de haut-niveau, non pas sur des patrons de conceptions ou d'obscures problèmes algorithmiques.
Des problèmes théoriques, utilisés par certains recruteurs pour départager les candidats, feraient passer à côté de certains "vrai développeurs". Car ces derniers peuvent de ne pas arriver à se rappeler de solutions à des problèmes qu'ils ne rencontrent que rarement, voire jamais.
En revanche, il déconseille de recruter les développeurs qui s'intéressent plus à l'informatique théorique qu'à l'expérience effective. Benner les considère même comme "une épine perpétuelle dans le pied de l'industrie du développement".
Source : le blog de Steven Benner
Et vous ?
:fleche: Êtes-vous d'accord avec la définition de Benner ?
:fleche: Quelle est votre propre définition du vrai développeur et comment faites-vous pour les dénicher ?
Il revient à ma mémoire une définition d'un de mes professeurs. C'était dans un autre contexte, mais c'est applicable à l'opinion de Steven Benner.
Face à un problème :
- Les mauvais développeurs croient connaitre la bonne méthode
- Les bons développeurs connaissent déjà la bonne méthode
- Les grands développeurs ne connaissent pas la bonne méthode, mais savent comment la trouver
Totalement d'accord ! Le développement, c'est la loi de l'évolution : si tu restes sur tes acquis, tu meurs (ou tu va faire de la bureaucratie/du management, autre forme d'évolution). Les développeurs d'il y a plus de 20-25 ans ont dû laisser le Fortran, le COBOL et autre Lisp de côté pour rester dans la course. De même, les développeurs actuels devront dire un jour adieu à Java, C# et Python (voire C++ ?) pour peut-être le langage D et Google Go.Citation:
Envoyé par Idelways
Étrangement, il n'y a que le C qui arrive à traverser les époques. Jusqu'à ce qu'il soit décrété comme étant "trop vieux pour l'Informatique" ?
:D
Mort de rire quand j'ai vu les 5 classifications.
Indéniablement dans la catégorie 1 et 5, c'est affolant...
C'est plus fort que moi... Par exemple, si jamais je sens, dans un bout de code, que ya une ligne de trop, la moindre instruction inutile, je peux passer des heures (des jours :aie:) dessus, pour trouver THE solution, parfaite, belle brillante, absolument magnifique...
Il faut comprendre, même si ça implique un truc du genre v^=~(0xAF << (i >> 3));
:aie:
Perfectionnsite jusqu'au bout des ongles... Capable de passer des heures à ré-indenter un code qui desfois met des TAB de 4 espaces et des TAB de 3 espaces ^^
Et bien sur fondamentalement incapable de rendre n'importe quoi à l'heure, ni de rendre quelque chose si ce n'est pas parfait, à moins de me faire violence, ou de n'avoir d'autre choix :mrgreen:
Tout le contraire de moi dans la vie "normale", je met le bazar partout ou je passe :aie:
Quand à la catégorie 5, c'est exactement ça... Je passe plus de temps à réfléchir comment faire plutôt que de le faire vraiment...
Si on me laisse faire, je re-cré à chaque projet un nouveau "framework" de travail, ultra-générique avec des hacks dans tous les sens (au sens : code non-documenté qui, si on le supprime, empêche le fonctionnement), portable toussa toussa.
Bref un truc qui permettra de coder à l'avenir de manière plus performante, et plus rapide :aie:, chose qui prend bien sûr 300 fois le temps de développement du projet... :).
Je crois que je suis relativement "lourd" pour les gens qui travaillent avec moi :D
Et je suis aussi d'accord avec la manière dont il sépare les "bons" développeur des "mauvais", mais je pense que celà peut s'appliquer de manière plus générique :
- Il y a ceux qui ont envie d'apprendre, qui sont curieux, qui cherchent à savoir le pourquoi du comment, cherchent à résoudre eux-même les choses.
- Et il y a ceux qui se contentent de vivre sur leurs aquis, ne se posent pas de questions, et qui estiment qu'ils "savent" des choses et que c'est bien suffisant comme ça.
Je pense que ça se retrouve dans la vraie vie. En gros ya les Hackers et les Autres... :mrgreen:
Mais c'est plus un état d'esprit concernant un domaine, plutôt qu'une aptitude naturelle.
Je pense qu'un "jeune" développeur, curieux, touche à tout, qui expérimente (càd : essaye d'inventer des solutions à ses problèmes de manière intelligente) etc... sera toujours meilleur en un sens que quelqu'un qui à apris la norme et qui se contente de l'appliquer, ou que quelqu'un qui se contente de dire :
(je déteste les gens comme ça :aie:)Citation:
Regarde, si je divise par 2 c'est trop petit, alors je vais diviser par 1.5 parcequ'on sera plus proche du résultat attendu...
Moi je suis souvent de ceux qui doivent reprendre le code de quelqu'un d'autre...
Donc forcément, je suis extrêmement anti hacks ou cheats, de code "bordel"!! J'insulte haineusement ces programmeurs environ 20 fois dans la journée pour me faire perdre (à moi, à mes collègues et à tout le monde) des centaines d'heures... Eux qui ont crû économiser quelques petites heures à engendrer un code bordélique et ultra crade plutôt qu'un code un minimum propre...
Je ne suis pas un perfectionniste pour autant, je fais en sorte de rendre mon travail à l'heure, je fais des compromis... Mais avec un code un tant soit peu propre et réutilisable avec si possible aucun hack ! (et si il y en a un, je le documente à mort).
Bref, je ne sais pas ce qu'est un "vrai" développeur, mais selon mon humble avis, un mauvais développeur est un développeur qui code sans réfléchir.
(Et on peut coder "directement" dans un projet sans pour autant que ça soit irréfléchi. Simple exemple : en s'inspirant d'une méthode agile. Mais des classes bordéliques et fourre-tout remplies de hack en tout genre... Le cauchemars!!)
ps: lors d'une mise à jour d'un article (comme c'est le cas ici), y a-t-il moyen de mettre un lien qui va directement au post de mise à jour sur son fil de discussion forum? S'il y en a un, je n'arrive jamais à le trouver (alors qu'avant, il était souvent dans le texte même de la mise à jour de l'article). merci ^^
on se connait? :aie:Citation:
Envoyé par cs_ntd