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

Sim.

Eu também prefiro deixar minhas meias no chão, onde eu tirei, minha mesa coberta de impressões e embalagens de lanches antigos, minha pia cheia de louça suja e minha cama desfeita.

Eu não considero um período de férias planejado de antemão para ser uma boa férias, uma refeição comido com uma mente em direção a alimentação adequada, ou ficar em trilhas conhecidas caminhadas adequadas.

Eu gosto de me divertir, surpreender-me, aprender coisas novas, cometer erros e nunca ter certeza se vou conseguir voltar. E, às vezes, essa atitude é exatamente necessária para que o projeto seja realizado ...

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

Você está exatamente correto. Essa abordagem de "programação cowboy" pode fazer 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 bugs que você teria tido de qualquer maneira
• É preciso fazer engenharia reversa do código para lembrar o que você fez quando precisou fazer uma alteração em seis meses
• Tempo extra gasto na formação de programadores adicionais que precisam de trabalhar no seu código
• Não ter um log de revisões para olhar para trás 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 mencionou em sua resposta, às vezes você tem que fazer o que tem que fazer. No entanto, como uma prática geral, não, fazer o código o mais rápido possível sem gastar tempo com controle de código-fonte, padrões, documentação, etc. é um péssimo hábito de se entrar.

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

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

Vou lançar algo aqui sobre isso que pode ser realmente impopular: os clientes geralmente querem coisas manipuladas de uma maneira cowboy .

Quer dizer, eles querem que algo seja feito e que alguém pule nele, execute-o e coloque-o lá fora. Nenhum gerenciamento de projetos, 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 alguma coisa lá da próxima vez".

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

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

• Identifique a maneira mais simples de implementar algo rapidamente
• Saiba em que ponto irá quebrar
• Escreva código limpo, legível e simples
• Prever como os usuários vão usá-lo, abusar dele e quebrá-lo
• Escala-o / abstrai-o nos lugares certos, e não vai astronauta de arquitetura nele
• Saiba onde e como lidar com exceções e exceções

Pessoas como essa produzem resultados realmente excelentes com muito pouca sobrecarga de gerenciamento e estrutura, mas são raras.

EDIT: Para referência futura, minha resposta é outro < pergunta, que foi mesclada com essa. Está completamente fora de lugar aqui, mas essa não foi a minha ligação.

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

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

Mas o ponto principal é: Quanto tempo leva o controle de versão?
Se ela não pode ser convencida a investir os 5 segundos de vez em quando, você deve levá-lo ao seu chefe. O controle de versão não é opcional. Ponto final.

E depois de tê-la usando o controle de versão, você pode rastrear facilmente quais bugs ela introduziu. E deixe ela consertá-los. É a bagunça dela, por que você deveria limpá-lo? Se ela acha que sua abordagem é melhor, então deixe ela fazer isso - 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, seja convencendo-a (o que parece improvável), fazendo-a sair (por causa de sua empresa) ou indo embora (por causa de sua sanidade mental). Mas o fracasso dela em primeiro lugar é muito mais provável e definitivamente deveria provar seu ponto. E então ela começará a aderir às práticas recomendadas, como muitas pessoas com muita experiência fazem.

Depende completamente se estou trabalhando sozinho ou em equipe.

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

Mas se eu trabalhar 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 melhorias incrementais e juntam novos sistemas baseados em receitas comprovadas rapidamente (desde que sejam bem lideradas), mas é raro ouvir sobre uma invenção real feita por uma equipe. O trabalho em equipe e os métodos requeridos têm suas virtudes, mas o mesmo acontece com o código de cowboy.

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 passar por páginas de documentação e muitos padrões e paradigmas diferentes. Mas ele também saberá quando poderá fazer tais coisas.

Eu ficaria chocado se ele pegasse um novo problema e começasse a criar um aplicativo que requer meses-homem do zero. Mas se é um plugin, uma 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, o design e os padrões são realmente bons apenas para desperdiçar o tempo.

