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

66

A maioria dos programadores que defendem metodologias politicamente corretas 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 a codificação Cowboy na Wikipedia

Maniero
fonte
13
Uma experiência foi realizada uma vez com dois grupos de pessoas que foram solicitadas a fazer panelas de barro em um período de tempo fixo. O grupo 1 foi instruído a fazer o pote da mais alta qualidade possível, o grupo 2 foi instruído a medir o peso de todos os potes produzidos. A qualidade dos potes finais do grupo 2 foi superior aos potes do grupo 1. Infelizmente, não consegui encontrar a fonte original desse experimento, mas o ponto principal é "quanto maior o número de iterações, melhor a qualidade". Os cowboys do grupo 2 eram? Provavelmente.
Adolf garlic
3
"Codificação de cowboy" - uma terrível escolha de palavras, se nada mais. Quando usado para se referir às pessoas de uma equipe, "cowboy" geralmente significa algo como "a pessoa que faz suas próprias coisas e não se importa com o que isso significa para o resto da equipe". Mas a questão do valor "menos estrutura" é boa.
MIA
4
Eu acho que você deve colocar sua definição de programação de cowboys (diretamente) em sua pergunta, pois tanto a página da Wikipedia quanto os respondedores parecem misturados sobre o que realmente é a codificação de cowboys. Você quer dizer apenas não usar nenhuma metodologia? Porque muitas pessoas parecem pensar que a codificação de cowboy não cria design. Pelo menos para mim, isso não significava nenhum processo formal - não que você pule a codificação imediatamente. Acho que já que você é quem deve fazer a pergunta, deve defini-la de acordo com o que você queria saber.
N1ckp 10/10
@ n1ck: Obrigado. Algumas pessoas simplesmente pulam nas respostas sem entender a pergunta. Agora é tarde demais, a alteração invalidaria algumas respostas. Infelizmente, alguns usuários não receberam a pergunta. Você entendeu.
Maniero 10/10
Essa pessoa não usa nenhum tipo de sistema de controle de origem ou apenas se recusa a usar o sistema da empresa?
Thomas

Respostas:

201

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 o veem 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 ideia de que ele sabe o que está fazendo (mesmo que não saiba).

  2. Arquitetura Os astronautas 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 outra reescrita no futuro, eles criam plataformas internas e acabam gastando 4 horas por dia em suporte, porque ninguém mais entende como usá-las adequadamente.

  3. Quase-engenheiros muitas vezes confundem-se para reais engenheiros, treinados, porque eles são realmente competentes e compreender 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. Elas começam a acreditar na infalibilidade absoluta e até na necessidade dessas metodologias sem perceber que, no campo real da 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 Os gurus da AKAou consultores altamente pagos sabem qual arquitetura e design serão usados ​​dentro de cinco minutos depois de 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 a codificação de cowboys - e muitos o fazem .

    Geralmente, essas pessoas criam um produto que é "bom o suficiente" e, portanto, seus trabalhos podem ser um pouco modificados, mas estão a quilômetros de distância do código de espaguete produzido pelos codificadores de cowboys. As pepitas não conseguem nem identificar essas pessoas quando lhes dizem 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 cowboy não é uma escolha , é um nível de habilidade , e você não pode optar por ser um codificador de cowboy, assim como não pode ser analfabeto.

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

Se você se tornou astronauta da arquitetura, é fisicamente e psicologicamente incapaz 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 de qualidade 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 pessoa que tenha passado desse estágio simplesmente não o fará. Eles podem fazer algo parecido, mas não será a mesma coisa.

