Franchement, préférez-vous le codage Cowboy? [fermé]

66

La plupart des programmeurs défendant des méthodologies politiquement correctes comme Agile, Waterfall, RUP, etc. Certains suivent la méthodologie, mais pas toutes. Franchement, si vous pouvez choisir la méthodologie, vous irez certainement dans les méthodes classiques "correctes" ou préférez-vous la méthode "plus facile" comme celle des cow-boys? Pourquoi?

Je sais que ça dépend. S'il vous plaît, expliquez quand vous utiliseriez l'un ou l'autre. S'il vous plaît, dites quels avantages voyez-vous sur le codage Cowboy.

Voir à propos du codage Cowboy sur Wikipedia

Maniero
la source
13
Une expérience a été réalisée une fois avec deux groupes de personnes à qui il a été demandé de fabriquer des pots en argile dans un délai déterminé. On a dit au groupe 1 de faire le pot de la plus haute qualité possible, au groupe 2 qu’ils seraient mesurés en fonction du poids de tous les pots produits. La qualité des pots finaux du groupe 2 était supérieure à celle des pots du groupe 1. Hélas, je n'ai pas pu trouver la source originale de cette expérience, mais le point primordial est "plus le nombre d'itérations est élevé, meilleure est la qualité". Le groupe 2 était-il des cow-boys? Probablement.
Adolf ail
3
"Cowboy coding" un choix de mots épouvantable si rien d'autre. Lorsqu'il est utilisé pour désigner les membres d'une équipe, "cow-boy" signifie souvent "la personne qui fait juste sa propre chose et se fiche de ce que cela signifie pour le reste de l'équipe". Mais la question de la valeur "moins de structure" est bonne.
MIA
4
Je pense que vous devriez énoncer (directement) votre définition de la programmation cow-boy dans votre question, car la page wikipedia et les répondeurs semblent mitigés sur ce qui est vraiment le codage cow-boy. Voulez-vous simplement dire de ne pas utiliser de méthodologie? Parce que beaucoup de gens semblent penser que le codage des cow-boys ne fait pas du tout de design. Au moins pour moi, cela signifiait simplement pas de processus formel - pas que vous sautiez immédiatement au codage. Je pense que puisque c'est vous qui posez la question, vous devez la définir en fonction de ce que vous voulez savoir.
n1ckp 10/10
@ n1ck: Merci. Certaines personnes ne font que sauter dans les réponses sans comprendre la question. Il est trop tard maintenant, changer cela annulerait certaines réponses. Malheureusement, certains utilisateurs n'ont pas compris la question. Tu l'as eu.
Maniero 10/10
Cette personne n'utilise-t-elle aucun type de système de contrôle de source ou refuse-t-elle simplement d'utiliser l'entreprise?
Thomas

Réponses:

202

Je pense que presque tous les programmeurs expérimentés sont passés par trois étapes et certains par quatre:

  1. Les codeurs ou les pépites Cowboy ne connaissent pratiquement rien du design et le considèrent comme une formalité inutile. Si vous travaillez sur de petits projets pour des parties prenantes non techniques, cette attitude peut leur être utile pendant un certain temps. ça fait des choses, ça impressionne le patron, fait en sorte que le programmeur se sente bien et confirme l'idée qu'il sait ce qu'il fait (même s'il ne le sait pas).

  2. Architecture Les astronautes ont été témoins des échecs de leurs premiers projets de pelote de fil pour s'adapter à l'évolution des circonstances. Tout doit être réécrit et pour éviter le besoin d' une autre réécriture à l'avenir, ils créent des plates - formes internes et finissent par consacrer 4 heures par jour au support technique, car personne d'autre ne comprend comment les utiliser correctement.

  3. Les quasi-ingénieurs se prennent souvent pour des ingénieurs qualifiés et formés, car ils sont véritablement compétents et comprennent certains principes d'ingénierie. Ils connaissent les concepts techniques et commerciaux sous-jacents: risque, ROI, UX, performances, maintenabilité, etc. Ces personnes considèrent la conception et la documentation comme un continuum et sont généralement en mesure d'adapter le niveau d'architecture / conception aux exigences du projet.

    À ce stade, beaucoup tombent amoureux de méthodologies, que ce soit agile, cascade, RUP, etc. Ils commencent à croire en l'infaillibilité absolue et même la nécessité de ces méthodes sans se rendre compte que dans le réel domaine de l' ingénierie du logiciel, ils sont simplement des outils , pas les religions. Et malheureusement, cela les empêche d’atteindre la dernière étape, à savoir:

  4. Les programmeurs de rubans adhésifs AKA Gourous ou des consultants bien rémunérés savent quelle architecture et quelle conception ils vont utiliser dans les cinq minutes qui suivent les exigences du projet. Tout le travail d’architecture et de conception est toujours en cours, mais c’est à un niveau intuitif et tellement rapide qu’un observateur non formé l’aurait confondu avec le codage cowboy - et beaucoup le font .

    Généralement, ces personnes ont toutes pour objectif de créer un produit "assez bon" et leurs travaux sont peut-être un peu sous-développés, mais ils sont à des kilomètres du code spaghetti produit par les codeurs de cow-boys. Les pépites ne peuvent même pas identifier ces personnes quand elles en parlent , car pour elles tout ce qui se passe en arrière-plan n'existe tout simplement pas.

Certains d’entre vous penseront probablement à ce stade que je n’ai pas répondu à la question. C'est parce que la question elle-même est imparfaite. Le codage Cowboy n'est pas un choix , c'est un niveau de compétence , et vous ne pouvez pas choisir d'être un codeur cowboy, pas plus que vous ne pouvez choisir d'être illettré.

Si vous êtes un codeur cow-boy, vous ne connaissez pas d'autre moyen.