Além disso, acho que grande parte do design já foi processada em um segmento de segundo plano em algum lugar dentro do chefe de desenvolvimento sênior.

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

Depende das circunstâncias. Por exemplo, depois de alguns desastrosos escândalos comerciais, várias bolsas de valores eletrônicas insistiram em que as bandeiras de negociação automática fossem adicionadas a todos os negócios. E isso tinha que ser para todos os softwares de negociação dentro de uma semana. Quero dizer, tinha que ser feito - se a bandeira não estivesse lá, você não poderia negociar. Em circunstâncias como essa, todas as boas práticas são aceitas - você simplesmente precisa ir (como costumávamos dizer) "hacky, hacky, hacky". E nessas circunstâncias, escrever código com rapidez e precisão é fundamental. Particularmente porque não havia sistemas de teste disponíveis.

Da minha experiência, a codificação de cow boys WITH source control é a melhor e mais livre de erros para desenvolver grandes sistemas de software.

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

Se a pessoa pode produzir um bom produto - algo que faz o que é suposto fazer, e é sustentável e confiável - o que importa se metodologias formais ou processos são seguidos? Os processos são ótimos para garantir um piso em qualidade, mas se alguém já está trabalhando acima desse piso, os processos não adicionam nada à equação. Muitos desenvolvedores hoje em dia parecem acreditar que o ponto da programação é aderir aos processos, em vez de produzir um bom produto.

Esse tipo de pessoa é chamado de hacker, e geralmente não é um termo gratuito do mais profissional entre nós.

Como você percebeu, o tempo economizado em design, organização e controle é perdido na depuração. E muitas vezes em descobrir qual versão do código foi a que foi enviada. Se você puder encontrá-lo em tudo!

Eu acho que esse tipo de pessoa está envolvida demais em si mesma, acha que é boa demais para trabalhar com as 'limitações' que os outros têm que sofrer e, portanto, não se incomodam com eles, e isso perde ainda mais tempo resto da 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, bem abaixo das habilidades e do talento do codificador de mídia).

Então, pode ser uma abordagem comum em outros lugares, mas na minha casa (e eu sou um codificador sênior que tem tendências a essa abordagem, nós) 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 do código-fonte (o que para ser honesto é maldito e útil!)

Kent Beck et al, são todos profissionais que viram que os antigos caminhos carregados de processos eram ruins em si mesmos, então eles criou novas metodologias para organizar a codificação e, ao mesmo tempo, mantê-la mais orientada para o artesanato, e então contou a todos sobre isso - publicando livros (de que outra forma você fez isso antes da Internet?)

Parece que você está certo - não aceite práticas ruins só porque alguém não pode hackeá-lo. Seu chefe de equipe ou gerente deve estar sofrendo com essa 'estrela de rock', mas se eles não forem ... bem, isso ainda não impede que você faça a coisa certa. Apenas não aceite a prática de má qualidade dela, se ela estragar (e ela vai!) Então deixe-a limpá-lo. Você se atém às boas práticas (e você sabe o que elas são) sem deixá-las assumir em detrimento de sua produtividade de codificação, e você será bom para o futuro.

Aqui está um ensaio de um escritor verdadeiramente perspicaz. Isso não resolve o problema, mas dá algumas dicas sobre por que é assim e talvez algumas dicas para lidar com isso profissionalmente.

O único fato importante é o resultado do produto a longo prazo da equipe.

Existe 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 em uma taxa média.

Se o cowboy produz coisas que os programadores regulares não fazem (para um determinado prazo ou especificação), e a equipe com o cowboy ainda tem que passar alguns homens semanas / meses limpando a bagunça do cowboy, eles podem acabar com o melhor resultado mais cedo.

