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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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é.

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.

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.

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.

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.

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.

La programmation de cow-boys est un moyen plutôt sûr de créer une grosse boule de boue . Ce qui, aussi désagréable que cela puisse paraître , a tendance à donner …

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.

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 ...