Si vous êtes devenu un astronaute en architecture, vous êtes physiquement et psychologiquement incapable de produire des logiciels sans conception.

Si vous êtes un quasi-ingénieur (ou un ingénieur professionnel), alors terminer un projet avec peu ou pas d'effort de conception initial est un choix conscient (généralement dû à des délais absurdes) qui doit être mis en balance avec les risques évidents et entrepris. seulement après que les parties prenantes les ont acceptées (généralement par écrit).

Et si vous êtes un programmeur de gaines adhésives, il n’ya aucune raison de «code cow-boy», car vous pouvez créer un produit de qualité aussi rapidement.

Personne ne "préfère" le codage cowboy par rapport à d'autres méthodologies, car ce n'est pas une méthodologie. C'est l'équivalent en matière de développement logiciel de la création de boutons dans un jeu vidéo. Ce n'est pas grave pour les niveaux débutants, mais quiconque a dépassé ce stade ne le fera tout simplement pas. Ils pourraient faire quelque chose qui semble similaire mais ce ne sera pas la même chose.

Aaronaught
la source
27
Magnifiquement articulé.
Brandon
4
+1 pour une bonne contribution malgré la contradiction. Vous avez dit qu'un quasi-ingénieur fait un choix conscient lorsqu'il le faut. Plusieurs fois, les programmeurs expérimentés ayant des connaissances doivent choisir d'enfreindre les règles qu'il connaît et croit en raison de certaines contraintes. Bien sûr, si un programmeur est très bon et rapide dans son travail, il n'a pas besoin de choisir, mais peu de professionnels ont cette qualité. Quoi qu'il en soit, la question est provocante.
Maniero
14
Le problème est que trop de gens veulent être programmeurs de ruban adhésif sans être d'abord des astronautes d'architecture puis des quasi-ingénieurs, ce qui signifie qu'ils sont toujours des cow-boys. Donc, je pense pouvoir pointer cette liste et dire "cela ressemble à une progression de carrière" ... dommage que les types de direction pensent que les AA sont le summum.
MIA
19
Je ne sais même pas où je suis sur cette liste: S Parfois, je peux entendre parler d'un projet et savoir instantanément comment je vais le construire, par exemple 4, puis je vais subir une analyse sérieuse, une paralysie et une réflexion sur l'architecture, Comme 2alors, je considère YAGNI et réfléchis à la valeur commerciale et essaie d’être pragmatique, et je me sens comme un 3, puis je finis par faire un gâchis comme un 1.
Carson Myers
14
Je devrais vous donner -1 pour impliquer qu'un consultant hautement payé est au niveau de compétence de programmeur de ruban adhésif (indice: la plupart d'entre eux ne le sont pas, pas même proches). Mais je vous ai donné +1 quand même.
Falcon
47

Oui.

Je préfère aussi laisser mes chaussettes sur le sol où je les ai enlevées, mon bureau couvert d'imprimés et de vieux emballages de collations, mon évier plein de vaisselle sale et mon lit non fait.

Je ne considère pas que des vacances planifiées à l’avance soient des vacances convenables, un repas mangé dans l’esprit de la nutrition, une nourriture adéquate, ou restant sur des sentiers connus propices à la randonnée.

J'aime m'amuser, être surpris, apprendre de nouvelles choses, faire des erreurs et ne jamais être sûr de mon retour. Et parfois, cette attitude est exactement ce qui est nécessaire pour faire démarrer un projet ...

... mais la plupart du temps, c'est tout simplement irresponsable. Quand la danse se terminera, le joueur de cornemuse sera payé ... Oubliez cela à vos risques et périls.

Shog9
la source
J'ai des problèmes avec +1 pour "les vieilles emballages de collations, mon évier plein de vaisselle sale et [le plus important] mon lit défait." Que diable, +1 parce que le frisson du codage des cow-boys et l'inconfort de ne pas savoir si vous pouvez le récupérer est trop stimulant pour vous faire perdre du temps avec un langage UML, un design et des spécifications stupides. Ils écrivent leurs spécifications à partir de mon implémentation, JAMAIS l'inverse. :: sarcasme
Chris
31

Vous avez tout à fait raison. Cette approche de "programmation cow-boy" peut permettre d’obtenir la première révision du code plus rapidement, mais cette économie de temps sera plus que perdue grâce à:

  • Bugs supplémentaires
  • Temps supplémentaire nécessaire pour trouver les bugs que vous auriez eu de toute façon
  • Devoir désosser votre code pour se souvenir de ce que vous avez fait lorsque vous devez effectuer un changement en six mois
  • Temps supplémentaire consacré à la formation de développeurs supplémentaires devant travailler sur votre code
  • Ne pas avoir un journal des révisions à regarder en arrière lorsque vous effectuez un changement qui casse quelque chose
  • Ne pas avoir de modules, vous pouvez facilement les réutiliser dans des projets ultérieurs
  • et ainsi de suite

Comme Neil Butterworth l'a mentionné dans sa réponse, vous devez parfois faire ce que vous devez faire. En règle générale, non, casser le code le plus rapidement possible sans perdre de temps sur le contrôle du code source, les patterns, la documentation, etc. est une très mauvaise habitude.

Bon pour vous d’analyser vos collègues et de déterminer si leurs habitudes sont bénéfiques ou néfastes au lieu de le faire aveuglément.

