ti-enxame.com

Francamente, você prefere a codificação Cowboy?

A maioria dos programadores que defendem metodologias corrige politicamente como Agile, Waterfall, RUP, etc. Alguns deles seguem a metodologia, mas não todos. Sinceramente, se você pode escolher a metodologia, certamente adotaria metodologias "corretas" convencionais ou preferiria a metodologia "mais fácil" como a programação de cowboys? Por quê?

Eu sei que depende. Por favor, explique quando você usaria um ou outro. Por favor, diga quais vantagens você vê na codificação Cowboy.

Veja sobre Cowboy coding na Wikipedia

68
Maniero

Eu acho que quase todo programador experiente passou por três estágios e alguns passam por quatro:

  1. Codificadores de cowboy ou pepitas sabem pouco ou nada sobre design e vê-lo como uma formalidade desnecessária. Se estiver trabalhando em pequenos projetos para stakeholders não técnicos, essa atitude poderá atendê-los bem por um tempo; faz as coisas acontecerem, impressiona o chefe, faz o programador se sentir bem consigo mesmo e confirma a idéia de que ele sabe o que está fazendo (mesmo que não saiba).

  2. Os astronautas de arquitetura testemunharam os fracassos de seus primeiros projetos de novelo de lã para se adaptarem às novas circunstâncias. Tudo deve ser reescrito e, para evitar a necessidade de outro reescrever no futuro, eles criam plataformas internas e acaba gastando 4 horas por dia em suporte, porque ninguém mais entende como usá-los corretamente.

  3. Quase-engenheiros geralmente confundem-se com real , engenheiros treinados porque são genuinamente competente e entenda alguns princípios de engenharia. Eles conhecem os conceitos subjacentes de engenharia e negócios: risco, ROI, UX, desempenho, manutenção e assim por diante. Essas pessoas veem o design e a documentação como um continuum e geralmente são capazes de adaptar o nível de arquitetura/design aos requisitos do projeto.

    Nesse ponto, muitos se apaixonam por metodologias, sejam elas Agile, Waterfall, RUP, etc. Eles começam a acreditar na infalibilidade absoluta e até mesmo em necessidade dessas metodologias sem perceber que no campo real engenharia de software, são apenas ferramentas, não religiões. E, infelizmente, isso os impede de chegar à fase final, que é:

  4. programadores de fita adesiva AKA gurus ou consultores altamente pagos sabem que arquitetura e design serão utilizados dentro de cinco minutos após ouvir os requisitos do projeto. Todo o trabalho de arquitetura e design ainda está acontecendo, mas é intuitivo e tão rápido que um observador não treinado o confundiria com codificação de cowboy - e muitos fazem .

    Geralmente, essas pessoas criam um produto que é "bom o suficiente" e, portanto, seus trabalhos podem ser um pouco modificados, mas estão miles longe do código de espaguete produzido por codificadores de cowboys . As pepitas não conseguem nem identificar essas pessoas quando elas são informadas sobre elas porque, para elas, tudo o que está acontecendo em segundo plano simplesmente não existe.

Alguns de vocês provavelmente estarão pensando neste momento que eu não respondi a pergunta. Isso ocorre porque a pergunta em si é falha. A codificação de cowboys não é uma opção escolha , é uma nível de habilidade , e você não pode mais ser codificador de cowboys do que você pode escolher ser analfabeto.

Se você é um programador de cowboys, não conhece outra maneira.

Se você se tornou um astronauta da arquitetura, é incapaz física e psicologicamente de produzir software sem design.

Se você é quase um engenheiro (ou um engenheiro profissional), a conclusão de um projeto com pouco ou nenhum esforço inicial de design é uma escolha consciente (geralmente devido a prazos absurdos) que deve ser ponderada contra os riscos óbvios e empreendida somente após as partes interessadas terem concordado com eles (geralmente por escrito).

E se você é um programador de fita adesiva, nunca há motivo para "código de cowboy" porque você pode criar um produto quality com a mesma rapidez.

