Novo estudo sobre o GitHub Copilot encontra “pressão descendente sobre a qualidade do código”
(visualstudiomagazine.com)- O white paper Coding on Copilot, da GitClear, analisa com dados de mudanças de código se o código assistido por IA pode aumentar a produtividade, mas ao mesmo tempo pesar sobre a qualidade e a manutenibilidade
- O code churn, isto é, código revertido ou modificado em até 2 semanas após ser escrito, deve dobrar em 2024 em relação à linha de base pré-IA de 2021
- Após a disseminação do Copilot, aumentou a proporção de código adicionado e de código copiado/colado, enquanto a queda no código movido sugere enfraquecimento de refatoração e reutilização
- Um estudo de 2022 do GitHub concluiu que usuários do Copilot concluíram tarefas 55% mais rápido, mas a GitClear foca mais no custo de manutenção de longo prazo do que na produtividade
- A análise de 153 milhões de linhas de código alterado, escritas entre janeiro de 2020 e dezembro de 2023, indica que líderes técnicos precisam avaliar os efeitos da adoção de IA também por métricas de qualidade de código
A natureza do código assistido por IA segundo o white paper da GitClear
- O white paper Coding on Copilot investiga que diferenças o código assistido por IA apresenta em qualidade e manutenibilidade em comparação com o código que teria sido escrito por humanos
- A pergunta central é se o código assistido por IA se aproxima mais da contribuição cuidadosamente lapidada de um desenvolvedor sênior ou do trabalho fragmentado de um contratado de curto prazo
- A GitClear é uma empresa que vende uma ferramenta de code review baseada em nuvem, e este estudo se concentra em como a composição das mudanças de código se altera após o uso de IA
Sinais negativos observados na manutenibilidade
- A GitClear encontrou tendências preocupantes do ponto de vista da manutenibilidade
- Code churn é a proporção de linhas de código revertidas ou atualizadas em até 2 semanas após serem escritas
- Essa proporção deve dobrar em 2024 em comparação com a linha de base pré-IA de 2021
- A proporção de código adicionado e de código copiado/colado cresce em relação a código modificado, removido ou movido
- Por causa dessas mudanças, o código gerado por IA foi comparado ao de um colaborador itinerante que tende a violar o princípio DRY nos repositórios pelos quais passa
Três mudanças associadas à disseminação do Copilot
- A GitClear destaca churn, código movido e código copiado/colado como mudanças importantes após a adoção do Copilot
-
Aumento do churn
- O “uso do Copilot” é visto como fortemente correlacionado com o envio de código com erros para os repositórios
- Isso está ligado ao fluxo em que código assistido por IA é adicionado rapidamente e depois revertido ou corrigido em pouco tempo
-
Queda do código movido
- A redução do código movido sugere queda em refatoração e reutilização
- Junto com o aumento de código copiado/colado, isso é interpretado como sinal de que as implementações atuais de assistentes de IA não incentivam suficientemente a reutilização de código
- Em vez de promover a criação de código DRY por meio de refatoração, elas oferecem a tentação de repetir código existente com um único toque de tecla
-
Aumento do código copiado/colado
- Código copiado/colado é avaliado como um fator que pesa bastante sobre a manutenibilidade de longo prazo
- Quando linhas de código, e não apenas palavras-chave, se repetem, isso é interpretado como sinal de que não houve tempo para avaliar a implementação anterior
- Quando o código é adicionado novamente em vez de ser reutilizado, futuros mantenedores precisam integrar caminhos paralelos de código que implementam a mesma funcionalidade repetida
Contraste com pesquisas sobre produtividade
- Um estudo de 2022 do GitHub concluiu que desenvolvedores que usaram o Copilot completaram tarefas 55% mais rápido do que aqueles que não usaram
- O mesmo estudo também mediu efeitos positivos além da produtividade, como satisfação do desenvolvedor e preservação de energia mental
- Em contraste com esses resultados de produtividade, o white paper da GitClear analisa principalmente mudanças na composição das alterações de código e na manutenibilidade com o uso de IA
Avaliações divergentes em pesquisas relacionadas
- Exploring the Verifiability of Code Generated by GitHub Copilot: encontrou evidências alinhadas ao consenso da literatura anterior de que o Copilot é uma ferramenta poderosa, mas não deve “pilotar o avião” sozinho
- Assessing the Quality of GitHub Copilot's Code Generation: a análise empírica conclui que o Copilot é uma ferramenta promissora, mas que avaliações mais abrangentes ainda são necessárias
- Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle: à medida que aumenta a proficiência em prompting para IA generativa, forma-se uma ligação singular e difícil de separar entre humanos e IA
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot: os efeitos heterogêneos observados sugerem que um programador em par baseado em IA pode ajudar pessoas a migrar para carreiras em desenvolvimento de software
- Study of software developers' experience using the Github Copilot Tool in the software development process: as opiniões dos desenvolvedores se dividiram; as atitudes foram em geral positivas, mas a intenção real de uso não foi alta, e questões de segurança apareceram como preocupação
Escopo da análise e questões em aberto
- A GitClear coletou e analisou 153 milhões de linhas de código alterado escritas entre janeiro de 2020 e dezembro de 2023
- O estudo também aponta que, com a explosão da popularidade da IA, entramos em uma era em que linhas de código estão sendo adicionadas mais rapidamente do que nunca
- Em 2024, a questão parece ser menos como o Copilot mudará o significado de ser desenvolvedor e mais quem ficará responsável pelo trabalho de limpeza posterior
1 comentários
Opiniões do Hacker News
Usei por 2 meses e cancelei a assinatura. O custo mental de corrigir os erros do vômito de código que vinha em enxurrada era alto demais e, em tarefas não triviais ou relacionadas a SQL, era quase inútil mesmo quando eu colocava primeiro o schema inteiro
Como eu sabia o que queria escrever, era muito menos cansativo escrever diretamente, e era mais fácil corrigir meus próprios erros do que os do bot. Fico preocupado com os juniores que vão ficar soterrados por esse lixo
Uso ChatGPT em vez do Copilot e fico surpreso com a quantidade de coisas que ele consegue fazer, mas ainda assim é difícil chamar de “bom código”. Consigo ler JavaScript, mas nos últimos 14 anos me especializei em iOS e não conheço bem as melhores práticas do lado do navegador, então uso para isso; em geral obtenho código que funciona, mas ainda vejo escolhas ruins ou coisas estranhas
Acho correta a postura de evitar os dois extremos sobre a IA atual: “já acabou” ou “não é nada”. Para o segundo grupo, é preciso uma analogia do tipo: “um cachorro faz malabarismo, declara imposto e assa um bolo, e em vez de se impressionar com o fato de ele conseguir fazer isso, você reclama que ele derrubou as bolas, errou os números e a receita não ficou tão boa”
O Copilot é mais útil como uma ferramenta de autocomplete que reduz digitação ao escrever código previsível baseado em contexto. Se você escreve uma enum class em uma janela, ele consegue autocompletar o uso em outra janela com base no contexto; ao escrever um conjunto de testes unitários, um Tab monta o esqueleto do próximo caso de teste
Especialmente em linguagens dinâmicas, o Copilot complementa bem o IntelliSense
Alguns meses atrás escrevi sobre como a indústria de dublagem/narração inevitavelmente pode ser empurrada para fora por modelos de texto para fala, junto com exemplos de composição tipográfica, encadernação e gravação de partituras: https://news.ycombinator.com/item?id=38491203
Mas, se o próprio desenvolvimento acabar esvaziado assim, não sei bem qual é o estado final. Afinal, foram os desenvolvedores que impulsionaram as substituições do passado. Algum tipo de declínio e colapso social não parece totalmente absurdo
“Parseie este JSON e coloque os campos correspondentes nos lugares certos do banco de dados” é um ótimo caso de uso para escrever SQL com o Copilot. Você poderia usar um plugin de ORM ou middleware, mas para um MVP ou mockup isso é otimização prematura demais
Por outro lado, uso bastante a API do ChatGPT e ela é bem conveniente. Quando escrevi um update SQL que mexia em milhões de linhas, pedi para dividi-lo em lotes e registrar o status após cada lote; quando recebi um 401 ao acessar um feed nuget no Azure DevOps, ele me deu não só a causa, mas também o yaml para corrigir
As duas coisas eu poderia fazer sozinho com um pouco de pesquisa, mas é realmente ótimo não precisar gastar esse tempo pesquisando
Graças ao GPT-4, minha eficiência no trabalho aumentou bastante. Eu crio principalmente apps CRUD simples em PHP para resolver problemas do dia a dia no trabalho e, como não uso frameworks nem estrutura MVC, o código gerado pelo GPT-4 com base em instruções claras é fácil de entender e geralmente funciona de primeira
Normalmente peço para ele alterar um trecho de cerca de 25 linhas de código para adequar uma função específica de relatório; por exemplo, se eu digo para agrupar por X e somar Y nesta página, ele responde com precisão. Depois de um QA e testes rápidos, está pronto; para tarefas de baixa complexidade e instruções claras, é algo que muda o jogo
Esse processo se parece com a forma como um programador sênior quebra uma tarefa em componentes básicos e a entrega a um júnior. Aqui, o GPT-4 faz o papel de um programador júnior de US$ 20 por mês e economiza meu tempo, então pago do meu próprio bolso sem hesitar
Mas, assim como eu perguntava quando criança por que aprender matemática se existe calculadora, agora entendo por que é preciso aprender os fundamentos. Se você não conhece o básico, não consegue usar a ferramenta de forma eficaz. Se o GPT-4 existisse quando eu estava aprendendo PHP, eu não entenderia os fundamentos tão bem quanto entendo hoje. Estou colhendo os frutos de ter aprendido antes de a ferramenta existir
Também não sinto que a qualidade do código seja particularmente menor; às vezes ele até entrega um resultado mais refinado
Acho que boa parte das críticas ainda é prematura, e vejo isso mais como um avanço rangendo que precisa de suporte adicional de infraestrutura. Onde está a integração com linters para impedir resultados que não compilam? E onde está a função que encontra e corrige automaticamente erros de baixa dificuldade?
Também está em aberto qual deve ser a forma dos testes em um ambiente de desenvolvimento com IA generativa e como eles devem mudar. Talvez exista uma forma melhor de maximizar os benefícios de abordagens processuais como TDD ou BDD e reduzir seus custos
Nos últimos 1 ou 2 anos, uma grande mudança tecnológica foi simplesmente jogada em fluxos de trabalho existentes. Com qualquer ferramenta, o resultado vem da combinação entre a capacidade da ferramenta em si e a experiência de quem a usa
A indústria precisa acumular muito mais experiência e sabedoria na integração de IA generativa ao desenvolvimento para termos uma noção do valor líquido real. Acho que serão necessários pelo menos mais 2 ou 3 anos, não por adaptação tecnológica, mas pelo tempo que as pessoas levam para se adaptar
Já vi uma equipe na casa dos 20 anos gerar montanhas de espaguete full-stack em cima de um framework CRUD básico que eu criei. Se você consegue gerar um “MMO framework” em 60 segundos, diminui o incentivo para criar um app de TODO do zero
É parecido com quando usei Firebase antes de aprender os fundamentos relacionais 12 anos atrás, e levei anos para chegar aos fundamentos
Não dá para prever o futuro com precisão, mas acredito que a forma como percebemos qualidade vai mudar
Há um clima de que a tecnologia será a salvação para problemas importantes em todas as áreas ao nosso redor, como carros elétricos, saúde, TI e finanças. Ao mesmo tempo, fica cada vez mais claro que a tecnologia é usada principalmente para fazer crescer mercados, governos, países etc., e que funciona acrescentando mais uma camada sobre abstrações que já vazam. A sensação é de que ela tenta derreter apenas os sintomas, em vez de resolver o problema
Qualidade inclui lentidão, e essa lentidão será necessária porque tratar sintomas tem limites e porque humanos não conseguirão dar conta dos desafios simplesmente continuando a empilhar mais abstrações
Acho errada a ideia de que precisamos ficar mais rápidos. Acredito que não se obtém qualidade tentando resolver problemas por ganhos superficiais, sem entender, como seres humanos, os fundamentos do desafio
LLM é um desastre para a nossa área. Porque ele agrada ao erro do ser humano médio, que quer chegar ao objetivo sem fazer o trabalho de verdade. O trabalho de verdade é aplicar premissas sobre correção e entender o que você está realmente tentando resolver
Felizmente, nem todo mundo está tentando ir mais rápido; algumas pessoas estão reaprendendo os fundamentos, aplicando decisões cuidadosas e afiando pensamentos e ferramentas para criar qualidade que dure
Minha experiência é quase o oposto. Em vez de vasculhar APIs ou bibliotecas bagunçadas bloquear a parte difícil, o LLM deixa dolorosamente claro quando meu raciocínio não está sólido no trabalho significativo
Para fazer algo com um LLM, é preciso escrever; e, para escrever, é preciso pensar. Muitas vezes, o mais útil é formular cuidadosamente em frases o que quero fazer, ser questionado pelo LLM e, nesse processo, encontrar e esclarecer lacunas no meu pensamento, podendo depois revisitar o histórico da conversa
Especialmente no início de um app, quando estou dando forma a ele, isso é muito útil para acompanhar o que eu achava que precisava fazer na época e depois reavaliar se ainda é o caso
Eles ouvem uma apresentação profissional em um clube e voltam para casa tentando imitá-la, mas o resultado acaba sendo uma massa confusa sem fundamentos. Ele enfatizou que é preciso se satisfazer fazendo coisas simples e construir gradualmente uma base mais forte
Essa percepção se aplica quase exatamente ao uso de código gerado por IA
Móveis da IKEA são um bom exemplo. Se você faz um móvel por conta própria, a sensação de estar perto dele é muito melhor do que perto daquelas coisas meio de papelão da IKEA. Mas, na cabeça das pessoas, custo, velocidade e conveniência parecem ser o mais importante
Modelos de IA tiram essa experiência inata e entregam apenas o creme do resultado final. É parecido com assistir pornografia em vez de construir uma relação real e chegar ao sexo
Se usados com inteligência, produtos do tipo Copilot ajudam. Eles cuidam do boilerplate e das partes tediosas, permitindo que a pessoa se concentre no raciocínio pesado
Além disso, ainda é cedo. É cedo demais para julgar, e também não parece que isso vá desaparecer
A metodologia parece interpretar mudanças como suposições ao comparar a atividade de commits de 2023 com anos anteriores, sem saber quanto disso teve envolvimento do Copilot. É uma abordagem bastante instável
Também consta que “a previsão de 2024 executou uma regressão quadrática nos dados existentes com o Assistant gpt-4-1106-preview da OpenAI”, e fico me perguntando se realmente pediram ao GPT para fazer uma regressão com quatro pontos de dados em vez de usar uma ferramenta simples de regressão como sklearn, R ou Excel. Mesmo que tenham feito direito, com quatro dados e considerando a primeira preocupação, o poder de convencimento é fraco
Regressão quadrática soa plausível, mas, com dois pontos de dados, na prática é só “estender a linha”. Por isso, a previsão de 2024 essencialmente tem pouquíssimo significado
Sou o autor do estudo original. Fico contente em ver tanta gente preocupada com a qualidade do código no longo prazo. O aumento, em 2023, de churned code e duplicação, ou seja, código copiado e colado, e a redução de moved code foram maiores do que esperávamos.
Espero que equipes de desenvolvimento e criadores de AI Assistants adotem métricas e incentivos que estimulem código reutilizado em vez de código recém-adicionado. Equipes sob gestores que acreditam que LoC deve entrar na avaliação de desempenho estão especialmente em risco. Segundo uma pesquisa do GitHub, cerca de um terço está nessa situação, e a geração atual de ferramentas de auxílio à programação torna fácil demais apertar Tab, commitar e plantar dívida técnica futura. Como Adam Tornhill disse no Twitter: “o principal desafio da programação assistida por IA é que fica fácil demais gerar em massa código que, para começo de conversa, não deveria ser escrito”.
Dito isso, a significância do estudo atual tem a limitação de não medir diretamente código escrito por IA. Ele apenas traçou a correlação entre qualidade de código e a disseminação de AI Assistants nos últimos quatro anos. Seria ótimo se o GitHub ou outras empresas de AI Assistant colaborassem em estudos posteriores para medir diretamente as diferenças de qualidade entre “código totalmente sugerido por IA”, “código sugerido por IA e modificado por humanos” e “código escrito do zero”.
No próximo estudo, também quero medir diretamente como a frequência de bugs muda conforme o uso de IA. Se houver outras ideias que seria bom medir, aceito sugestões. Estou tentando publicar um novo artigo de pesquisa a cada cerca de dois meses.
Reuso de código pode ser poderoso dentro de uma mesma codebase, mas também já vi isso criar confusão quando atravessa codebases. Pode ser útil ou inadequado e confuso, e o resultado em geral depende do julgamento.
Acho melhor avaliar desenvolvedores pelos resultados do software. Por exemplo, impacto organizacional em relação ao uso de recursos, erros de serviço que não derivam de serviços dependentes ou infraestrutura, e coisas assim.
O programador moderno não é alguém responsável apenas por código; é uma mistura intencional de engenheiro de qualidade/testador, gerente técnico de produto, gerente de projeto, programador, engenheiro de performance e engenheiro de infraestrutura. Não estou tentando desmerecer a pesquisa em si; fico feliz que haja pessoas se importando profundamente com qualidade de código, e acho que precisamos pensar de outra forma sobre avaliação.
Também fico curioso se controlaram outras possíveis explicações, como mudanças na economia de tecnologia.
Esse artigo benchmarkou o desempenho dos LLMs mais populares em tarefas de refatoração de código real, e diz que a IA forneceu refatorações funcionalmente corretas em apenas 37% dos casos.
Programação assistida por IA é de fato útil, mas é preciso manter humanos experientes no loop e definir expectativas realistas além do exagero do marketing.
Meu fluxo de trabalho normalmente é dar uma passada na documentação, criar um protótipo, arrumar um pouco o código, adicionar testes, mover coisas, quebrar, retrabalhar, estudar a documentação, refatorar mais e só então entender o problema o suficiente para jogar fora 80% do código e refazer direito.
Se o Copilot me dá, na etapa de protótipo, um código que funciona o bastante e me faz simplesmente seguir em frente, minha compreensão não se aprofunda o suficiente para estruturar o todo corretamente. Ele me deixa pular 90% do fluxo de trabalho, mas isso tem um preço. Claro que, nas etapas finais do desenvolvimento, o Copilot pode ser muito útil.
Se os resultados do estudo estiverem certos, não me surpreende. Código ruim vem de entendimento insuficiente, e o Copilot não pode ter mais entendimento do que aquilo que eu forneci. Ele pode escrever código melhor que o programador médio, mas o resultado não pode ser melhor que a entrada. Com tanta gente focada em “engenharia de prompt”, não entendo por que se surpreendem quando o “prompt” ruim do VSCode produz resultados ruins.
Na minha experiência, o Copilot é ótimo para ajudar a começar. O código às vezes é bom, às vezes é mediano ou está completamente quebrado.
Ainda assim, é valioso por fazer você começar a pensar. Antes de usá-lo, eu desperdiçava muito mais tempo. Talvez seja porque meus circuitos cerebrais sejam meio peculiares.
Sou júnior e tenho o Codeium instalado no VSCode, mas, na maioria das vezes, ele me distrai muito. Não entendo muito bem por que tanta gente usa esse tipo de assistente
Coisas como o Phind são úteis. Quando acontece algo que não entendo, em uns 60% dos casos ele me ajuda a compreender o problema. É o tipo de coisa que encontra um bug bobo que deixei passar por estar cansado ou distraído
Já o Codeium talvez seja útil para despejar boilerplate de frameworks, mas, na minha pequena experiência com scrapers, pipelines de dados simples e JS+HTML/CSS puro, ficar pulando sugestões é muito irritante. Especialmente porque muitas vezes elas não funcionam, e mesmo quando é por um motivo trivial, como faltar um argumento, no fim ainda preciso gastar tempo depurando
Além disso, em JavaScript existe um estilo comum de encadear métodos e funções anônimas infinitamente, como uma corrente. Eu acho isso muito difícil. Prefiro quebrar linhas e dar nomes a funções e variáveis. As sugestões de código também seguem esse estilo com frequência; imagino que os dados de treinamento sejam assim. Dizem que o Codeium aprende isso, e às vezes de fato aprende
O que mais me preocupa é: sendo júnior, se eu entregar meu código a esse tipo de assistente, como vou aprender? Dar contexto e perguntas ao Phind ajuda a aprender ou pelo menos dá uma direção para eu pesquisar por conta própria na internet, mas não sei como alguém aprende apenas apertando Tab
Alguns dias atrás percebi que muita gente, inclusive desenvolvedores, usa LLMs não como ferramenta para melhorar, mas como substituto do esforço. Isso me parece assustador não só pelo medo de empresas substituírem pessoas, mas também como questão de autorreflexão
Programar não é a paixão da minha vida, mas eu gosto. Porque me permite fazer coisas acontecerem e lidar com complexidade. Se você não entende o que está acontecendo, não consegue criar nada, nem perceber quando a complexidade está prestes a engolir você
Continue assim, e, se não mudar, você vai chegar a um bom lugar. Com certeza está no caminho certo
O ponto importante é que, ao longo da minha carreira, escrevi especificações de API à mão tantas vezes que 1) consegui enxergar os problemas imediatamente e 2) consegui corrigi-los sem ajuda adicional. Foi mais rápido consertar os modelos manualmente do que refinar o prompt
Em uma área que conheço bem, é impressionante ver algo que tomaria a manhã inteira ser feito em 30 segundos. Mas eu não peço para a IA fazer coisas que eu não sei fazer. Em vez disso, converso bastante com ela sobre trade-offs, possíveis problemas de segurança e coisas assim no trabalho em que estou mexendo
Parece um engenheiro júnior com doutorado na linguagem que uso. Não entende muita coisa, mas aquilo que entende parece entender profundamente
Alguns desenvolvedores, especialmente os de JS, adoram chaining mesmo sem nenhum benefício além de manter tudo em uma linha. Isso não é um benefício. Continue como está e não deixe esse idiota de um idiom infectar sua cabeça
O momento em que essa tecnologia impressiona é quando ela acompanha meu estilo e minhas preferências. Ela dá nomes do jeito que eu quero e usa corretamente o método que acabei de escrever, em vez de repetir a implementação
Não usei muito em projetos vazios ou pequenos, mas imagino que, se ela não estiver fortemente inclinada pelo contexto ao redor para o jeito que eu já uso, a experiência pareça bem menos ideal
O maior uso dos assistentes de IA, para mim, foi escrever testes e acelerar mudanças repetitivas do tipo “igual a isto, mas um pouco diferente”. No IntelliJ + GitHub, quando um novo parâmetro precisa ser refletido em vários métodos e arquivos, normalmente basta digitar manualmente as duas ou três primeiras variações e depois resolver com enter + tab. O contexto preenche o restante
O Codeium no VSCode parece ter uma IA menos suficiente, e o plugin também parece escrito de um jeito em que as sugestões e as teclas de aceitar frequentemente atrapalham. Ainda ajuda em tarefas repetitivas, mas menos quando se trata de sugerir como atingir um objetivo
Resolvi tentar criar um clone do Yourls baseado em Django/Python com o ChatGPT. Dei instruções específicas para permitir URLs curtas customizadas e também rastrear tráfego, mas ele não levou isso em conta direito na lógica nem no modelo de dados. Para corrigir depois, tive que alimentá-lo novamente com instruções específicas
Ferramentas de IA são parecidas com um desenvolvedor júnior que faz o trabalho. Só que muito mais rápidas
Se você não sabe o que está fazendo, elas só aceleram a velocidade com que você comete erros
Recentemente eu precisava prefixar aliases de colunas em uma instrução SELECT com o nome da tabela, mas não havia uma funcionalidade para isso, então dei ao ChatGPT a definição do schema e a query e pedi que escrevesse a lista longa de umas 40 colunas selecionadas
Não encontrei uma boa forma de automatizar isso em vários RDBMSs e, embora desse para fazer com regex ou outra manipulação de texto, a abordagem de explicar o problema e receber a saída necessária foi agradavelmente simples
Fora isso, uso LLM como autocomplete. Também tem o efeito de me levar a dar bons nomes a funções, porque, muitas vezes, só com essa informação a LLM já oferece um ponto de partida razoável. É especialmente útil em APIs ou linguagens que não usei muito, quando o problema que encontrei já foi resolvido milhares de vezes. Quase não uso mais StackOverflow
Por isso comprei o Copilot e também uso bastante o ChatGPT. LLMs estão entre as minhas coisas favoritas, junto com bom autocomplete tipo IntelliSense, geração de especificações OpenAPI ou código EF/JPA, migrações de DB/criação de tabelas a partir de modelo ER, contêineres e IDEs inteligentes como as da JetBrains
As empresas vão querer mais código mais rápido, e acho que, nesse turbilhão, sairão menos pessoas que realmente sabem o que estão fazendo
O artigo completo está aqui: https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on...
Mesmo antes de ferramentas de assistência por “IA” chegarem ao mercado, já havia uma reação contra código DRY e, infelizmente, era uma tendência que vinha crescendo quando eu usava o Twitter entre 2019 e 2022
Alguns desenvolvedores mais jovens têm uma atitude em relação a código muito diferente da que aprendi. Demonstram enorme desprezo pelo Gang of Four e por design patterns, e parecem não saber que os frameworks de que gostam estão cheios exatamente desses padrões. Falam com sarcasmo de princípios como DRY e, especialmente, SOLID
Em lugares como o Twitter, quanto mais sarcástica e combativa é a fala contra o outro lado, mais engajamento ela gera. É uma tendência bem preocupante
Também sinto um desprezo enorme pelo que acontece em codebases corporativas. Não importa o que algum guru de SOLID diga: empilhar camadas e mais camadas de indireção com classes não é aceitável. Boas práticas, DRY e SOLID acabam sendo usados apenas como desculpa
O que não suporto é tratar uma lista arbitrária de princípios surgida do pensamento orientado a objetos ao estilo Java como se fosse a verdade da modelagem de software. Também estou cansado da enésima discussão sobre como SOLID deve ser entendido
As pessoas não brigam tanto sobre o teorema CAP porque ele não é um conjunto arbitrário de ideias formando um acrônimo bonito
DRY também pode ser abusado, e a reação é apenas contra a atitude de tratá-lo como algo perfeito
Por exemplo, o princípio importante de DRY não era não repetir código, mas não repetir ideias. Para qualquer conceito em um sistema, idealmente deveria haver uma única fonte da verdade, e ao lidar com esse conceito deveria haver um único lugar a entender ou alterar
Por isso, copiar e colar uma quantidade considerável de código em vez de criar uma abstração significativa costuma ser ruim. Ao mesmo tempo, também é um alerta de que, no momento em que você repete uma ideia, cria uma dívida contínua de manter diferentes representações sincronizadas. Isso se aplica a migrations de banco de dados que definem schemas e classes ORM separadas, a APIs de backend e clientes de frontend, a valores de formulário em UI retained mode e estado interno, e a invariantes de modelo de dados expressas tanto em tipos quanto em testes unitários
Quem se opõe a juntar à força ideias diferentes só porque por acaso têm implementações parecidas não está errado ao dizer que isso se torna um risco de manutenção depois. Mas está atacando um espantalho que nunca foi o ponto original do DRY
O problema agora é onde e quando novos desenvolvedores aprendem corretamente esses princípios. Alguns têm formação acadêmica, mas nem todos, e cursos acadêmicos de CS também não precisam ensinar muitas habilidades práticas de desenvolvimento
Quando comecei, seniors davam treinamento prático e substancial aos juniors, mas, com a cultura atual de trocas frequentes de emprego e a relutância em contratar juniors como investimento de longo prazo, isso parece ter diminuído muito. Cursos formais são caros para indivíduos, mas quase não representam custo do ponto de vista de uma empresa; ainda assim, provavelmente pouquíssimos desenvolvedores novos são enviados por suas empresas
Também há livros que vale a pena ler, mas não sei se pessoas na casa dos 20 anos em 2024 vão querer lidar voluntariamente com esse formato antigo de tinta impressa em pedaços de árvores cortadas. Desenvolvedores em crescimento hoje parecem aprender muitas dessas ideias em blogs e no YouTube, e também há materiais excelentes ali, mas o problema é sempre encontrá-los em meio a lixo mal compreendido ou embalado de forma duvidosa
Então, quando surge uma ferramenta mágica que gera 12 linhas de código mais ou menos funcional no intervalo de um batimento cardíaco, não é surpresa que desenvolvedores jovens achem esse código excelente tendo pouquíssima noção de seus problemas mais profundos. É difícil dizer que a culpa é de alguém, mas claramente é um problema, e seria bom saber o que fazer