Warren Pena
la source
6
Il y a toujours des exceptions. Certains codeurs pourraient être des génies, avoir une mémoire photographique mais peu de patience. D'autres ne sont pas si rapides mais persistants; ils écrasent la tâche, un octet à la fois, jusqu'à ce que cela devienne leur chienne. Il y a beaucoup de façons d'être un bon programmeur. La programmation de cow-boy fonctionne peut-être pour elle. Cela pourrait ne pas fonctionner pour le demandeur ou pour beaucoup d'autres. Cependant, pourquoi prescrire COMMENT quelqu'un devrait travailler, alors que l'important est le taux et la qualité des résultats. Pourquoi adopter une loi interdisant les moteurs 12 cylindres, alors que vous pouvez simplement récompenser les MPM plus élevés au moyen d’un crédit d’impôt?
Job
@Job: Je suis d'accord. Tout le monde a un processus différent; ce processus ne réussit pas couramment mais peut l'être. Pour ma part, je suis un utilisateur notoire de l' algorithme de Feynman et je fais l'étape 3 aussi rapidement que possible pendant que je suis toujours dans la zone.
Jon Purdy
3
@Job - Il y a parfois des exceptions. Les pourcentages finiront par prendre le relais. Il peut y avoir des exceptions lorsqu'il est évalué indépendamment du code parfait (pas d'erreurs, pas de problèmes, etc.), mais les habitudes des codeurs de cow-boy finiront par frapper de plein fouet son entreprise (et son équipe). Vous pouvez gagner à la roulette russe cinq fois de suite, mais continuez à jouer et mon argent est en jeu.
Thomas
2
@Job: Oui, je suis plutôt d'accord, jusqu'à un certain point. Mais refuser d’envisager autre chose (qui = refuser d’apprendre) et refuser d’utiliser le contrôle de la source sont deux grands drapeaux rouges qui me disent: Peut-être vite, mais un vrai boohead dangereux.
Rapidement maintenant
1
Suivre un processus formel n'est pas le seul moyen d'écrire un code qualité et ne garantit pas pour autant un code qualité. Avoir un processus formel est moins important si le travail d'une personne est "vaguement lié" avec le travail d'autres personnes. Le contrôle de version devient plus important si le processus devient plus informel. Sur le "refus d'apprendre" - combien de mauvaises expériences cette personne a-t-elle eues avec de mauvais processus et de mauvais systèmes dans le passé? L'inférence est imparfaite, mais c'est fondamentalement le seul moyen de comprendre tout ce qui ne
relève
29

Cela revient vraiment à la question de savoir si vous pouvez mettre en œuvre les choses correctement sans une structure serrée en place et beaucoup de temps consommé dans la planification.

Je vais lancer ici quelque chose de très impopulaire: les clients veulent généralement que les choses soient gérées de manière cow-boy .

C'est-à-dire qu'ils veulent que quelque chose soit fait et que quelqu'un le fasse, l'exécute et le diffuse. Pas de gestion de projet, de réunions, de téléconférences ni de formulaires. Simplement fais-le. Je n'ai jamais demandé à un client de dire "hé, cela a été fait un peu trop vite pour nos goûts, nous vous serions reconnaissants de mettre une petite cascade ou un autre objet à l'intérieur la prochaine fois".

Les méthodologies et la structure des équipes sont conçues pour niveler le terrain de jeu d'un projet et amener différents niveaux de développeurs sur la même page, travaillant pour les mêmes objectifs, de la même manière.

Les "cow-boys" à succès avec lesquels j'ai travaillé sont capables de:

  • Identifier le moyen le plus simple d'implémenter quelque chose rapidement
  • Savoir à quel moment ça va casser
  • Écrivez un code propre, lisible et simple
  • Prédire comment les utilisateurs vont l'utiliser, en abuser et le casser
  • Faites-le à l’échelle / abstenez-vous aux bons endroits, et n’allez pas sur l’astronaute de l’architecture
  • Savoir où et comment gérer les cas extrêmes et les exceptions

Les personnes comme celle-ci produisent de très bons résultats avec très peu de frais de gestion et de structure, mais ils sont rares.

Brandon
la source
9
Je n'appellerais vraiment pas votre liste finale du code "cowboy". Cela ressemble plus au "programmeur de ruban adhésif" par excellence glorifié par Spolsky. La différence est qu'un codeur cow-boy commence simplement à assembler du code sans se soucier de la conception générale; le « programmeur du ruban adhésif » sorte de fait comme il va de pair, mais a un plan; il fait juste la plupart des travaux de conception à un niveau intuitif (et parfois itératif).
Aaronaught
3
Les clients ne veulent pas forcément du style cow-boy, ils le veulent simplement, rapide et pas cher. Il nous appartient ensuite de livrer.
@ user1249: Cela me rappelle le triangle de la gestion de projet: pas cher, rapide, bon - choisissez-en deux.
DanMan
L’hypothèse selon laquelle les clients sont l’autorité professionnelle est risible. Bien sûr, je veux que les choses soient manipulées à la manière d'un cow-boy, c'est pourquoi je veux que ma voiture soit construite vite et sale, ma maison soit construite par de nouveaux arrivants qui peuvent simplement coller du ciment comme un mur, et ma nourriture devrait être préparée par ceux qui ignorent les risques pour la santé au profit de ma consommation plus tôt ...
Henry Aloni
13

EDIT: Pour référence future, ma réponse est pour une autre question, qui a été fusionnée dans celle-ci. C'est tout à fait hors de propos ici, mais ce n'était pas mon appel.


Elle est juste paresseuse, arrogante, ignorante et extrêmement égoïste. Ce comportement est imprudent.

Je veux dire, ce n’est pas qu’elle utilise une méthodologie non conventionnelle ou peut-être dépassée. Elle utilise consciemment aucun . Pas de normes. Pas d'assurance qualité. Pas du tout. D'où attend-elle la qualité logicielle? Des arbres?
C'est drôle, elle nie en fait l'expérience des personnes que vous citez, alors qu'elle en manque visiblement. Fournir des arguments vérifiables et pertinents pour mettre en doute leurs revendications est valide. Mais essayer de les discréditer en niant leur expérience ne l’est pas.