Ninguém "prefere" a codificação de cowboys a outras metodologias porque não é uma metodologia. É o equivalente ao desenvolvimento de software dos botões de esmagamento em um videogame. Tudo bem para os níveis iniciantes, mas qualquer um que tenha passado desse estágio simplesmente não o fará. Eles podem fazer algo que é semelhante mas não será a mesma coisa.

204
Aaronaught

Sim.

Também prefiro deixar minhas meias no chão, onde as tirei, minha mesa coberta de impressões e velhas embalagens de salgadinhos, minha pia cheia de louça suja e minha cama desarrumada.

Não considero férias planejadas com antecedência como férias apropriadas, uma refeição com a mente voltada para a nutrição de alimentos adequados ou permanecer em trilhas conhecidas para caminhadas adequadas.

Gosto de me divertir, me surpreender, aprender coisas novas, cometer erros e nunca ter certeza se vou conseguir voltar. E às vezes, essa atitude é exatamente o que é necessário para obter um projeto do zero ...

... mas na maioria das vezes, é irresponsável. Quando a dança terminar, o flautista será pago ... Esqueça isso por sua conta e risco.

46
Shog9

Você está exatamente correto. Essa abordagem de "programação de cowboy" pode obter a primeira revisão do código mais rapidamente, mas essa economia de tempo será mais do que perdida graças a:

  • Erros adicionais
  • Tempo adicional necessário para encontrar os erros que você teria de qualquer maneira
  • Ter que fazer engenharia reversa do seu código para lembrar o que você fez quando precisa fazer uma alteração em seis meses
  • Tempo extra gasto treinando desenvolvedores adicionais que precisam trabalhar no seu código
  • Não ter um log de revisões para revisar quando você faz uma alteração que quebra algo
  • Não tendo módulos, você pode reutilizar facilmente em projetos posteriores
  • E assim por diante

Como Neil Butterworth mencionado em sua resposta, às vezes você precisa fazer o que precisa. Como prática geral, porém, não, digitar o código o mais rápido possível, sem tempo gasto em controle de código-fonte, padrões, documentação etc. é um péssimo hábito.

É bom para você analisar seus colegas de trabalho e considerar se os hábitos deles são benéficos ou prejudiciais, em vez de fazer cegamente o que fazem.

31
Warren Pena

Isso realmente se resume à questão de se você pode ou não implementar as coisas corretamente, sem uma estrutura rígida e muito tempo consumido no planejamento.

Vou jogar aqui algo que pode ser realmente impopular: os clientes geralmente querem que as coisas sejam tratadas de maneira cowboy.

Ou seja, eles querem solicitar que algo seja feito e que alguém pule, execute e publique. Nenhum gerenciamento de projeto, reuniões, teleconferências ou formulários. Apenas faça. Eu nunca tive um cliente dizendo "ei, isso foi feito rápido demais para o nosso gosto, nós apreciaríamos se você colocasse uma cachoeira ou algo assim na próxima vez".

As metodologias e a estrutura da equipe são projetadas para nivelar o campo de jogo de um projeto e obter níveis variados de desenvolvedores na mesma página, trabalhando para os mesmos objetivos, da mesma maneira.

Os "cowboys" de sucesso com os quais trabalhei são capazes de:

  • Identifique a maneira mais simples de implementar algo rapidamente
  • Saiba em que ponto ele vai quebrar
  • Escreva código limpo, legível e direto
  • Preveja como os usuários o usarão, abusarão e quebrarão
  • Escale-o/abstraia-o nos lugares certos, e não vá astronauta de arquitetura nele
  • Saiba onde e como lidar com casos e exceções do Edge

Pessoas assim produzem realmente ótimos resultados com muito pouca sobrecarga de gerenciamento e estrutura, mas são raros.

29
Brandon

EDIT: Para referência futura, minha resposta é para outra pergunta, que foi mesclada nesta. Está bastante fora de lugar aqui, mas essa não foi minha decisão.


Ela é apenas preguiçosa, arrogante, ignorante e extremamente egoísta. Esse comportamento é imprudente.