Aaronaught
fonte
27
Lindamente articulado.
Brandon
4
+1 para uma boa contribuição, apesar da contradição. Você disse que um quase-engenheiro faz uma escolha consciente quando é necessário. Muitas vezes, programadores experientes e com conhecimento precisam escolher quebrar as regras que ele conhece e acredita devido a alguma restrição. É claro que se um programador é muito bom e rápido em seu trabalho, ele não precisa escolher, mas poucos profissionais têm essa qualidade. Enfim, a pergunta é provocativa.
Maniero
14
O problema é que muitas pessoas querem ser programadores de fita adesiva sem serem primeiro os astronautas de arquitetura e depois quase engenheiros, o que significa que eles são eternamente cowboys. Então, acho que posso apontar para essa lista e dizer "parece uma progressão na carreira" ... pena que os tipos de gerência pensem que os AAs são o pináculo.
MIA
19
Eu nem sei onde estou nesta lista: S Às vezes, posso ouvir sobre um projeto e saber instantaneamente como vou construí-lo, tipo 4, e então vou sofrer séria paralisia de análise e pensar demais na arquitetura, tipo 2, então eu considero a YAGNI e penso no valor do negócio e tento ser pragmático, me sinto como um 3, e então acabo fazendo uma bagunça como um 1.
Carson Myers
14
Eu deveria lhe dar -1 por sugerir que um consultor altamente pago está no nível de habilidade de programador de fita adesiva (dica: a maioria deles não está, nem chega perto). Mas eu te dei +1 de qualquer maneira.
Falcon
47

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.

Eu 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 iniciar um projeto ...

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

Shog9
fonte
Estou tendo problemas com o +1 por "embalagens velhas de lanches, minha pia cheia de louça suja e [o mais importante] minha cama desarrumada". Que diabos, +1 porque a emoção da codificação de cowboys e o desconforto de não saber se você pode voltar é muito empoderador para perder tempo com UML, design e especificações tolas. Eles escrevem as especificações da minha implementação, NUNCA o contrário. :: sarcasm
Chris
31

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.

Warren Pena
fonte
6
Sempre há exceção. Alguns codificadores podem ser gênios, têm memória fotográfica, mas pouca paciência. Outros não são tão rápidos, mas persistentes; eles esmigalham a tarefa, um byte de cada vez, até que se torne sua cadela. Existem muitas maneiras de ser um bom programador. Talvez a programação de cowboy funcione para ela. Pode não funcionar para o solicitante ou muitos outros. No entanto, por que mandato COMO alguém deve trabalhar, quando o importante é a taxa e a qualidade dos resultados? Por que aprovar uma lei que proíbe motores de 12 cilindros, quando você pode simplesmente recompensar mpg mais alto por meio de crédito tributário?
Job
@ Job: Eu concordo. Todo mundo tem um processo diferente; esse processo geralmente não é bem-sucedido, mas pode ser. Eu sou um usuário notório do algoritmo de Feynman , e passo 3 o mais rápido possível enquanto ainda estou na zona.
Jon Purdy
3
@ Job - Às vezes há exceções. As porcentagens acabarão por assumir. Pode haver exceções quando avaliadas isoladamente do código perfeito (sem erros, sem problemas, etc.), mas eventualmente os hábitos dos codificadores de cowboy atingem sua empresa (e sua equipe e ela) na bunda. Você pode ganhar na roleta russa cinco vezes seguidas, mas continua jogando e meu dinheiro está em risco.
Thomas
2
@ Job: Sim, eu meio que concordo, até certo ponto. Mas recusar-se a considerar qualquer outra coisa (que = recusar-se a aprender) e recusar-se a usar o controle de origem são duas grandes bandeiras vermelhas que me dizem: Pode ser rápido, mas um idiota muito perigoso.
quickly_now
11
Seguir um processo formal não é a única maneira de escrever código de qualidade e não garante código de qualidade. Ter um processo formal é menos importante se o trabalho de uma pessoa estiver "vagamente ligado" ao trabalho de outras pessoas. O controle de versão, se houver, fica mais importante à medida que o processo fica mais informal. Sobre "recusar-se a aprender" - quantas experiências ruins essa pessoa teve com processos e sistemas ruins no passado? Inferência é imperfeito, mas é basicamente a única maneira que temos de compreender qualquer coisa fora nossas próprias cabeças, e com o direito (ou melhor erradas) experiências ...
Steve314
29