Mais l'essentiel est: combien de temps prend le contrôle de version?
Si elle ne peut pas être convaincue d'investir les 5 secondes de temps en temps, vous devriez en parler à son patron. Le contrôle de version n'est pas facultatif. Arrêt complet.

Et une fois que vous l'utilisez avec le contrôle de version, vous pouvez facilement suivre les bogues qu'elle a introduits. Et laissez- la les réparer. C'est son bordel, pourquoi devriez-vous le nettoyer? Si elle pense que son approche est meilleure, alors laissez-la faire - jusqu'au bout .
En supposant qu'elle puisse le faire (dans un délai raisonnable), vous avez toujours un problème: le travail d'équipe avec elle est presque impossible. Et c'est quelque chose que vous devrez résoudre en la convainquant (ce qui semble peu probable), en la faisant partir (pour le bien de votre entreprise) ou en le laissant (pour le souci de votre santé mentale).
Mais son échec en premier lieu est beaucoup plus probable et devrait prouver votre point de vue. Et ensuite, elle commencera à adhérer aux meilleures pratiques, comme le font beaucoup de personnes ayant beaucoup d'expérience.

back2dos
la source
2
Parfois, la vérité fait mal tout simplement ...
ChaosPandion
+1 pour avoir dit que le travail d'équipe avec des personnes aussi égoïstes est impossible. Même s’ils sont des génies, les cow-boys ne sont pas des joueurs d’équipe; ils sont le spectacle principal et nous sommes le groupe de soutien
Mawg le
11

Cela dépend complètement si je travaille en solo ou en équipe.

Si je travaille en équipe, certaines conventions et accords sont nécessaires - chaque membre de l’équipe doit respecter certaines normes communes pour travailler dans le but commun, afin que ses efforts soient compatibles.

Mais si je travaille seul, alors bien sûr, je veux être un cow-boy. Toutes les grandes créations du monde ont été inventées par un seul esprit, ou au plus deux, à la manière de cow-boy. Juste pour en nommer quelques-uns:

  • Mécanique classique? Cowboy Isaac Newton, ajouts ultérieurs de Leibniz, Lagrange, Hamilton.
  • Avion? Cowboys Wright.
  • Théorie de la relativité? Cowboy Albert Einstein.
  • Science fondamentale de l'informatique? Cowboy Alan Turing.
  • Transistor? Cowboys Walter Brattain et John Bardeen.

Les équipes sont douées pour apporter des améliorations progressives et pour assembler rapidement de nouveaux systèmes basés sur des recettes éprouvées (à condition d'être bien pilotées), mais il est rare d'entendre parler d'une invention réelle réalisée par une équipe. Le travail d'équipe et les méthodes qu'il requiert ont leurs vertus, mais le codage des cow-boys l'est aussi.

Joonas Pulakka
la source
Je remarque que vous avez mentionné des succès célèbres dans le domaine des cow-boys, tout en faisant abstraction des échecs beaucoup plus nombreux.
Mawg
7

Cela dépend du problème. Un bon développeur senior rédigera un code très compact, simple et robuste, très stable et appliquant toutes les meilleures pratiques, sans passer par des pages de documentation et des tonnes de modèles et de paradigmes différents. Mais il saura aussi quand il aura les moyens de faire de telles choses.

Je serais choqué s'il prend un nouveau problème et commence à concevoir une application qui nécessite des mois-homme à partir de zéro. Mais si c'est un plugin, un outil simple que vous pouvez écrire en 2 heures, une fonction qui effectue une conversion et n'est pas destinée à une réutilisation, la conception et les modèles ne sont en fait que bons pour perdre du temps.

De plus, je suppose qu'une grande partie de la conception a déjà été traitée dans un fil de fond quelque part dans la tête des développeurs expérimentés.

Vous devez commencer à vous inquiéter lorsque le développeur principal commence à créer des classes d'un système complexe ou de nouvelles applications en partant de zéro, sans étape de planification.

Codeur
la source
9
votre réponse omet complètement la partie la plus éloquente de la question "J'ai un programmeur qui code rapidement en rejetant le contrôle de révision ...". Quiconque révoque le contrôle de révision et promeut cette opinion auprès des employés subalternes est criminel.
1
@Jarrod: ou pas. Il est inutile de s’engager dans un code incomplet / dysfonctionnel.
Denis de Bernardy
1
@ Denis - c'est principalement à quoi sert une branche. L’historique des décisions, modifications, erreurs, impasses, etc. au cours de l’élaboration d’un code incomplet / défectueux fait de l’OMI une partie de la documentation de ce code, et est très important pendant la maintenance. Une ramification et une fusion simplifiées sont une bonne raison de remplacer Subversion par un VCS distribué.
Steve314
@steve: Cela supposerait que vous examiniez les journaux avant de modifier une ligne de code. Très franchement, je connais très peu de codeurs qui le savent réellement ... Et même alors (comme je le fais ...), ils sont beaucoup moins intéressés par la raison pour laquelle ceci / cela a été commis que par la raison pour laquelle cela a été changé à partir du code d'origine.
Denis de Bernardy
@steve: Pour les fonctions simples, il est plus facile d'utiliser un seul commit avec le commentaire "Fonction ajoutée qui calcule les paramètres d'accélération", plutôt que d'avoir des coomitations: "Squelette PaternX", "Ajout de la première ligne de code", "Correction d'un bug", "Correction d'un autre punaise". Il est plus facile de suivre les modifications globales du projet s'il y a moins de commissions "de bruit". Et il y a des étagères qui peuvent être utilisées pour du code incomplet pour éviter la perte de données.
Codeur
6

Cela dépend des circonstances. Par exemple, après des scandales commerciaux désastreux, plusieurs bourses électroniques ont insisté pour que des drapeaux de négociation automatique soient ajoutés à toutes les transactions. Et cela devait être pour tous les logiciels de trading en une semaine. Je veux dire que cela devait être fait - si le drapeau n'était pas là, vous ne pourriez pas échanger. Dans de telles circonstances, toutes les bonnes pratiques sont respectées par le conseil d’administration - il suffit d’y aller (comme on disait): "hacky, hacky, hacky". Et dans ces circonstances, l'écriture de code rapide et précise est la clé. D'autant qu'il n'y avait pas de systèmes de test disponibles.

Neil Butterworth
la source
Comment utilise-t-on votre PORCIN? Quel est le langage pour décrire les dialogues?
Job
@ Job Ce n'est pas encore prêt.
Neil Butterworth
votre réponse omet complètement la partie la plus révélatrice de la question "J'ai un programmeur qui code rapidement en rejetant le contrôle de révision ..." Je suis presque sûr que votre exemple, il n'a pas
@Jarrod Contrôle de version. Eh bien, nous avons eu des rcs. Gestion des versions? C'était une banque d'investissement! Vous poussez des choses à la porte aussi vite que vous les écrivez.
Neil Butterworth
Nous saluons le retour.
P Shved
5

D'après mon expérience, le codage cow-boy AVEC contrôle de source est le meilleur moyen, sans aucun bug, de développer de grands systèmes logiciels.

jojo
la source
2
Au prix de créer une grosse boule de boue (ma propre réponse ;-))
Denis de Bernardy
4