Quero dizer, não é que ela use uma metodologia não convencional ou talvez desatualizada. Ela apenas usa conscientemente nenhum. Sem padrões. Sem garantia de qualidade. Não. De onde ela espera a qualidade do software? Árvores?
É engraçado que ela negue a experiência das pessoas que você cita, quando ela obviamente não tem. Fornecer argumentos verificáveis ​​e relevantes para questionar suas reivindicações é válido. Mas apenas tentar desacreditá-los negando sua experiência não é.

Mas, o ponto principal é: Quanto tempo leva o controle de versão?
Se ela não puder ser convencida a investir os 5 segundos de vez em quando, leve-o ao chefe dela. O controle de versão não é opcional. Ponto final.

E depois que você usar o controle de versão, poderá rastrear facilmente quais erros ela introduziu. E vamos ela corrigi-los. É a bagunça dela, por que você deveria limpá-lo? Se ela acha que sua abordagem é melhor, deixe-a fazê-lo - todo o caminho.
Supondo que ela realmente possa fazer isso (dentro de um tempo razoável), você ainda tem um problema: o trabalho em equipe com ela é quase impossível. E isso é algo que você terá que resolver convencendo-a (o que parece improvável), fazendo-a sair (pelo bem da sua empresa) ou partir (pelo bem da sua sanidade).
Mas o fracasso dela em primeiro lugar é muito mais provável e definitivamente deve provar seu argumento. E então ela começará a aderir às melhores práticas, como muitas pessoas com muita experiência.

13
back2dos

Depende completamente se estou trabalhando sozinho ou em equipe.

Se eu trabalho em equipe, alguns convenções e acordos são necessários - todos na equipe devem seguir alguns padrão comumente acordado para trabalhar em direção ao objetivo comum, para que seus esforços são compatíveis.

Mas se eu trabalho sozinho, é claro que quero ser um cowboy. Todas as grandes criações do mundo foram inventadas por uma única mente, ou no máximo duas, trabalhando no estilo cowboy. Apenas para citar alguns:

  • Mecânica clássica? Cowboy Isaac Newton, adições posteriores de Leibniz, Lagrange, Hamilton.
  • Avião? Cowboys Wright.
  • Teoria da relatividade? Cowboy Albert Einstein.
  • Ciência fundamental dos computadores? Cowboy Alan Turing.
  • Transistor? Cowboys Walter Brattain e John Bardeen.

As equipes são boas em fazer melhorias incrementais e montar novos sistemas com base em receitas comprovadas com bastante rapidez (desde que estejam sendo bem conduzidos), mas é raro ouvir sobre uma invenção real feita por uma equipe. O trabalho em equipe e os métodos que ele exige têm suas virtudes, mas o mesmo acontece com a codificação de cowboys.

11
Joonas Pulakka

Depende do problema. Um bom desenvolvedor sênior escreverá um código muito compacto, simples e robusto que é muito estável e usa todas as práticas recomendadas sem percorrer páginas da documentação e toneladas de diferentes padrões e paradigmas. Mas ele também saberá quando pode se dar ao luxo de fazer essas coisas.

Eu ficaria chocado se ele resolvesse um novo problema e começasse a projetar um aplicativo que requer meses de trabalho a partir do zero. Mas se for um plugin, ferramenta simples que você pode escrever em 2 horas, uma função que faz alguma conversão e não se destina a uma reutilização, design e padrões são realmente bons apenas para perder tempo.

Além disso, acho que grande parte do design já foi processada em um encadeamento em segundo plano em algum lugar dentro da cabeça dos desenvolvedores seniores.

Você deve começar a se preocupar quando o desenvolvedor sênior começar a agitar classes de um sistema complexo ou novos aplicativos a partir do zero e sem a etapa de planejamento.

7
Coder

Depende das circunstâncias. Por exemplo, após alguns escândalos desastrosos de negociação, várias bolsas de valores eletrônicas insistiram que as bandeiras de negociação automática foram adicionadas a todos os negócios. E isso tinha que ser para todos os softwares de negociação em uma semana. Quero dizer, tinha que ser feito - se a bandeira não estivesse lá, você não poderia trocar. Em circunstâncias como essa, todas as boas práticas seguem o conselho - você apenas precisa (como costumávamos dizer) "hacky, hacky, hacky". E nessas circunstâncias, escrever código de maneira rápida e precisa é essencial. Especialmente porque não havia sistemas de teste disponíveis.

