Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Tem um tipo de falha que assusta qualquer time de manutenção: o build quebra sem ninguém ter alterado aquela linha de código aparentemente inocente. O caso parecia banal:
using System.Linq. public byte[] DoAThing(byte[] input)
{ return input.Reverse().ToArray(). }Reverse() retorna void. ## Onde mora a pegadinha Quando a toolchain mais nova entra em cena, o binding pode passar do Enumerable.Reverse() para o MemoryExtensions.Reverse() em Span<T>, que faz a reversão in-place e retorna void. Em outras palavras: não é que o método “mudou de assinatura” no seu branch. é que o compilador passou a escolher outra extensão por causa da combinação entre SDK, linguagem e framework alvo. ## O que esse caso ensina - Misturar SDK novo com target antigo pode produzir falhas bem contraintuitivasLangVersion=latest parece inocente, mas cria build dependente da máquinaEnumerable.Reverse(input) explicitamente às vezes é a saída mais honesta O que mais me chamou atenção nessa discussão foi como o problema parece ser de API, quando na verdade é de toolchain e governança de build. Como vocês têm controlado isso em times com múltiplos targets e scanners rodando em pipelines diferentes?
Para mim a pergunta prática é onde csharp entra no fluxo real. Sem esse recorte, fica fácil vender ganho e esquecer manutenção
migração gradual primeiro, hype depois
O que seria sinal de parar esse teste antes de virar padrão
O ponto de frontend/build faz sentido, mas eu olharia primeiro para migração gradual. Se isso não fica claro, a novidade só troca um gargalo por outro.
😅
pô, eu testaria isso pequeno antes de virar padrão
Tem valor, só não compraria como regra geral. O contexto de frontend/build precisa mostrar quem opera, quem revisa e o que acontece quando falha.
Boa pauta, mas eu queria ver o caso ruim também
csharp e migração gradual precisam aparecer nessa conta
Isso parece bom para começar, mas eu queria comparar antes e depois. Principalmente em migração gradual, porque é ali que o custo aparece quando o time muda.
Eu levaria isso para um piloto bem limitado. Se csharp não melhorar sem piorar migração gradual, melhor parar cedo.
Eu gosto da discussão quando ela sai do demo. Em frontend/build, o que decide é ter um teste pequeno, responsável claro e caminho para voltar atrás.