Je pense que l’un des commentateurs a eu raison - tout est dans les résultats.

Si la personne peut produire un bon produit - quelque chose qui fait ce qu’elle est censée faire, qui est maintenable et fiable - alors qu’importe que les méthodes ou les processus formels soient suivis? Les processus sont parfaits pour garantir la qualité d'un sol, mais si quelqu'un travaille déjà au-dessus de ce sol, les processus n'ajoutent rien à l'équation. De nos jours, trop de développeurs semblent penser que l’ intérêt de la programmation est d’adhérer aux processus, et non de produire un bon produit.

Grand maître b
la source
4

Ce genre de personne s'appelle un hacker, et ce n'est généralement pas un terme complémentaire des plus professionnels parmi nous.

Comme vous l'avez remarqué, le temps mis sur le design, l'organisation et le contrôle est perdu. Et souvent pour trouver quelle version du code était celle qui avait été réellement expédiée. Si vous pouvez le trouver du tout!

Je trouve que ce genre de personne est trop enracinée dans elle-même, pense qu'elle est trop bonne pour travailler avec les «limitations» que d'autres doivent souffrir et ne vous en faites donc pas, et cela perd encore plus de temps que le reste de la l'équipe doit nettoyer après eux. Ils ne sont pas non plus trop impliqués dans le processus de résolution des bugs (tâche du développeur de maintenance, bien en deçà des compétences et du talent du codeur de l33t).

Donc, cela pourrait être une approche commune ailleurs, mais chez moi (et je suis un codeur senior qui a des tendances dans ce sens, heu), nous ne le subissons pas. Ce n’est pas que nous demandions une tonne de processus et de procédures, mais nous insistons sur une organisation minimale, le contrôle du code source (qui pour être honnête est sanglant et extrêmement utile!)

Kent Beck et al. Sont tous des professionnels qui ont vu que les méthodes traditionnelles chargées de processus étaient mauvaises en eux-mêmes. Ils ont donc créé de nouvelles méthodologies pour organiser le codage tout en le gardant plus orienté vers l’artisanat, puis en ont parlé à tous les autres - en publiant des livres ( Comment avez-vous pu le faire avant Internet?)

Vous semblez avoir raison - n'acceptez pas une mauvaise pratique simplement parce que quelqu'un d'autre ne peut pas la pirater. Votre chef d’équipe ou votre responsable d’équipe devrait avoir du mal à se lancer dans cette «rockstar», mais s’ils ne le sont pas… eh bien, cela ne vous empêche pas encore de faire ce qui est bien. N'acceptez tout simplement pas la pratique de mauvaise qualité de sa part, si elle se trompe (et elle le fera!), Alors laissez-la nettoyer. Vous vous en tenez aux bonnes pratiques (et vous savez ce qu’elles sont) sans les laisser prendre le dessus sur votre productivité de codage, et vous serez optimiste pour l’avenir.

Voici un essai d'un écrivain vraiment perspicace. Cela ne résout pas votre problème, mais il vous donne quelques indications sur la raison pour laquelle c'est comme ça et peut-être quelques astuces pour le gérer de manière professionnelle.

gbjbaanb
la source
+1 Il est regrettable que «pirate informatique» ait changé pour signifier cela. Une brève histoire du hackerdom
Gyan, alias Gary Buyn, le
4
Je dirais "pirater" au lieu de "pirate".
Mike Sherrill 'Cat Recall' le
2
Ce sont des cow-boys, comme l’a déclaré le PO, ne vous embrouillez pas comme un pirate informatique. Laissez cela aux médias.
octobre
ça pourrait être un programmeur "rock star" ... trop plein d'ego et de talent pour s'inquiéter des "petites choses". Maintenant, où est ma baignoire pleine de m & m bleu?! Je le veux maintenant!
gbjbaanb
3

Le seul fait important concerne les résultats à long terme de l'équipe.

On prétend qu'une équipe comprenant un grand programmeur (ou plus) produira de meilleurs résultats qu'une équipe avec un nombre encore plus grand de programmeurs moyens codant à un débit moyen.

Si le cow-boy produit des choses que les programmeurs habituels ne produisent pas (pour une date ou une date donnée), et que l’équipe avec le cow-boy doit même passer quelques semaines / mois à nettoyer le gâchis du cow-boy, ils pourraient tout de même se retrouver avec le meilleur résultat plus tôt.