6
Neil Butterworth

Pela minha experiência, o cowboy que codifica WITH control source é a melhor e mais livre de bugs para desenvolver grandes sistemas de software.

5
jojo

Esse tipo de pessoa é chamado de hacker, e geralmente não é um termo complementar entre os mais profissionais entre nós.

Como você notou, o tempo economizado em design, organização e controle é perdido na depuração. E, muitas vezes, na descoberta de qual versão do código foi realmente enviada. Se você pode encontrá-lo!

Acho que esse tipo de pessoa está muito envolvido consigo mesmo, acho que é bom demais para trabalhar com as 'limitações' que os outros têm que sofrer e, portanto, não se incomoda com elas, e isso perde ainda mais tempo que o resto da vida. equipe tem que limpar depois deles. Eles também não estão muito envolvidos no processo de correção de bugs (essa é uma tarefa do desenvolvedor de manutenção, muito abaixo das habilidades e talentos do codificador l33t).

Portanto, pode ser uma abordagem comum em outros lugares, mas na minha casa (e eu sou um programador sênior que tem tendências a essa abordagem, ahem), não a sofremos. Não é que exijamos uma tonelada de processos e procedimentos, mas insistimos em uma quantidade mínima de organização, controle de código-fonte (o que, para ser honesto, é sangrento a leste e muito útil!)

Kent Beck et al, são todos os profissionais que viram os velhos caminhos carregados de processos serem ruins em si mesmos; portanto, eles criaram novas metodologias para organizar a codificação, mantendo-a mais orientada para o artesanato e depois disseram a todos os outros sobre isso - publicando livros (de que outra forma você fazia isso antes da Internet?)

Parece que você está certo - não aceite práticas inadequadas apenas porque alguém não pode invadir isso. O líder ou o gerente da sua equipe deve estar muito preocupado com essa 'estrela do rock', mas se não estiverem ... bem, isso ainda não o impede de fazer a coisa certa. Só não aceite a prática de má qualidade dela, se ela estragar (e ela vai!), Então deixe-a limpar. Você segue as boas práticas (e sabe o que são) sem deixá-las assumir o risco de prejudicar sua produtividade de codificação, e será bom para o futuro.

Aqui está m ensaio de um escritor verdadeiramente perspicaz. Não resolve o seu problema, mas fornece algumas idéias sobre como é e talvez algumas dicas para lidar com isso profissionalmente.

4
gbjbaanb

Eu acho que um dos comentaristas estava certo - é tudo sobre os resultados.

Se a pessoa pode produzir um bom produto - algo que faz o que deveria fazer e é sustentável e confiável - então o que importa se metodologias ou processos formais são seguidos ? Os processos são ótimos para garantir um piso de qualidade, mas se alguém já estiver trabalhando acima desse piso, os processos não acrescentam nada à equação. Atualmente, muitos desenvolvedores parecem pensar que o ponto da programação é aderir aos processos, em oposição a produzir um bom produto.

4
GrandmasterB

Você pode encontrar algumas dicas na minha resposta para Francamente, você prefere a codificação de cowboys? O problema é que "codificação de cowboys" significa coisas diferentes para pessoas diferentes, e não é imediatamente óbvio para os olhos destreinados, qual versão você está vendo.

Quando alguém pode olhar para um problema e imediatamente começar a ajustar o código, com rapidez e precisão, isso pode é o sinal de um engenheiro mestre que já o viu milhares de vezes e já sabe o melhor maneira de resolver o problema.

Ou, pode ser o sinal de um amador de classificação.

Vou lhe dizer uma coisa: recusar-se a usar o controle de versão ou escrever testes porque eles são "acadêmicos" é definitivamente não uma abordagem "sênior" ou até remotamente profissional. Você nunca verá esse tipo de coisa sendo realizada em uma grande loja de software, como a Microsoft ou o Google, e provavelmente também não o verá na maioria das empresas iniciantes ou em equipes empresariais razoavelmente maduras.