Isso realmente se resume à questão de saber se você pode 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 um pouco rápido demais para o nosso gosto, nós apreciaríamos se você colocasse uma pequena cachoeira ou algo lá 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
  • Prever 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 extremos e exceções

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

Brandon
fonte
9
Eu realmente não chamaria sua lista final de codificação "cowboy". É mais como o "programador de fita adesiva" por excelência glorificado por Spolsky. A diferença é que um codificador de cowboy simplesmente começa a codificar juntos sem prestar atenção ao design geral; o "programador de fita adesiva" meio que faz as pazes à medida que avança, mas ainda tem um plano; ele está fazendo a maior parte do trabalho de design em um nível intuitivo (e às vezes iterativo).
Aaronaught
3
Os clientes não querem necessariamente o estilo cowboy, eles apenas querem barato e rápido. Cabe então a nós entregar.
@ user1249: Isso me lembra o triângulo do gerenciamento de projetos: barato, rápido, bom - escolha dois.
DanMan 27/08/16
A suposição de que os clientes são a autoridade profissional é risível. É claro que quero que as coisas sejam manuseadas de maneira caubói, é por isso que quero que meu carro seja arrumado rápido e sujo, que minha casa seja construída por recém-chegados que possam colar cimento de maneira parecida com uma parede, e que minha comida esteja preparada. por aqueles que ignoram risco para a saúde em benefício de me comer mais cedo ...
Henry Aloni
13

EDIT: Para referência futura, minha resposta é para outra pergunta, que foi mesclada a esta. 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 simplesmente não usa conscientemente . 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, você deve levar isso 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 deixá- la consertá-los. É a bagunça dela, por que você deveria limpá-lo? Se ela acha que sua abordagem é melhor, deixe-a fazê-lo - até o fim .
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 ponto de vista. E então ela começará a aderir às melhores práticas, como muitas pessoas com muita experiência.

back2dos
fonte
2
Às vezes a verdade dói puro e simples ...
ChaosPandion
+1 por dizer que o trabalho em equipe com pessoas tão egoístas é impossível. Mesmo que sejam gênios, os cowboys não são jogadores de equipe; eles são o show principal e nós somos a banda de apoio
MAWG
11

Depende completamente se estou trabalhando sozinho ou em equipe.

Se eu trabalho em equipe, são necessárias algumas convenções e acordos - todos na equipe devem seguir algum padrão comum para trabalhar em direção ao objetivo comum, para que seus esforços sejam 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.

Joonas Pulakka
fonte
Percebo que você mencionou alguns sucessos famosos de caubói, enquanto repassava as falhas muito mais numerosas.
Mawg 27/02
7

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 thread de segundo plano em algum lugar dentro da cabeça dos desenvolvedores sênior.

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

Codificador
fonte
9
sua resposta ignora completamente a parte mais reveladora da pergunta "Eu tenho um programador que codifica rapidamente, ignorando o controle de revisão ..." qualquer pessoa que negue o controle de revisão e promova essa opinião para funcionários de nível júnior é criminosa.
11
@ Jarrod: ou não. Há pouco sentido em cometer código incompleto / disfuncional.
Denis de Bernardy
11
@ Denis - é para isso que serve uma filial. O histórico de decisões, alterações, erros, becos sem saída etc. durante o desenvolvimento de código incompleto / disfuncional é IMO parte da documentação desse código e muito importante durante a manutenção. Ramificações e mesclagens mais fáceis são um bom motivo para substituir o subversion por um VCS distribuído.
Steve314
@ Steve: Isso pressupõe que você está olhando para os logs antes de editar uma linha de código. Francamente, conheço pouquíssimos programadores que realmente fazem ... E mesmo assim (como eu ...), eles estão muito menos interessados ​​em saber por que isso / aquilo foi cometido do que por isso, do que por que foi alterado do código original.
Denis de Bernardy
@steve: Para funções simples, é mais fácil usar o commit único com o comentário "Função adicionada que calcula os parâmetros de aceleração", do que ter coomits: "PaternX skeleton", "Primeira linha de código adicionada", "Corrigido um bug", "Corrigido outro erro". É mais fácil rastrear alterações globais do projeto se houver menos "ruído" confirmado. E existem prateleiras que podem ser usadas para código incompleto para evitar o dataloss.
Coder
6

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 dentro de uma semana. Quero dizer que 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.