Si l'équipe avec le cow-boy ne peut pas nettoyer (documenter, déboguer, intégrer, entretenir) le désordre même après plusieurs mois / année de travail, alors quelle que soit l'avancée créée par le cow-boy, elle ne lui confère pas un avantage à long terme.

Décidez lequel et optimisez l’alignement de l’équipe.

Tous les programmeurs ne travaillent pas (ou ne devraient pas fonctionner) de la même manière, tant que le résultat final est bon.

hotpaw2
la source
4
On prétend qu'une équipe comprenant un grand programmeur (ou plus) produira de meilleurs résultats qu'une équipe avec un nombre encore plus grand de programmeurs moyens codant à une vitesse moyenne - jusqu'à ce que le grand programmeur quitte et prenne sa selle, son cheval et son votre code avec eux. Quelle est la qualité de ces résultats alors?
Thomas
L'hypothèse n'est pas nécessairement correcte. Respecter la date limite d'une conférence ou d'un autre spectacle de votre produit peut également être extrêmement important.
1
@Thomas: Les facteurs de risque vont dans les deux sens. Le type qui finance tous les chèques de paie pourrait ne pas participer au prochain tour de financement quand même une preuve de concept piratée ne paraît pas assez tôt. Quelle est la qualité de vos chevaux lents maintenant? Tous les choix d'ingénierie sont des paris. Placez vos frites.
hotpaw2
@ hotpaw2 - Le pari est de savoir si les coûts (potentiellement terminaux) du codage des cow-boys vont frapper avant que vous puissiez obtenir votre financement. En général, mon pari est contre le codage des cow-boys (et que cela prendra plus de temps). Oh, tu pourrais me battre 1/10 fois ou même 1/5. Mais au total, année après année, au fur et à mesure que les chances s’accumulent, les codeurs cow-boys vous coûteront plus que votre gain.
Thomas
1
@ Thorbjørn Ravn Andersen, @ hotpaw2 - Il y a une autre dynamique en jeu ici. Un codeur qui est prêt à utiliser des techniques à risque, même lorsque ces risques sont inutiles, s’il n’est pas activement appliqué, va en général faire des choix plus risqués ailleurs. En d'autres termes, leur choix contre le contrôle à la source est révélateur d'un comportement plus risqué qui finira par les mordre, eux et leur entreprise. Même dans un jeu de hasard, vous pouvez parfois battre la maison, mais les pourcentages finissent par vous battre.
Thomas
3

Vous pourriez trouver un aperçu de ma réponse à Franchement, préférez-vous le codage par cow-boy? Le problème, c'est que "coder par un cow-boy" signifie différentes choses pour différentes personnes, et ce n'est pas immédiatement évident pour l'œil non averti, quelle version vous voyez.

Lorsque quelqu'un peut examiner un problème et commencer immédiatement à produire du code, rapidement et avec précision, cela peut être le signe d'un ingénieur qui a tout vu auparavant et sait déjà quel est le meilleur moyen de résoudre le problème.

Ou, cela peut être le signe d'un amateur de rang.

Je vais vous dire une chose: refuser d’utiliser le contrôle de version ou d’écrire des tests parce qu’ils sont trop «académiques» n’est définitivement pas une approche «senior» ni même à distance professionnelle. Vous ne verrez jamais ce genre de chose se faire dans un grand magasin de logiciels tel que Microsoft ou Google, et probablement pas dans la plupart des startups ou des équipes d’entreprise raisonnablement mûres.

Les risques sont trop importants. Et si votre PC meurt du jour au lendemain? Au revoir 3 ans de productivité. Bon, alors vous faites des sauvegardes; alors que se passe-t-il lorsque vous effectuez un changement majeur, réalisez que c'était complètement faux et devez le revenir? Cela arrive même aux développeurs les plus expérimentés et les plus talentueux, car les exigences sont fausses. Si vous n’exécutez aucun type de contrôle de version, vous allez simplement vous perdre dans la boue. J'y suis allé une fois et je n'y retournerai jamais .

Il n'y a aucune excuse - il faut 10 minutes pour configurer un référentiel et 10 secondes pour effectuer un commit. Cela représente peut-être 1% de votre temps de développement total. Les tests, si vous êtes pressé, peuvent facilement être réduits à 20-30 minutes par jour tout en restant raisonnablement utiles.

Je ne suis pas fan des méthodologies Agile (remarquez la majuscule A), mais vous avez parfois vraiment besoin de vous retrousser les manches et de commencer à écrire ce foutu code. J'ai vu des personnes et des équipes avec une "paralysie d'analyse" et une productivité qui en prend un coup visible. Mais renoncer aux outils de base de notre métier, tels que le contrôle de révision et les tests, est vraiment le meilleur choix pour moi; cette personne n'occupe pas un poste de direction.

Aaronaught
la source
2

Oui, mais vous devez savoir quand NE PAS le faire.

Sur quelque chose de petit, vous allez probablement bien, mais si vous avez quelque chose de complexe, dangereux, contraint, etc., vous devez être capable de reconnaître quand une bonne conception vaut le temps supplémentaire.

Je pense aussi que vous devriez certainement réfléchir à la réponse d'Aaronaught. Cowboy signifie différentes choses pour différentes personnes.

Facture
la source
2

Quand je pense aux méthodologies "traditionnelles", je pense que "la direction ne sait pas comprendre les développeurs, alors au lieu d'entrer dans le monde des développeurs et suffisamment compréhensive pour savoir ce qui se passe, ils incitent les développeurs à entrer dans leur monde".