Os riscos são grandes demais. E se o seu PC morrer durante a noite? Tchau tchau 3 anos de produtividade. Ok, então você faz backups; então o que acontece quando você faz uma grande mudança, percebe que estava completamente errado e precisa revertê-la? Isso acontece até para os desenvolvedores mais experientes e talentosos, porque os requisitos estão errados. Se você não estiver executando nenhum tipo de controle de versão, estará girando suas rodas na lama. Já estive lá uma vez e nunca voltaria.

Não há desculpa: são necessários 10 minutos para configurar um repositório e 10 segundos para fazer uma consolidação. Isso representa talvez 1% do seu tempo total de desenvolvimento. Os testes, se você estiver com pressa, podem ser reduzidos facilmente para 20 a 30 minutos por dia e ainda assim são razoavelmente úteis.

Não sou fã das metodologias Agile (observe a letra A maiúscula), mas às vezes você realmente precisa arregaçar as mangas e começar a escrever o maldito código. Eu já vi pessoas e equipes com "paralisia de análise" e produtividade realmente sofrer um impacto visível. Mas a dispensa das ferramentas básicas do nosso comércio , como controle de revisão e testes, é realmente o argumento decisivo para mim; essa pessoa não pertence a uma posição sênior.

3
Aaronaught

O único fato importante são os resultados do produto a longo prazo da equipe.

Há uma alegação de que uma equipe incluindo um grande programador (ou mais) produzirá melhores resultados do que uma equipe com um número ainda maior de programadores médios codificando a uma taxa média.

Se o cowboy produzir coisas que os programadores regulares não produzem (por um determinado prazo ou especificação), e a equipe com o cowboy precisar passar alguns homens semanas/meses limpando a bagunça do cowboy, eles ainda poderão acabar com o problema. melhor resultado mais cedo.

Se a equipe com o cowboy não puder limpar (documentar, depurar, integrar, manter) a bagunça, mesmo depois de muitos meses/ano, o avanço que o cowboy criou não deu à equipe uma vantagem a longo prazo.

Decida qual e otimize a lista da equipe.

Nem todo programador funciona (ou deve funcionar) da mesma maneira, desde que o resultado final seja bom.

3
hotpaw2

Quando penso em metodologias "tradicionais", acho que "o gerenciamento não sabe entender os desenvolvedores; portanto, em vez de entrar no mundo dos desenvolvedores e entender o suficiente para saber o que está acontecendo, eles fazem com que os desenvolvedores entrem em seu mundo".

Fundamentalmente, quando penso em "Agile", penso "você faz o que precisa para minimizar as ineficiências introduzidas por várias pessoas trabalhando juntas". Então, eu estou firmemente no campo de que "não existe algo como A Metodologia Ágil , apenas um conjunto de valores e princípios ".

Em outras palavras, há coisas que você precisa fazer em um projeto muito grande, e coisas que você precisa fazer em projetos pequenos, e há coisas que você faz nos dois.

Por exemplo, eu não teria mais do que a lista de pendências mais simples de um projeto em que estou trabalhando ... Seria apenas uma lista de tarefas. Se houver dois de nós, provavelmente eu teria essa lista compartilhada, mas em um formato muito simples (provavelmente apenas uma nota armazenada em nosso repositório de códigos). Quando tenho 3 ou 4, estou procurando algum tipo de sistema de itens de trabalho.

2
MIA

Sim, mas você precisa reconhecer quando NÃO fazê-lo.

Em qualquer coisa pequena, você provavelmente está bem, mas se tiver algo complexo, perigoso, constrangido, etc., precisará reconhecer quando um design adequado vale o tempo extra.

Eu também acho que você definitivamente deveria pensar na resposta de Aaronaught. Cowboy significa coisas diferentes para pessoas diferentes.

2
Bill

Tenho a sensação de que seu desagrado pelo estilo dela está fazendo com que você o detecte um pouco. Você diz a abordagem de cowboy é paga na depuração - é isso o que já está acontecendo, ou é essa a sua suposição de como será o desempenho?

Divulgação justa - Eu também sou desenvolvedor sênior e muitas vezes abandono um processo formal de design e experiência. Não ter um processo formal para alguém com muita experiência no domínio do problema é bastante comum. Se você resolveu um problema dezenas de vezes, não precisa de um processo formal para formular uma solução semelhante novamente.

