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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Somente ao prototipar recursos muito simples.

Então, uma vez feito e considerado da maneira certa, abandono 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 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.

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.

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.

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.

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.

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.

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

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.

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