Neil Butterworth
fonte
Como alguém usa seu SUÍNO? Qual é o idioma para descrever diálogos?
Job
@Job Ainda não está pronto.
Neil Butterworth
sua resposta pula completamente a parte mais reveladora da pergunta "Eu tenho um programador que codifica rapidamente ignorando o controle de revisão ..." Tenho certeza de que seu exemplo, eles não descartaram o controle de versão ou o gerenciamento de lançamento, etc.
@Jarrod Controle de versão. Bem, nós tivemos rcs. Gerenciamento de liberação? Este era um banco de investimento! Você empurra as coisas para fora da porta o mais rápido que as escreve.
Neil Butterworth
bem vindo de volta.
usar o seguinte
5

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

jojo
fonte
2
Ao custo de criar uma grande bola de lama (a minha própria resposta ;-))
Denis de Bernardy
4

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 -, o que importa se metodologias ou processos formais são seguidos? Os processos são ótimos para garantir um nível de qualidade, mas se alguém já estiver trabalhando acima desse nível, os processos não acrescentam nada à equação. Atualmente, muitos desenvolvedores parecem pensar que o objetivo da programação é aderir aos processos, em vez de produzir um bom produto.

GrandmasterB
fonte
4

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 no leste e é útil!)

Kent Beck et al, são todos os profissionais que viram que os velhos caminhos carregados de processos eram ruins em si mesmos; portanto, eles criaram novas metodologias para organizar a codificação, mantendo-a mais orientada para o artesanato e depois contaram a todos 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á um 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.

gbjbaanb
fonte
+1 É lamentável que 'hacker' tenha mudado para significar isso. Uma Breve História do Hackerdom
Gyan aka Gary Buyn
4
Eu diria "hackear" em vez de "hacker".
Mike Sherrill 'Cat Recall'
2
Eles são um cowboy, assim como o OP afirmou, não confundem o que é um hacker. Deixe isso para a mídia.
ocodo
pode ser que eles sejam um programador "rockstar" ... cheio de ego e talento para se preocupar com as 'pequenas coisas'. Agora, onde está minha banheira cheia de m & ms azul ?! Eu quero isso agora!
gbjbaanb
3

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.

hotpaw2
fonte
4
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 - isto é, até que o grande programador saia e pegue sua sela, cavalo e seu código com eles. Quão bons são esses resultados?
Thomas
A suposição não é necessariamente correta. Cumprir o prazo de uma conferência ou outro programa do seu produto também pode ser extremamente importante.
11
@ Thomas: fatores de risco cortam nos dois sentidos. O sujeito que financia todos os salários poderia sair da próxima rodada de financiamento quando mesmo uma prova de conceito cortada em conjunto não aparece em breve. Quão bons são seus cavalos lentos agora? Todas as opções de engenharia são apostas. Coloque suas fichas.
precisa saber é o seguinte
@ hotpaw2 - A aposta é se os custos (potencialmente terminais) da codificação de cowboy serão atingidos antes que você possa obter seu financiamento. Em geral, minha aposta é contra a codificação de cowboys (e isso levará mais tempo). Oh, você pode me vencer 1/10 vezes ou até 1/5. Mas, no total, ano após ano, à medida que as chances se acumulam, os codificadores de caubói custam mais do que você ganha.
Thomas
11
@ Thorbjørn Ravn Andersen, @ hotpaw2 - Há outra dinâmica em jogo aqui. Um codificador que esteja disposto a usar, se não buscar ativamente, técnicas de risco, mesmo quando esses riscos são desnecessários, em geral fará escolhas mais arriscadas em outros lugares. Ou seja, sua escolha contra o controle de fonte é indicativa de um padrão de comportamento mais arriscado que acabará por morder a eles e a sua empresa. Mesmo em uma aposta, às vezes você pode vencer a casa, mas as porcentagens acabam vencendo.
Thomas
3