Um processo formal lida com o design do código - não vejo por que mais bugs devem ser introduzidos porque um processo formal está ausente. O único grande problema que li na sua conta é que o controle de revisão não está sendo usado - o que não é apenas egoísta, mas absolutamente imprudente em nome do desenvolvedor. Ela não está realmente se comprometendo, ou simplesmente não está se comprometendo com um padrão que é do seu agrado?

Não ter uma abordagem formal ao design não é 'codificação de cowboy' no meu livro (embora não seja usando o controle de revisão). A experiência deve ser usada exatamente para isso - para reduzir o tempo necessário para encontrar uma solução 'suficientemente boa'. Lembre-se de que você precisa resolver os problemas que você tem atualmente e facilitar a alteração do código, não projetar para cenários futuros que talvez nunca aconteçam. Com a experiência, você tem uma boa ideia de como fazer isso muito rápido.

1
Eran Galperin

Parece haver dois campos - aqueles que favorecem os resultados e aqueles que favorecem os princípios. Eu caio nesse último.

Sou um programador medíocre, mas indiscutivelmente consciente - minha principal preocupação ao codificar: além realizar o trabalho, é que estou ajudando quem usa o meu código para realizar o trabalho. Não posso dizer que sempre consegui isso - mas é isso que pretendo fazer.

Claro, você pode possui um hotrod em sua equipe - mas o que acontece quando eles demoram algumas semanas e você é solicitado a depurar o trabalho ou adicionar coisas a ele? Por fim, os programadores de cowboys não são jogadores de equipe. Eles podem criar ótimos códigos, mas se a equipe depende deles - é perigoso.

1
sunwukung

Somente ao prototipar recursos muito simples.

Então, uma vez feito e considerado da maneira certa, abandono o código e fico sério.

1
Klaim

Eu fiz isso uma vez em um projeto real (na época, nós o chamamos de Programação Samurai, depois da série de esboços do Samurai Tailor no Saturday Night Live) e, para minha surpresa, funcionou bem. Obviamente, o que eu comecei foi o lixo, então havia pouco risco de piorar.

No entanto, sou um "puro" no coração e não gosto do estilo de desenvolvimento do tipo atirar do quadril.

Por outro lado, o modus operandi altamente carregado de processos também não é do meu gosto. Eu só gosto de planejar antes de agir.

Em suma, acho que a quantidade de processo formal apropriada depende muito da magnitude (tamanho do código, duração do projeto, número de desenvolvedores, tipos de requisitos etc.) do projeto. Desejo que critérios rigorosos e rigorosos sejam impostos às pessoas que desenvolvem o software para equipamentos aviônicos ou biomédicos, por ex. Para jogos, por exemplo, há muito menos desvantagens em qualquer falha, portanto, o custo e o ônus de práticas de desenvolvimento rigorosas e metódicas não são realmente justificados.

1
Randall Schulz

Depende (muito) do tamanho do projeto. Por um lado, para obter um resultado decente, você precisa ter um design. Por outro lado, se o projeto for pequeno o suficiente para que você possa conceituar todo o design (na maioria das vezes, sem anotá-lo, desenhar diagramas etc.), provavelmente estará bem sem esse trabalho extra de documentando tudo o que você faz.

Quase todo mundo já ouviu histórias de terror suficientes para perceber que tentar entrar sem uma ideia clara do que você está fazendo e para onde as coisas estão indo é uma receita para o desastre. O que é muito mais raramente apontado é que o oposto pode ser igualmente desastroso. Apenas por exemplo, a maioria de nós costuma escrever pequenas ferramentas no processo de programação. Escrever uma especificação completa, testes e documentação geralmente não vale a pena. Há um limite abaixo do qual a produtividade não vale a pena - as pessoas geralmente não gostam de reinventar a roda, mas em alguns casos é mais fácil reinventar do que evitá-la.