Se a equipe com o vaqueiro não puder limpar (documentar, depurar, integrar, manter) a bagunça, mesmo depois de muitos meses / ano, então qualquer avanço que o vaqueiro tenha criado não daria à equipe uma vantagem de longo prazo. / p>

Decida qual e otimize a lista da equipe.

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

Você pode encontrar algum insight na minha resposta a Francamente, você prefere o código de cowboy? O problema é que "cowboy coding" significa coisas diferentes para pessoas diferentes, e não é imediatamente óbvio, para o olho destreinado, qual versão você está vendo.

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

Ou pode ser o sinal de um amador amador.

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

Os riscos são muito grandes. E se o seu PC morrer durante a noite? Adeus 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 tem que reverter isso? Isso acontece até mesmo 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. Eu estive lá, uma vez, e nunca voltar .

Não há desculpa - leva 10 minutos para configurar um repositório e 10 segundos para fazer um commit. Isso representa talvez 1% do seu tempo total de desenvolvimento. Testes, se você estiver com pressa, podem facilmente ser reduzidos a 20-30 minutos por dia e ainda ser razoavelmente útil.

Não sou fã de metodologias ágeis (observe a maiúscula A), mas às vezes você realmente precisa apenas arregaçar as mangas e começar a escrever o maldito código. Eu vi pessoas e equipes com "paralisia de análise" e a produtividade realmente tem um impacto visível. Mas o descarte das ferramentas básicas de 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.

Sim, mas você precisa reconhecer quando NÃO é necessário.

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

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

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

Fundamentalmente, quando penso em "Ágil", 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 que "não existe 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 há coisas que você precisa fazer em pequenos projetos, e há coisas que você faz em ambos.

Por exemplo, eu não teria mais do que o mais simples dos backlogs de um projeto em que estou trabalhando ... Seria apenas uma lista de tarefas pendentes. Se houver dois de nós, provavelmente 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 item de trabalho.

Somente ao criar protótipos de recursos muito simples.

Então, uma vez feito e considerado o caminho certo, eu deixo o código e fico sério.

Eu fiz isso uma vez em um projeto real (na época chamamos de Samurai Programming, depois da série de desenhos do Samurai Tailor no Saturday Night Live), e para meu espanto, funcionou bem. Claro, o que eu comecei era lixo, então havia pouco risco de piorar.

No entanto, eu sou um "puro" no coração e não gosto do estilo shoot-from-the-hip de desenvolvimento.

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

Em suma, sinto que a quantidade de processo formal que é apropriado depende muito da magnitude (tamanho do código, duração do projeto, número de desenvolvedores, tipos de requisitos, etc.) do projeto. Eu quero rigor e critérios rigorosos a serem impostos às pessoas que desenvolvem o software para equipamentos aviônicos ou biomédicos, por exemplo. Para jogos, por exemplo, há muito menos desvantagem em relação a falhas, portanto, o custo e a carga de práticas de desenvolvimento rigorosas e metódicas não são realmente justificados.

Depende (strongmente) 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 conceitualizar todo o projeto (a maior parte dele de qualquer maneira) sem anotá-lo, desenhar diagramas etc., então provavelmente você estará bem sem esse trabalho extra de documentando tudo que você faz.

Em casos como este, o que é valioso é a produção de uma biblioteca para facilitar tarefas desse tipo. Com isso, o código front-end muitas vezes 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 classificar como obter um programa completo para fazer o que você quer. Considere, por exemplo, o gnu indent com seus 50+ flags diferentes, muitos dos quais interagem de várias maneiras sutis, então as únicas opções razoáveis são: 1) não usá-lo, ou 2) decidir gostar do que ele te dá. em vez de tentar conseguir o que você queria originalmente.

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

Eu sou um programador medíocre, mas sem dúvida consciencioso - minha principal preocupação ao codificar, além de fazer o trabalho, é que estou ajudando quem quer que use o meu código para fazer o seu trabalho. Eu não posso dizer que sempre consegui isso - mas é isso que eu pretendo fazer.