Franchement, préférez-vous le codage Cowboy?
La plupart des programmeurs défendant des méthodologies politiquement correctes comme Agile, Waterfall, RUP, etc. Certains d'entre eux suivent la méthodologie mais pas tous. Franchement, si vous pouvez choisir la méthodologie, vous iriez certainement vers des méthodologies "correctes" ou vous préféreriez la méthodologie "plus facile" comme la programmation cowboy? Pourquoi?
Je sais que ça dépend. Veuillez expliquer quand vous utiliseriez l'un ou l'autre. S'il vous plaît, dites quels avantages voyez-vous sur le codage Cowboy.
Voir à propos de Cowboy coding sur Wikipedia
Je pense que presque tous les programmeurs expérimentés ont traversé trois étapes et certains en ont franchi quatre:
Les codeurs Cowboy ou les pépites connaissent peu ou pas la conception et la 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; il fait avancer les choses, il impressionne le patron, fait que le programmeur se sente bien dans sa peau et confirme l'idée qu'il sait ce qu'il fait (même s'il ne le fait pas).
Architecture Les astronautes ont été témoins des échecs de leurs premiers projets de pelote de laine pour s'adapter aux circonstances changeantes. Tout doit être réécrit et pour éviter la nécessité de un autre réécrire à l'avenir, ils créent plates-formes internes, et finissent par passer 4 heures par jour sur le support car personne d'autre ne sait comment les utiliser correctement.
Les quasi-ingénieurs se confondent souvent avec réel, des ingénieurs formés car ils sont véritablement compétents et comprennent une certaine ingénierie des principes. Ils connaissent les concepts techniques et commerciaux sous-jacents: risque, retour sur investissement, expérience utilisateur, performances, maintenabilité, etc. Ces personnes voient la conception et la documentation comme un continuum et sont généralement capables d'adapter le niveau d'architecture/conception aux exigences du projet.
À ce stade, beaucoup tombent amoureux des méthodologies, qu'elles soient Agile, Waterfall, RUP, etc. Ils commencent à croire à l'infaillibilité absolue et même nécessité de ces méthodologies sans se rendre compte que dans le = actuel domaine du génie logiciel, ce ne sont que des outils, pas des religions. Et malheureusement, cela les empêche d'arriver à l'étape finale, qui est:
programmeurs de bande de conduit AKA gourous ou consultants hautement rémunérés savoir quelle architecture et conception ils vont utiliser dans les cinq minutes après avoir entendu les exigences du projet. Tout le travail d'architecture et de conception est toujours en cours, mais c'est à un niveau intuitif et si rapide qu'un observateur inexpérimenté le confondrait avec le codage cowboy - et beaucoup le font.
Généralement, ces gens sont tous sur la création d'un produit qui est "assez bon" et donc leurs œuvres peuvent être un peu sous-conçues, mais elles sont miles loin du code spaghetti produit par les codeurs cowboy. Les pépites ne peuvent même pas identifier ces personnes quand on les en parle, 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 plus que vous ne pouvez choisir d'être analphabète.
Si vous êtes un codeur de cow-boy, vous ne connaissez pas d'autre moyen.
Si vous êtes devenu astronaute d'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), la réalisation d'un projet avec peu ou pas d'effort de conception à l'avance est un choix conscient (généralement en raison de délais absurdes) qui doit être mis en balance avec les risques évidents et entrepris. seulement après que les parties prenantes ont donné leur accord (généralement par écrit).
Et si vous êtes un programmeur de ruban adhésif, alors il n'y a aucune raison de "coder cowboy" car vous pouvez créer un produit qualité tout aussi rapidement.
Personne ne "préfère" le codage de cowboy par rapport aux autres méthodologies car ce n'est pas une méthodologie. C'est l'équivalent de développement logiciel des boutons de purée dans un jeu vidéo. C'est OK pour les niveaux débutants, mais quiconque a dépassé cette étape 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 également 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 défait.
Je ne considère pas que des vacances planifiées à l'avance soient de vraies vacances, un repas mangé avec un esprit voué à la nutrition, une bonne alimentation ou un séjour sur des sentiers connus comme une bonne randonnée.
J'aime m'amuser, être surpris, apprendre de nouvelles choses, faire des erreurs et ne jamais être sûr de pouvoir y revenir. Et parfois, cette attitude est exactement ce qui est nécessaire pour lancer un projet ...
... mais la plupart du temps, c'est juste irresponsable. Lorsque la danse se termine, le joueur de cornemuse sera payé ... Oubliez cela à vos risques et périls.
Vous avez exactement raison. Cette approche de "programmation cowboy" peut permettre de sortir plus rapidement la première révision du code, mais ce gain de temps sera plus que perdu grâce à:
- Bogues supplémentaires
- Temps supplémentaire nécessaire pour trouver les bogues que vous auriez de toute façon
- Devoir faire de l'ingénierie inverse de votre code pour vous souvenir de ce que vous avez fait lorsque vous devez effectuer un changement dans six mois
- Temps supplémentaire consacré à la formation de développeurs supplémentaires qui doivent travailler sur votre code
- Ne pas avoir de journal des révisions à consulter lorsque vous apportez une modification qui casse quelque chose
- Ne pas avoir de modules que vous pouvez facilement réutiliser dans des projets ultérieurs
- Et ainsi de suite
Comme Neil Butterworth l'a mentionné dans sa réponse, parfois tu dois faire ce que tu dois faire. En règle générale, non, frapper le code aussi rapidement que possible sans passer de temps sur le contrôle du code source, les modèles, la documentation, etc. est une très mauvaise habitude.
Bon pour vous pour analyser vos collègues et déterminer si leurs habitudes sont bénéfiques ou nuisibles au lieu de faire aveuglément comme ils le font.
Cela se résume vraiment à la question de savoir si vous pouvez ou non mettre en œuvre les choses correctement sans une structure serrée en place et beaucoup de temps consommé dans la planification.
Je vais jeter quelque chose ici sur celui-ci qui peut être vraiment impopulaire: les clients veulent généralement que les choses soient traitées à la manière d'un cow-boy.
Autrement dit, ils veulent demander que quelque chose soit fait, et demander à quelqu'un de sauter dessus, de l'exécuter et de le diffuser. Pas de gestion de projet, de réunions, de téléconférences ou de formulaires. Simplement fais-le. Je n'ai jamais eu un client dire "hé, cela a été fait un peu trop vite pour nos goûts, nous apprécierions que vous mettiez une petite cascade ou quelque chose la prochaine fois".
Les méthodologies et la structure de l'équipe sont conçues pour uniformiser les règles du jeu d'un projet et obtenir différents niveaux de développeurs sur la même page, travaillant pour les mêmes objectifs, de la même manière.
Les "cowboys" à succès avec lesquels j'ai travaillé sont capables de:
- Identifiez le moyen le plus simple de mettre en œuvre rapidement quelque chose
- Sachez à quel moment il se cassera
- Écrivez du code clair, lisible et simple
- Prédire comment les utilisateurs vont l'utiliser, en abuser et le casser
- Mettez-le à l'échelle/abstrayez-le aux bons endroits, et n'y allez pas astronaute d'architecture
- Savoir où et comment gérer les cas et exceptions Edge
Des gens comme celui-ci produisent de très bons résultats avec très peu de gestion et de structure, mais ils sont rares.
EDIT: Pour référence future, ma réponse est pour ne autre question, qui a été fusionnée dans celle-ci. C'est assez déplacé 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 juste consciemment aucun. Pas de normes. Aucune assurance qualité. Pas du tout. D'où veut-elle que la qualité des logiciels provienne? Des arbres?
C'est drôle, elle nie en fait l'expérience des gens que vous citez, alors qu'elle en manque manifestement. Fournir des arguments vérifiables et pertinents pour contester leurs allégations est valable. Mais essayer de les discréditer en niant leur expérience ne l'est pas.
Mais, le point principal 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'avez utilisée avec le contrôle de version, vous pouvez facilement suivre les bogues qu'elle a introduits. Et laissez elle 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 réellement 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 convaincant (ce qui semble peu probable), en la faisant partir (pour le bien de votre entreprise) ou en partant (pour votre santé mentale).
Mais son échec en premier lieu est beaucoup plus probable et devrait certainement prouver votre point. Et puis, elle commencera à adhérer aux meilleures pratiques comme le font de nombreuses 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 requis - tout le monde dans l'équipe doit suivre certaines norme communément admise pour travailler vers l'objectif commun afin que leurs efforts soient compatibles.
Mais si je travaille seul, je veux bien sûr être un cow-boy. Toutes les grandes créations du monde ont été inventées par un seul esprit, ou tout au plus deux, à la manière d'un 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 assembler assez rapidement de nouveaux systèmes basés sur des recettes éprouvées (à condition qu'elles soient bien dirigées), mais il est rare d'entendre parler d'une invention réelle faite par une équipe. Le travail d'équipe et les méthodes qu'il requiert ont leurs vertus, tout comme le codage cowboy.
Dépend du problème. Un bon développeur senior écrira du code très compact, simple et robuste qui est très stable et utilise toutes les meilleures pratiques sans parcourir des pages de documentation et des tonnes de modèles et de paradigmes différents. Mais il saura également quand il pourra se permettre de faire de telles choses.
Je serais choqué qu'il prenne 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 fait une certaine conversion et n'est pas destinée à une réutilisation, la conception et les modèles ne sont en fait bons que pour perdre du temps.
En outre, je suppose qu'une grande partie de la conception a déjà été traitée dans un fil d'arrière-plan quelque part à l'intérieur de la tête des développeurs seniors.
Vous devez commencer à vous inquiéter lorsque le développeur senior commence à baratter les classes d'un système complexe ou de nouvelles applications à partir de zéro, et sans étape de planification.
Cela dépend des circonstances. Par exemple, après quelques scandales commerciaux désastreux, plusieurs bourses électroniques ont insisté pour que des drapeaux de négociation automatique soient ajoutés à tous les métiers. 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 des circonstances comme celle-ci, toutes les bonnes pratiques passent par le tableau - il suffit de faire (comme nous disions autrefois) "hacky, hacky, hacky". Et dans ces circonstances, l'écriture rapide et précise du code est la clé. D'autant plus qu'aucun système de test n'était disponible.
D'après mon expérience, le codage cow boy AVEC le contrôle de source est le meilleur moyen et le plus exempt de bogues pour développer de grands systèmes logiciels.
Ce type de personne est appelé un pirate informatique, et ce n'est généralement pas un terme complémentaire des plus professionnels d'entre nous.
Comme vous l'avez remarqué, le temps gagné dans la conception, l'organisation et le contrôle est perdu lors du débogage. Et souvent pour trouver quelle version du code était celle qui était réellement expédiée. Si vous pouvez le trouver du tout!
Je trouve que ce genre de personne est trop enveloppée en elle-même, je pense qu'elle est trop bonne pour travailler avec les "limitations" que les autres doivent souffrir et donc ne vous embêtez pas avec elles, et cela perd encore plus de temps que le reste de la l'équipe doit nettoyer après eux. Ils ne sont également pas trop impliqués dans le processus de correction de bogues (c'est une tâche de développeur de maintenance, bien en deçà des compétences et du talent du codeur 'l33t).
Donc, cela pourrait être une approche commune ailleurs, mais chez moi (et je suis un codeur senior qui a tendance à cette approche, ahem) nous n'en souffrons pas. Ce n'est pas que nous demandons une tonne de processus et de procédures, mais nous insistons sur une quantité minimale d'organisation, un contrôle du code source (qui pour être honnête est sanglant à l'est et sacrément utile!)
Kent Beck et al, sont tous des professionnels qui ont vu que les anciennes méthodes chargées de processus étaient mauvaises en elles-mêmes, alors ils ont créé de nouvelles méthodologies pour organiser le codage tout en le gardant plus orienté métier, puis ont dit à tout le monde à ce sujet - en publiant des livres (comment l'avez-vous fait à l'époque 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 manager devrait s'attaquer à cette "rockstar", mais s'ils ne sont pas… eh bien, cela ne vous empêche toujours pas de faire la bonne chose. N'acceptez pas la pratique de mauvaise qualité de sa part, si elle fout (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 relais au détriment de votre productivité de codage, et vous serez bon pour l'avenir.
Voici n essai d'un écrivain vraiment perspicace. Cela ne résout pas votre problème, mais cela vous donne un aperçu de la raison pour laquelle c'est comme ça et peut-être quelques conseils pour y faire face de manière professionnelle.
Je pense que l'un des commentateurs avait raison - son tout sur les résultats.
Si la personne peut produire un bon produit - quelque chose qui fait ce qu'elle est censée faire et qui est maintenable et fiable - alors qu'importe si des méthodologies ou des processus formels sont suivis ? Les processus sont excellents pour garantir un étage de qualité, mais si quelqu'un travaille déjà au-dessus de cet étage, alors les processus n'ajoutent rien à l'équation. Trop de développeurs de nos jours, imo, semblent penser que le point de la programmation est d'adhérer aux processus, par opposition à produire un bon produit.
Vous pourriez trouver un aperçu dans ma réponse à Franchement, préférez-vous le codage de cow-boy? Le problème est que "le codage de cow-boy" signifie différentes choses pour différentes personnes, et ce n'est pas immédiatement évident, à l'œil non averti, quelle version vous voyez.
Quand quelqu'un peut regarder un problème et commencer immédiatement à émettre du code, rapidement et avec précision, cela peut-être être le signe d'un ingénieur maître qui l'a déjà vu mille fois auparavant et qui connaît déjà 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 écrire des tests parce qu'ils sont trop "académiques" est définitivement pas une approche "senior" ou même à distance professionnelle. Vous ne verrez jamais, jamais ce genre de chose se faire dans un grand magasin de logiciels comme Microsoft ou Google, et vous ne le verrez probablement pas non plus dans la plupart des startups ou des équipes d'entreprise raisonnablement matures.
Les risques sont tout simplement trop grands. Et si votre PC meurt pendant la nuit? Au revoir 3 ans de productivité. D'accord, vous effectuez donc des sauvegardes; alors que se passe-t-il lorsque vous effectuez un changement majeur, réalisez qu'il é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 faux. Si vous n'exécutez aucun contrôle de version, vous allez juste faire tourner vos roues dans la boue. J'y suis allé, une fois, et j'y retournerais jamais.
Il n'y a aucune excuse - cela prend 10 minutes pour configurer un référentiel et 10 secondes pour faire 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 étant raisonnablement utiles.
Je ne suis pas fan des méthodologies Agile (notez le A majuscule) mais parfois vous avez vraiment besoin de simplement retrousser vos manches et commencer à écrire le fichu code. J'ai vu des gens et des équipes souffrant de "paralysie de l'analyse" et la productivité en prend vraiment un coup visible. Mais le rejet des outils de base de notre métier tels que le contrôle des révisions et les tests est vraiment la clé pour moi; cette personne n'appartient pas à un poste supérieur.
Le seul fait important est les résultats à long terme des produits 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 élevé de programmeurs moyens codant à un taux moyen.
Si le cow-boy produit des trucs que les programmeurs habituels ne produisent pas (pour une échéance ou une spécification donnée), et que l'équipe avec le cow-boy doit même passer quelques semaines/mois pour nettoyer le gâchis du cow-boy, ils pourraient toujours 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, maintenir) le désordre même après plusieurs mois/an, alors quelle que soit l'avance créée par le cow-boy, cela n'a pas donné à l'équipe un avantage à long terme.
Décidez lequel et optimisez la composition de l'équipe.
Tous les programmeurs ne fonctionnent pas (ou ne devraient pas fonctionner) de la même manière, tant que le résultat final est bon.
Quand je pense aux méthodologies "traditionnelles", je pense que "la direction ne sait pas comment comprendre les développeurs, donc au lieu d'entrer dans le monde des développeurs et de comprendre suffisamment pour savoir ce qui se passe, ils font entrer les développeurs dans leur monde".
Fondamentalement, quand je pense à "Agile", je pense que "vous faites ce que vous devez faire pour minimiser les inefficacités introduites par plusieurs personnes travaillant ensemble". Je suis donc fermement dans le camp que "il n'y a rien de tel que LE Méthodologie Agile , juste un ensemble de valeurs et de principes ".
En d'autres termes, il y a des choses que vous devez faire sur un très grand projet, et il y a des choses que vous devez faire sur des petits projets, et il y a des choses que vous faites sur les deux.
Par exemple, je n'aurais pas plus que le plus simple des backlogs pour un projet sur lequel je travaille moi-même ... Ce serait juste une liste de choses à faire. S'il y a deux d'entre nous, 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'en ai 3 ou 4, je cherche une sorte de système d'élément de travail.
Oui, mais vous devez savoir quand NE PAS le faire.
Sur tout ce qui est petit, vous allez probablement bien, mais si vous avez quelque chose de complexe, dangereux, contraint, etc., vous devez être en mesure de reconnaître quand une conception appropriée 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.
J'ai le sentiment que votre dégoût pour son style vous amène à le dénaturer légèrement. Vous dites l'approche Cowboy est payée en débogage - est-ce ce qui se produit déjà, ou est-ce votre hypothèse sur la façon dont cela se déroulera?
Divulgation équitable - Je suis moi-même un développeur senior et je renonce souvent à un processus formel de conception et d'expérience. Ne pas avoir de processus formel pour quelqu'un qui est très expérimenté 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 plus de bogues devraient être introduits car il manque un processus formel. Le seul gros problème que j'ai lu dans votre compte est que le contrôle des révisions n'est pas utilisé - ce qui est non seulement égoïste, mais carrément téméraire de la part du développeur. En fait, ne s'engage-t-elle pas du tout, ou tout simplement ne s'engage-t-elle pas selon un schéma qui vous convient?
Ne pas avoir une approche formelle de la conception n'est pas du "codage cowboy" dans mon livre (cependant, ne pas utiliser le contrôle des révisions). L'expérience doit être utilisée exactement pour cela - pour réduire le temps nécessaire pour trouver une solution "suffisamment bonne". N'oubliez pas que vous devez résoudre les problèmes que vous rencontrez actuellement et rendre le code facile à modifier, et non pas à la conception de scénarios futurs qui pourraient ne jamais se produire. Avec l'expérience, vous comprenez très bien comment faire cela très rapidement.
Il semble y avoir deux camps - ceux qui sont en faveur des résultats et ceux qui sont en faveur des principes. Je tombe dans ce dernier.
Je suis un programmeur médiocre mais sans doute consciencieux - ma principale préoccupation lors du codage, au-delà pour faire le travail, est que j'aide quiconque utilise mon code à faire LEUR travail. Je ne peux pas dire que j'ai toujours réussi - mais c'est ce que je vise à faire.
Bien sûr, vous mai avez un hotrod dans votre équipe - mais que se passe-t-il quand ils prennent quelques semaines de congé et qu'on vous demande de déboguer leur travail ou d'y ajouter des trucs? En fin de compte, les programmeurs de cow-boys ne sont pas des joueurs d'équipe. Ils peuvent faire du bon code, mais si l'équipe dépend d'eux - alors c'est dangereux.
Uniquement lors du prototypage de fonctionnalités très simples.
Ensuite, une fois terminé et considéré comme la bonne façon, je laisse tomber le code et deviens sérieux.
Je l'ai fait une fois sur un vrai projet (à l'époque où nous l'appelions Samurai Programming, après la série de croquis Samurai Tailor sur Saturday Night Live), et à mon grand étonnement, cela a bien fonctionné. Bien sûr, j'ai commencé par les ordures, donc il y avait peu de risques d'aggraver les choses.
Cependant, je suis un "soignée" dans l'âme et je n'aime pas le style de développement shoot-from-the-hip.
D'un autre côté, un modus operandi fortement chargé de processus n'est pas à mon goût non plus. J'aime juste planifier avant d'agir.
Dans l'ensemble, je pense 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 que la rigueur et des critères stricts soient imposés aux personnes développant le logiciel pour l'avionique ou les équipements biomédicaux, par ex. Pour les jeux, par exemple, il y a beaucoup moins d'inconvénients à tout échec, donc le coût et le fardeau des pratiques de développement rigoureuses et méthodiques ne sont pas vraiment justifiés.
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'un autre côté, si le projet est suffisamment petit pour que vous puissiez conceptualiser la conception entière (la plupart sont de toute façon) sans l'écrire, dessiner des diagrammes, etc., alors vous êtes probablement aussi bien sans ce travail supplémentaire de documenter tout ce que vous faites.
Presque tout le monde a entendu suffisamment d'histoires d'horreur pour se rendre compte qu'essayer d'intervenir sans avoir une idée claire de ce que vous faites et où vont les choses 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 la peine. Il y a un seuil en dessous duquel la production ne vaut pas la peine - 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 des cas comme celui-ci, ce qui est souvent est utile est de produire une bibliothèque pour faciliter des tâches comme celle-ci. Avec cela, le code frontal devient souvent si trivial qu'il est plus facile d'écrire (ou de modifier) du code pour faire ce que vous voulez 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 diverses manières subtiles, donc les seuls choix raisonnables sont 1) ne l'utilisez pas du tout, ou 2) décidez d'aimer ce qu'il vous donne au lieu d'essayer d'obtenir ce que vous vouliez à l'origine.
Je ne pense pas que le codage Cowboy soit une approche senior.
Comme d'autres l'ont dit, il y a un réel danger à rejeter le contrôle de version. Ignorer la documentation et l'analyse peut également signifier risquer de livrer quelque chose que l'utilisateur ne veut pas. Juste mon avis, mais je ne pense pas que vous passiez du "codeur au développeur" si vous ne faites que du code cowboy.
Cependant, oui, il existe des exceptions comme celle mentionnée par Neil Butterworth. Et dans ces situations, je préfère qu'un développeur senior expérimenté soit celui qui doit faire le codage des cow-boys.
Je trouve votre message intéressant. J'ai souvent partagé des points de vue avec votre sujet, et son sentiment est que les méthodes trop formalisées étouffent. Comme quelqu'un d'autre l'a noté, si elle est un génie et peut suivre une multitude de notes mentales en même temps sans oublier ni se confondre, il est tout à fait possible de maintenir un morceau monolithique de code alambiqué et de lui faire faire des choses incroyables avec des changements complètement obscurs. . Il y a un certain bonheur mental qui vient dans les cerveaux 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 à la dure que personne, sauf l'auteur d'origine, ne peut jamais rien faire qui soit utile à ce code. Si le programmeur passe à autre chose, il finit par perdre beaucoup d'argent en découvrant que la seule option est de réécrire (je pensais que cela signifiait une perte totale, mais je me rends compte de nos jours que vous ne détruisez pas le résultat intrinsèque de développement itératif au niveau des fonctionnalités externes).
Personnellement, cela ne me dérangerait pas d'avoir quelqu'un comme ça dans l'équipe, car dans une crise, ils pourraient faire quelque chose auquel personne d'autre ne pense.
D'un autre côté, soyez votre propre personne et décidez par vous-même de la réponse à votre question, car la seule chose qui est sûre est que personne l'a compris quand il s'agit de créer un logiciel. C'est l'une des choses qui en fait un domaine intéressant ...
La programmation Cowboy est un moyen assez sûr de créer une grosse boule de boue . Ce qui, aussi désagréable que cela puisse paraître, a tendance à livrer ...
Je pense que les nouveaux programmeurs ont tendance à faire des choses de codage de cow-boy lorsqu'ils prennent en charge des aspects d'un projet/des étendues avec lesquels ils n'ont peut-être pas beaucoup d'expérience ou lorsqu'ils essaient de "faire avancer les choses" en raison de 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 modèle approprié à utiliser et je me suis juste "piraté le chemin".
La différence entre moi et la personne dont vous vous plaignez est que je me rends compte généralement peu de temps après que j'aurais pu le faire mieux et le rendre plus maintenable et cela m'incite généralement à en apprendre davantage et à améliorer mes compétences (en lisant des livres/articles sur le matière). Quand je reviens pour déboguer certaines de ces solutions piratées, je trouve généralement que c'est une douleur et cela contribue davantage à mon envie d'apprendre à le faire de la "bonne manière". Je pense que cette personne que vous décrivez est fondamentalement coincée à un niveau infantile de réflexion personnelle et que laisser son propre ego gêner réellement ses compétences en tant que développeur de logiciels ne semble pas être quelqu'un avec qui je voudrais travailler.
Non jamais.
Je fais toujours l'analyse des exigences, je pense à l'architecture, je conçois les détails, puis je 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 travaillait dans un style cow-boy. Nous sommes ingénieurs et avons une responsabilité envers le client et les utilisateurs.