Em casos como esse, muitas vezes é vale a pena produzir uma biblioteca para facilitar tarefas como essa. Com isso, o código do front-end geralmente se torna tão trivial que escrever (ou modificar) o código para fazer o que você quer se torna mais fácil do que decidir como obter um programa completo para fazer o que você deseja. Considere, por exemplo, o recuo do gnu com mais de 50 sinalizadores diferentes, muitos dos quais interagem de várias maneiras sutis; portanto, as únicas opções razoáveis ​​são: 1) não o use, ou 2) decida gostar do que isso lhe oferece em vez de tentar conseguir o que você originalmente queria.

1
Jerry Coffin

Não acho que a codificação de cowboy seja uma abordagem sênior.

Como outros já disseram, há um risco real de descartar o controle de versão. Ignorar a documentação e a análise também pode significar arriscar a entrega de algo que o usuário não deseja. Apenas minha opinião, mas acho que você não passa de "codificador para desenvolvedor" se tudo o que você faz é código de cowboy.

No entanto, sim, há exceções como a mencionada por Neil Butterworth. E nessas situações, prefiro que um desenvolvedor sênior experiente seja o responsável pela codificação dos cowboys.

0
Bernard Dy

Acho sua postagem interessante. Eu sempre compartilhei opiniões com o seu assunto, e o sentimento dela é que métodos super formalizados são sufocantes. Como alguém notou, se ela é um gênio e pode rastrear uma infinidade de notas mentais ao mesmo tempo sem esquecer ou se confundir, é bem possível manter um pedaço monolítico de código complicado e fazer coisas incríveis com mudanças completamente obscuras . Há uma certa felicidade mental que chega ao cérebro das pessoas que podem fazer isso - é como ser um Deus de um pequeno universo em sua mente.

No entanto, os empregadores inteligentes aprenderam da maneira mais difícil que ninguém, exceto o autor original, pode fazer algo que valha a pena nesse código. Se o programador seguir em frente, eles acabarão gastando muito dinheiro descobrindo que a única opção é reescrever (eu costumava pensar que isso significava perda total, mas hoje percebo que você não destrói o resultado intrínseco de desenvolvimento iterativo no nível da funcionalidade externa).

Pessoalmente, não me importo de ter alguém assim na equipe, porque, em uma crise, eles podem fazer algo que ninguém mais pensa.

Por outro lado, seja você mesmo e decida por si mesmo qual é a resposta para sua pergunta, porque a única coisa certa é que ninguém descobriu isso quando se trata de criar software. É uma das coisas que o torna um campo interessante ...

0
Aaron Anodide

A programação de cowboy é uma maneira bastante certa de criar um grande bola de barro . Que, por mais desagradável que pareça, tende a entregar ...

0
Denis de Bernardy

Eu acho que os programadores mais novos tendem a fazer algumas coisas de codificação de cowboys ao abordar aspectos de um projeto/escopo com os quais eles podem não ter muita experiência ou quando estão tentando "simplesmente fazer as coisas" devido à pressão de um chefe, etc. Eu sei que definitivamente segui esse caminho algumas vezes porque me faltava o conhecimento do padrão adequado a ser usado e apenas "abri caminho".

A diferença entre mim e a pessoa da qual você está reclamando é que, logo depois, percebo que poderia ter feito melhor e tornado mais sustentável e geralmente me estimula a aprender mais e melhorar minhas habilidades (lendo livros/artigos sobre o assunto). sujeito). Quando volto a depurar algumas dessas soluções invadidas, geralmente considero uma dor e isso contribui mais para o meu desejo de aprender como fazê-lo da "maneira certa". Eu acho que essa pessoa que você está descrevendo está basicamente presa em um nível infantil de auto-reflexão e que deixa o próprio ego atrapalhar o aprimoramento de suas habilidades como desenvolvedor de software, não parece ser alguém com quem eu gostaria de trabalhar.

0
programmx10

Não nunca.

Sempre faço análise de requisitos, penso em arquitetura, projeto os detalhes e depois código. Mesmo se eu trabalhar sozinho em casa para um projeto pessoal.

E eu demitiria instantaneamente um desenvolvedor da minha equipe se ele estivesse trabalhando no estilo cowboy. Somos engenheiros e temos uma responsabilidade com o cliente e os usuários.

0
CesarGon