Fondamentalement, quand je pense à "Agile", je pense que "vous faites ce que vous devez faire pour minimiser les inefficiences introduites par plusieurs personnes travaillant ensemble". Je suis donc fermement dans le camp que « il n'y a pas une telle chose comme LA méthodologie Agile , juste un ensemble de valeurs et de principes ».

En d’autres termes, vous devez effectuer certaines tâches dans le cadre d’un très grand projet, de même que dans le cas de projets de petite envergure et dans les deux cas.

Par exemple, je n'aurais pas plus que l'arriéré le plus simple pour un projet sur lequel je travaille moi-même ... Ce serait simplement une liste de tâches à faire. Si nous sommes deux, je partagerais probablement cette liste, mais dans un format très simple (probablement juste une note stockée dans notre référentiel de code). Une fois que j'ai 3 ou 4, je cherche une sorte de système d'élément de travail.

MIA
la source
1

Seulement lors du prototypage de fonctionnalités très simples.

Puis, une fois terminé et considéré comme correct, je laisse tomber le code et deviens sérieux.

Klaim
la source
1

Je l'ai déjà fait sur un vrai projet (à l'époque, nous l'appelions Samurai Programming, d'après la série de sketches Samurai Tailor de Saturday Night Live), et à mon grand étonnement, cela a bien fonctionné. Bien sûr, ce que j'ai commencé avec était des déchets, donc il y avait peu de risque d'empirer les choses.

Cependant, je suis un "chou" dans l'âme et je n'aime pas le style de développement qui tire de la hanche.

D'autre part, le modus operandi très chargé de processus n'est pas à mon goût non plus. J'aime juste planifier avant d'agir.

Dans l’ensemble, j’estime que la quantité de processus formel appropriée dépend fortement de l’ampleur (taille du code, durée du projet, nombre de développeurs, types d’exigences, etc.) du projet. Je souhaite imposer des critères rigoureux et stricts aux personnes développant le logiciel pour avionique ou équipements biomédicaux, par exemple pour les jeux. Par exemple, les défaillances sont bien moins négatives. Le coût et la charge que représentent des pratiques de développement rigoureuses et méthodiques justifié.

Randall Schulz
la source
2
Vous devez souvent résoudre le problème afin de comprendre comment le résoudre ...
1

Cela dépend (fortement) de la taille du projet. D'une part, pour obtenir un résultat décent, vous devez avoir un design. D'autre part, si le projet est suffisamment petit pour que vous puissiez conceptualiser l'intégralité de la conception (le plus souvent de toute façon) sans l'écrire, dessiner des diagrammes, etc., alors vous êtes probablement aussi à l'aise sans ce travail supplémentaire de documenter tout ce que vous faites.

Presque tout le monde a entendu assez d'histoires d'horreur pour se rendre compte qu'essayer d'intervenir sans une idée claire de ce que vous faites et de ce qui se passe est une recette pour un désastre. Ce qui est beaucoup plus rarement souligné, c'est que le contraire peut être tout aussi désastreux. Par exemple, la plupart d’entre nous écrivons régulièrement de petits outils en cours de programmation. Écrire une spécification complète, des tests, de la documentation n’est souvent pas rentable. Il y a un seuil en dessous duquel la production n'est pas rentable - les gens n'aiment pas souvent réinventer la roue, mais dans certains cas, il est plus facile de réinventer que de l'éviter.

Dans les cas comme celui - ci, ce qui est souvent est la peine est productizing une bibliothèque pour faire des tâches comme facile. Avec cela, le code frontal devient souvent si trivial que l'écriture (ou la modification) de code pour faire ce que vous voulez devient plus facile que de trouver comment obtenir un programme complet pour faire ce que vous voulez. Considérez, par exemple, gnu indent avec ses 50 drapeaux différents, dont beaucoup interagissent de manière subtile, de sorte que les seuls choix raisonnables sont 1) ne l'utilisez pas du tout, ou 2) décidez d'aimer ce que cela vous donne. au lieu d'essayer d'obtenir ce que vous vouliez à l'origine.

Jerry Coffin
la source
1

Il semble y avoir deux camps: ceux qui favorisent les résultats et ceux qui favorisent les principes. Je tombe dans ce dernier.

Je suis un programmeur médiocre mais sans doute consciencieux - ma principale préoccupation lors de la programmation, au - delà de la réalisation du travail, c’est que j’aide celui qui utilise mon code à le faire. Je ne peux pas dire que j'ai toujours atteint cet objectif - mais c'est ce que je souhaite faire.

Bien sûr, vous pouvez avoir un membre du groupe dans votre équipe - mais que se passe-t-il quand ils prennent quelques semaines de congé et qu'on leur demande de déboguer leur travail ou d'y ajouter des éléments? En fin de compte, les programmeurs cow-boys ne sont pas des joueurs d’équipe. Ils peuvent faire du bon code, mais si l’équipe dépend d’eux, c’est dangereux.

Sunwukung
la source
Oui, et il est possible (probable?) Pour certains codeurs de cow-boys de livrer du code pas très bon.
Bernard Dy
1

J'ai le sentiment que votre aversion pour son style vous amène à le représenter légèrement. Vous dites que l'approche de cow-boy est payante en débogage - est-ce déjà ce qui se passe ou est-ce votre hypothèse de savoir comment cela va se dérouler?

Divulgation équitable - Je suis moi-même un développeur principal et je renonce souvent à un processus formel de conception et d'expérience. Le fait de ne pas avoir de processus formel pour une personne très expérimentée dans le domaine problématique est assez courant. Si vous avez résolu un problème des dizaines de fois, vous n'avez pas besoin d'un processus formel pour formuler à nouveau une solution similaire.