Você pode encontrar algumas dicas na minha resposta a Frankly, prefere a codificação de cowboys? O problema é que "codificação de caubói" 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 começar imediatamente a codificar o código, com rapidez e precisão, isso pode ser o sinal de um engenheiro mestre que já o viu milhares de vezes e já sabe a 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" demais não é definitivamente uma abordagem "sênior" ou 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 ela estava completamente errada 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 mais 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 da análise" e produtividade realmente sofrer um impacto visível. Mas a dispensa das ferramentas básicas de nossa atividade , como controle de revisão e testes, é realmente o argumento decisivo para mim; essa pessoa não pertence a um cargo sênior.

Aaronaught
fonte
2

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

Em qualquer coisa pequena, você provavelmente está bem, mas se tiver algo complexo, perigoso, restrito, 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.

Conta
fonte
2

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 isso "não há tal coisa 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 em ambos.

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ódigo). Quando tenho 3 ou 4, estou procurando algum tipo de sistema de itens de trabalho.

MIA
fonte
1

Somente ao prototipar recursos muito simples.

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

Klaim
fonte
1

Eu fiz isso uma vez em um projeto real (na época, chamamos de Samurai Programming, 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, eu 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. Eu quero que rigor e critérios rigorosos sejam impostos às pessoas que desenvolvem o software para equipamentos aviônicos ou biomédicos, por exemplo, 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 justificado.

Randall Schulz
fonte
2
Frequentemente você precisa para resolver o problema, a fim de descobrir como resolvê-lo ...
1

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 mais raramente apontado é que o oposto pode ser igualmente desastroso. Apenas por exemplo, a maioria de nós rotineiramente escreve 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 este, o que muitas vezes é interessante é productizing uma biblioteca para fazer tarefas como este fácil. 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 seus 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.

Jerry Coffin
fonte
1

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 de fazer 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 ter 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? Em última análise, os programadores de cowboys não são jogadores de equipe. Eles podem criar ótimos códigos, mas se a equipe depender deles - é perigoso.

sunwukung
fonte
Sim, e é possível (provavelmente?) Para alguns codificadores de cowboys fornecerem códigos não tão bons.
Bernard Dy
1

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

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

Eran Galperin
fonte
0

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.

CesarGon
fonte
-1: Você também deve agir no melhor interesse de quem está escrevendo seu salário.
Jim G.
@ Jim: eu estou escrevendo o salário. É por isso que tenho a prerrogativa de despedir membros da equipe. Talvez o seu voto negativo tenha sido um pouco apressado. :-)
CesarGon
Somos engenheiros e temos uma responsabilidade com o cliente e os usuários. - Às vezes, o cliente exige uma data de envio rápida. Ênfase: Às vezes, a data de envio rápido não é negociável.
Jim G.
@ Jim: Eu sei disso muito bem, depois de abrir três empresas. Ainda assim, nenhum código de cowboy de todos os tempos, muito obrigado. Como eu disse, temos uma responsabilidade com o cliente e os usuários, e sempre consegui combinar esse compromisso com boas práticas de engenharia e sem cowboys.
CesarGon
0

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 documentação e 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 de cowboys.

Bernard Dy
fonte
0

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.

programmx10
fonte
0

Acho sua postagem interessante. Eu sempre compartilhei opiniões com o seu assunto, e a sensação dela é de 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 fazê-lo 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 ...

Anodeto de Aaron
fonte
Eu concordo, a menos que seja uma solução ad-hoc que nunca precise ser tocada novamente, é importante ter algum tipo de padrão, porque não se trata apenas de "fazê-lo funcionar". -lo
programmx10