Un processus formel traite de la conception du code - je ne vois pas pourquoi il faudrait introduire plus de bogues, car il manque un processus formel. Le seul gros problème que j'ai lu dans votre compte est que le contrôle de révision n'est pas utilisé - ce qui est non seulement égoïste, mais carrément irresponsable pour le développeur. Est-ce qu'elle ne commet pas du tout, ou simplement, ne s'engage pas dans un modèle qui vous convienne?

Ne pas avoir une approche formelle de la conception n'est pas «codage cowboy» dans mon livre (ne pas utiliser le contrôle de révision est bien). L’expérience doit être utilisée exactement pour cela - réduire le temps nécessaire pour trouver une solution «assez bonne». N'oubliez pas que vous devez résoudre les problèmes que vous avez actuellement et rendre le code facile à modifier, pas à concevoir pour des scénarios futurs qui pourraient ne jamais se produire. Avec l'expérience, vous comprendrez comment le faire très rapidement.

Eran Galperin
la source
0

Non jamais.

Je fais toujours l’analyse des exigences, pense à l’architecture, conçois les détails, puis code. Même si je travaille seul à la maison pour un projet personnel.

Et je licencierais instantanément un développeur de mon équipe s’il / elle travaillait dans un style cow-boy. Nous sommes des ingénieurs et avons une responsabilité vis-à-vis du client et des utilisateurs.

CesarGon
la source
-1: Vous devez également agir dans le meilleur intérêt de quiconque écrit votre chèque de règlement.
Jim G.
@ Jim: J'écris le chèque de paie. C'est pourquoi j'ai le privilège de renvoyer les membres de l'équipe. Peut-être que votre vote négatif était un peu précipité. :-)
CesarGon
Nous sommes des ingénieurs et avons une responsabilité vis-à-vis du client et des utilisateurs. - Parfois, le client demande une date d'expédition rapide. Emphase: Parfois, la date d'expédition rapide n'est pas négociable.
Jim G.
@ Jim: Je le sais très bien, après avoir créé trois entreprises. Pourtant, pas de cow-boy codant jamais, merci beaucoup. Comme je l'ai dit, nous avons une responsabilité vis-à-vis du client et des utilisateurs, et j'ai toujours été en mesure de faire correspondre cet engagement à des pratiques d'ingénierie éprouvées et à l'absence de cow-boys.
CesarGon
0

Je ne pense pas que le codage des cow-boys soit une approche prioritaire.

Comme d’autres l’ont dit, il est très dangereux d’abandonner le contrôle de version. Ignorer la documentation et l’analyse peut également signifier le risque de livrer quelque chose que l’utilisateur ne veut pas. Juste mon avis, mais je ne pense pas que vous passiez de "codeur à développeur" si vous ne faites que du code cow-boy.

Cependant, oui, il existe des exceptions comme celle mentionnée par Neil Butterworth. Et dans ces situations, je préférerais qu'un développeur senior expérimenté soit celui qui doit coder les cow-boys.

Bernard Dy
la source
0

Je pense que les nouveaux programmeurs ont tendance à coder les cow-boys en prenant en charge des aspects d’un projet / de domaines qu’ils n’ont peut-être pas beaucoup d’expérience ou en essayant de "faire avancer les choses" sous la pression d’un patron, etc. Je sais que j’ai définitivement emprunté ce chemin à quelques reprises parce que je ne connaissais pas le bon modèle à utiliser et que je me suis juste "frayé un chemin à travers".

La différence entre moi et la personne dont vous vous plaignez, c’est que, peu après, je me rends vite compte que j’aurais pu le faire mieux et le rendre plus facile à maintenir. matière). Lorsque je reviens pour déboguer certaines de ces solutions piratées, je trouve généralement cela pénible et cela contribue davantage à mon désir d'apprendre à le faire de la "bonne façon". Je pense que la personne que vous décrivez est fondamentalement bloquée à un niveau de réflexion infantile infantile et qu'elle laisse son propre ego nuire à l'amélioration réelle de ses compétences en tant que développeur de logiciels, ne semble pas être une personne avec laquelle je voudrais travailler.

programmx10
la source
0

Je trouve votre post intéressant. J'ai souvent partagé des points de vue avec votre sujet, et elle a le sentiment que les méthodes trop formelles sont étouffantes. Comme quelqu'un l'a noté, si elle est un génie et qu'elle peut suivre une multitude de notes mentales en même temps sans oublier ni s'embrouiller, il est tout à fait possible de conserver un bloc monolithique de code compliqué et de le faire faire des choses étonnantes avec des changements complètement obscurs . Il y a un certain bonheur mental dans le cerveau des gens qui peuvent le faire - c'est comme être un dieu d'un petit univers dans votre esprit.

Cependant, les employeurs intelligents ont appris à leurs dépens que nul autre que l'auteur original ne peut faire quoi que ce soit d'intéressant avec ce code. Si le programmeur passe à autre chose, il finit par gaspiller beaucoup d’argent en s’apercevant que la seule option est de réécrire (jadis, je pensais que c’était une perte totale, mais je me rends compte aujourd’hui que vous ne détruisez pas le résultat intrinsèque de développement itératif au niveau de la fonctionnalité externe).

Personnellement, cela ne me dérangerait pas que quelqu'un comme ça fasse partie de l'équipe, car dans un moment critique, ils pourraient faire quelque chose que personne d'autre ne pense.

En revanche, soyez votre propre personne et décidez par vous-même quelle est la réponse à votre question, car la seule chose qui est sûre, c’est que personne ne le sait vraiment quand il s’agit de construire un logiciel. C'est l'une des choses qui en fait un domaine intéressant ...

Aaron Anodide
la source
Je suis d’accord, à moins que ce ne soit une solution ad-hoc qui n’a plus jamais besoin d’être retouché, il est important d’avoir une tendance, car il ne s’agit pas seulement de "faire marcher", il faudra que quelqu'un regarde "sous le capot" et donne un sens à it
programmx10