O que é "bom gosto" em engenharia de software?

• Gosto técnico é um conceito diferente de habilidade técnica: mesmo alguém muito competente pode ter mau gosto, e alguém com pouca habilidade pode ter bom gosto
• O gosto de um engenheiro de software significa a capacidade de escolher os valores de engenharia adequados ao projeto
• Isso se revela na sensibilidade sobre que tipo de código parece bom/ruim, quais decisões de design são satisfatórias e em quais problemas a pessoa se fixa, refletindo assim o conjunto de valores de engenharia que ela prioriza
• Todas as decisões em engenharia de software são uma sequência de trade-offs; engenheiros imaturos tratam certas abordagens como verdades absolutas, enquanto engenheiros maduros ajustam os valores com flexibilidade conforme o contexto
• Bom gosto é a capacidade de escolher a prioridade entre valores que se encaixam em um projeto específico, enquanto mau gosto aparece como rigidez, como a obsessão por padrões absolutos como "best practices"
• O gosto se desenvolve por meio de experiências em projetos diversos e de uma mentalidade aberta e, no fim, a presença ou ausência de bom gosto aparece no sucesso ou fracasso do projeto

---

A diferença entre gosto técnico e habilidade

• Gosto técnico não coincide necessariamente com alta competência
• Assim como qualquer pessoa consegue distinguir uma comida boa de uma ruim independentemente de saber cozinhar, no software o gosto se forma antes da habilidade
• O gosto do engenheiro aparece conforme o que ele acha que um código "parece bom" ou "parece ruim"
• O tipo de decisão de design que traz satisfação e os problemas aos quais a pessoa dá mais atenção funcionam como parte do gosto
• A habilidade técnica pode crescer com repetição e aprendizado, mas o gosto se desenvolve de forma mais vaga e intuitiva

• Indicadores de gosto em engenharia

  • Sentir que "este código parece bom/ruim"
  • Forte satisfação — ou indiferença — diante de certas decisões de design
  • Problemas de software que continuam incomodando mesmo depois do expediente, em contraste com outros que não incomodam
• Gosto é, em essência, a capacidade de adotar os valores de engenharia adequados ao projeto atual

A distinção entre habilidade e gosto

• Existe a dúvida: o "código que parece bom" precisa necessariamente ser de fato um código melhor?
  • Ex.: quem prefere map/filter valoriza legibilidade e funções puras, enquanto quem prefere for pode valorizar desempenho e extensibilidade simples
  • Isso não é uma questão de certo ou errado, mas de diferenças nos valores priorizados
• Como cada linguagem e cada contexto têm vantagens e desvantagens próprias, uma escolha não é necessariamente melhor do que outra
• Cada engenheiro atribui importância a valores diferentes e, por isso, as preferências variam

O que é gosto em engenharia

• Quase toda decisão em engenharia de software é um equilíbrio entre valores em conflito (trade-off)
• Engenheiros inexperientes tendem a insistir demais no próprio gosto
• Engenheiros maduros percebem os benefícios sob diferentes perspectivas e valorizam a escolha mais adequada à situação atual
• O importante não é decidir se X (tecnologia) ou Y (tecnologia) é melhor, mas julgar se, no projeto atual, as vantagens de X são mais necessárias do que as de Y

• Exemplos de valores de engenharia

  • Resiliency: o sistema continua funcionando bem mesmo com falhas ou problemas de rede?
  • Speed: o desempenho se aproxima do limite teórico, ou há muito trabalho desnecessário?
  • Readability: um novo engenheiro consegue entender e se adaptar rapidamente? As funções são curtas e claras?
  • Correctness: estados incorretos são modelados? Há testes, tipos e assert suficientes? Há até verificação formal?
  • Flexibility: o sistema é fácil de expandir? Mudanças podem ser aplicadas com simplicidade?
  • Portability: ele depende de um ambiente específico? Mudanças no ambiente de implantação são simples?
  • Scalability: com aumento de tráfego de 10x ou 100x, o sistema consegue escalar ou fazer auto scaling? Onde estão os gargalos?
  • Development speed: com que rapidez o sistema pode evoluir? A maioria dos engenheiros consegue trabalhar nele?
  • Além disso, existem vários outros valores, como elegância, modernidade, uso de open source e custo de manutenção
• Nem todos os engenheiros têm o mesmo nível de interesse em cada valor
• Dependendo de quais valores a pessoa considera mais importantes, mudam a linguagem, o framework e os padrões de design que ela usa

Características do mau gosto

• Mau gosto surge quando os valores preferidos pela pessoa não se encaixam no projeto atual
• O problema é a falta de flexibilidade para continuar empurrando para o próprio projeto as vantagens de uma tecnologia ou metodologia específica
• Discursos que sempre apelam para "best practice" mostram falta de julgamento adaptado ao contexto
• Engenheiros inflexíveis podem funcionar bem em certos projetos, mas, quando o ambiente ou o trabalho muda, podem causar problemas sérios

Características do bom gosto

• Bom gosto é a capacidade de escolher bem os valores de engenharia certos de acordo com a situação do problema
• Diferentemente da habilidade técnica pura, isso só pode ser verificado em contextos reais e complexos de projeto
• Se um projeto que adotou decisões de design com as quais a pessoa concordava vai bem, isso permite medir o quanto seu gosto era adequado
• Experiência em projetos diversos e, em certos momentos, uma postura aberta a novos valores são elementos importantes de aprendizado
• Manter a flexibilidade e evitar ideias fixas sobre tecnologias ou métodos ajuda na formação de um bom gosto

Considerações finais

• Bom gosto é tão importante quanto habilidade e pode ser desenvolvido ao longo do crescimento por meio de diversidade, flexibilidade e auto-reflexão
• Algumas pessoas demonstram um gosto excepcional muito além da própria experiência (como prodígios em programação e em outras áreas)

Discussão adicional

• Nos comentários do Hacker News, também houve opiniões céticas sobre a própria existência de "gosto"
• Alguns defenderam que há uma única solução correta para todo problema, mas o autor rebateu que, na prática, múltiplas soluções são possíveis e que, no fim, valores pessoais e contexto orientam a escolha
• Outra opinião apontou que o contexto do cliente e do negócio também faz parte do gosto

[shakespeares]

Parece mais uma tendência ruim que pode ser tóxica para a equipe e o projeto do que algo que simplesmente se descartaria como mau gosto.

[GN⁺]

Comentário no Hacker News

• Já vi engenheiros imaturos se apegarem demais ao próprio gosto, e essa imaturidade também pode existir em engenheiros experientes. Quando eu ajudava amigos com código de trabalhos da faculdade, sentia o impulso de reescrever tudo só porque eu não gostava do código. Mas percebi que isso levaria tempo demais e faria com que eles não entendessem o resultado. Então passei a ajudar fazendo apenas alguns ajustes na abordagem deles, e eles ficaram mais satisfeitos. Essa experiência me apresentou perspectivas diferentes e também melhorou meu próprio código. Acabei sentindo que eu é que devia agradecer aos meus amigos. Até hoje tenho dificuldade de deixar preconceitos de lado, mas tento compreender seriamente o ponto de vista do outro sempre que possível e, às vezes, reconhecer que aquele jeito é melhor. Princípios são, na prática, bastante subjetivos, então se apoiar sempre neles significa uma abordagem preguiçosa, sem pensar seriamente sobre a situação

  • Mesmo quando um engenheiro júnior está fazendo algo de forma ineficiente, eu nunca digo que ele está usando um jeito menos otimizado. Em vez disso, sempre pergunto por que fez assim. No fim de cada conversa, um de nós dois aprende alguma coisa. Ou eu conheço um método novo ou a razão dele, ou ele aprende por que aquilo não funciona no longo prazo. De qualquer forma, essas conversas nunca terminam de forma confrontadora

  • Acho que “bom gosto” surge ao entrar em contato com ótimas APIs e bom código. Código bom você reconhece na hora, e com o tempo deveria conseguir escrever assim também. Mas, no começo da carreira, é difícil ter bom gosto em programação, e experiência por si só também não garante isso, então é preciso fazer um esforço constante para buscar, reconhecer e imitar o bom gosto

  • A solução para se libertar de preconceitos, vieses e rigidez mental é educação e um acúmulo de experiências variadas fora da perspectiva individual. É preciso se esforçar ativamente para entender o mundo a partir da visão de outras pessoas para crescer como pessoa e como profissional e ampliar a própria perspectiva. Como engenheiro com muitos interesses em áreas diferentes, só de saber que existem outras soluções ou outros pontos de vista meu jeito de resolver problemas já muda, e assim encontro soluções melhores do que a primeira abordagem instintiva

  • É por isso que é bom experimentar várias linguagens de programação. Ao desafiar constantemente sua visão atual com uma nova linguagem, surgem sem parar momentos de “ahá”. No começo pode parecer estranho ou errado, mas é preciso aceitar isso como parte do processo até entender completamente o motivo e o funcionamento

  • Excelente comentário. Essa é a mentalidade que aplico às pessoas que contrato ou com quem trabalho. Se o objetivo ou o resultado for alcançado, não é necessário que o processo e os detalhes sigam exatamente o meu jeito. Reconheço que existem várias formas de fazer

• Acho que “bom gosto” na moda não está em cada peça isoladamente, mas em combinar roupas que individualmente podem parecer sem grande significado para criar uma sensação forte e harmoniosa. Eu esperava que o texto fosse nessa direção. Queria ver uma exploração mais profunda de se aquilo que engenheiros de software decidem por gosto realmente pertence ao campo do gosto, e não apenas a trade-offs técnicos. Para falar a verdade, o próprio texto parece um exemplo de mau gosto. Em termos de conteúdo, cada parte é razoavelmente bem escrita, mas o conjunto não cria um “visual” coerente, então o texto parece disperso. Não é um ataque ao autor; acho o tema excelente, e por isso mesmo queria sugerir melhorias

  • Não concordo com a ideia de que uma peça de roupa, por si só, não tenha significado. Roupas têm significado cultural, histórico e simbólico mesmo antes de serem combinadas. Moda é mais do que simples combinação. Além disso, na moda também existem vários trade-offs de produção, uso e combinação

  • O que você quer saber — “como reconhecemos beleza e elegância?” — é tema de filósofos desde a Antiguidade e amplo demais para ser concluído em um único artigo. Christopher Alexander, da arquitetura, explorou isso profundamente, e suas ideias influenciaram bastante a arquitetura de software. Alexander defendia que existe beleza objetiva. Vale ver sua palestra principal na OOPSLA ou a tese de doutorado de Roy Fielding. O termo “valores” citado neste texto aparece organizado de forma mais sistemática como “atributos arquiteturais” na tese de Fielding

  • Curiosamente, eu acho este texto um raro grande ensaio, difícil de encontrar, por tratar o tema com profundidade e de forma sistemática

  • Quero perguntar em que momento, em uma determinada combinação de fatores, o engenheiro realmente demonstra “gosto”, e onde fica esse “domínio do gosto”, distinto de simples trade-offs técnicos. Do meu ponto de vista, muitas decisões acabam sendo tratadas como “trade-offs técnicos, mas impossíveis de provar de forma absoluta, ou com diferenças tão pequenas que na prática não importam”. Ou seja, quando é difícil decidir, deixamos como questão de gosto

  • A maioria dos desenvolvedores em geral tem pouco senso de moda e, por isso, não entende muito bem o que é bom gosto de maneira ampla. E a maior parte das coisas do mundo tech não é nada estilosa ou legal para quem não é da área. Linguagens de programação não são legais. No mundo de desenvolvimento, o ponto de partida já é “não é legal”, e daí só piora. Por exemplo, Rust, C++ etc. entram na categoria “não é legal”, e linguagens funcionais obscuras, Bash, Linux etc. entram na categoria “realmente nada legais”

• Bom gosto é escrever um código poderosamente simples, como se qualquer pessoa pudesse ter escrito

  • Vou compartilhar outro exemplo. Ao desmontar e montar novamente um Dodge Challenger 72, sempre me surpreendo com como esse carro foi feito de maneira simples, direta e incrivelmente boa por um custo baixo. Por exemplo, a alimentação do painel precisa de 5 volts separados da tensão total do carro (10~18V). Para isso há uma espécie de buzzer, usando eletroímã, que abre o circuito acima de 5 volts e o fecha abaixo disso, ligando e desligando rapidamente para produzir uma média de 5 volts. A maioria troca isso por um regulador eletrônico de tensão, mas aí o painel para de funcionar. Na prática, como o painel é mecânico, se não houver esse pequeno ruído nos 5 volts as agulhas travam com frequência; esse 5 volts “grosseiro”, na verdade, evita que elas travem. Se você substitui por algo eletrônico, precisa adicionar “ruído” de propósito. Fico admirado com como um mecanismo mecânico tão simples pode ser excelente tanto em eficácia quanto em simplicidade

  • O verdadeiro valor desse tipo de código simples, mesmo quando economiza manutenção e tempo de trabalho, normalmente não é devidamente reconhecido. Código que pratica o princípio KISS (Keep It Simple, Stupid) muitas vezes é desvalorizado por parecer não ter valor visível. Por isso até existem equipes e organizações que, na prática, só administram complexidade desnecessária

  • Às vezes é bom que um engenheiro consiga fazer algo extraordinário, mas o que realmente importa é o engenheiro que, mesmo quando parece difícil no início, acaba encontrando com frequência a solução comum e simples

  • No balé, tudo o que se ouve é “parece tão fácil!”, mas na realidade eles praticaram dezenas de milhares de vezes para realmente fazer parecer fácil

  • Sempre respeito mais quem consegue resumir algo complexo de um jeito realmente simples. Como nos exemplos de K&R C: claros e elegantes, só queria que deixassem comentários um pouco mais cuidadosos

• A pergunta “dá para entender o código de imediato e fazer onboarding de novos engenheiros com facilidade?” é mais difícil do que parece. Não está claro se “novo” significa alguém com 0, 10 ou 30 anos de experiência. “Legibilidade” também parece um conceito claro para algumas pessoas, mas na prática está em um espectro que vai de 0 ao infinito. As equações de Maxwell são extremamente claras para alguns e totalmente opacas para outros. Por isso, sempre fico na dúvida sobre para quem exatamente vale a afirmação de que “código deve ser fácil de ler”

  • Código fácil de ler é aquele que considera o leitor e minimiza a carga cognitiva. Esse também é o objetivo de abstrações em camadas e de design patterns. Claro que isso varia conforme a especialização do leitor e sua familiaridade com a base de código, então há subjetividade. Mas negar a própria existência da legibilidade só porque ela é subjetiva já é exagero. Não dá para dizer que Ulysses, de Joyce, e The Cat in the Hat, de Seuss, são igualmente fáceis de ler

  • Não concordo com a afirmação de que “legibilidade não é um conceito”. Código ilegível é código que ninguém consegue ler, nem o próprio autor (ou a IA). E código que só o autor consegue ler também não é código fácil de ler

  • As equações de Maxwell eram realmente difíceis na época, mas a forma que conhecemos hoje é resultado do refinamento de pessoas como Heaviside, que melhoraram sua legibilidade

  • Acho que a “legibilidade local” de um trecho isolado de código não significa muita coisa. Se padrões são aplicados de maneira consistente em toda a base de código, então, mesmo que o padrão seja um pouco complexo, o resultado geral ainda pode ser código bastante legível. Complexidade temporária é aceitável se não comprometer a qualidade do código como um todo

  • Legibilidade normalmente serve para reduzir a ‘complexidade acidental’ (accidental complexity). Tanto fórmulas quanto roteiro de filme ou algoritmos complexos ficam difíceis de entender se a notação for ruim. No fim, para a pergunta “o código deve ser fácil de ler para quem?”, minha resposta é: para um engenheiro que entende bem o domínio, conhece o problema, mas ainda não viu aquele código. É parecido com um artigo acadêmico: deve ser legível para o grupo de pesquisadores daquela área. Resumo de No Silver Bullet

• Acho que a metáfora “um engenheiro de mau gosto é como uma bússola quebrada que no fim aponta para a direção errada” explica bem a essência. Esse tipo de pessoa “quebrada de forma previsível” dá para filtrar em entrevistas. Mais perigoso é a “bússola parcialmente quebrada”. Aparentemente ela gira um pouco, mas na verdade está sempre errada exatamente por 127 graus

  • Gostaria de ver um exemplo concreto desse engenheiro “bússola parcialmente quebrada”

• Muitos textos assim confundem duas questões. A primeira é que existem decisões objetivamente ruins, independentemente de gosto ou princípio — por exemplo, buscar em lista com O(n) versus usar um dicionário com O(1). Há casos técnicos com superioridade clara. A segunda é que todo o resto são trade-offs. Se vai usar map-reduce ou um laço comum, basta considerar desempenho, legibilidade, compatibilidade etc. Se há uma razão para escolher uma entre várias opções, tudo bem mesmo que eu pense diferente. O problema é quando a escolha está errada ou quando nem se considerou o trade-off. Aí já é tema de manutenção, e dependendo de desempenho, frequência e contexto talvez nem valha mexer. Se o “porquê” da decisão estiver claro, eu aceito qualquer uma. Não sei se isso pode realmente ser chamado de “gosto”

• O problema deste texto é tratar de forma descontextualizada a ideia de que “cada pessoa valoriza coisas diferentes”. Na prática, um engenheiro deveria ser capaz de perceber aproximadamente quais valores são mais importantes para o problema em questão (= hard constraint). Faz sentido chamar de “gosto” a liberdade restante depois de retirar essas hard constraints. Pensando em um artista, seria a parte em que, além dos materiais e especificações exigidos, ainda restam restrições ou liberdades próprias. O bom gosto em engenharia de software se parece com buscar o máximo de contenção pessoal e o mínimo estético. Para mim, o verdadeiro “mau gosto” é quebrar princípios sem motivo. Em outras palavras, muitas vezes vi gente confundir simplicidade com familiaridade

• O item “valores” no texto se conecta aos atributos de arquitetura de software da tese de doutorado de Roy Fielding. A tese de Fielding é mais conhecida por REST, mas na verdade é uma discussão muito mais ampla e sólida sobre arquitetura de software. Ela ajuda a pensar em termos de vários “atributos arquiteturais” — escalabilidade, legibilidade, manutenibilidade etc. — e, pessoalmente, quero enfatizar como também é importante entender as ‘restrições arquiteturais’

• Engenharia de verdade (Principled engineering) deveria ser o básico. Em cima disso, é possível ter gosto bom ou ruim. O contrário não vale. Se a engenharia em si é ruim, gosto não significa nada. Mau gosto pode atrapalhar a eficiência da engenharia, mas não torna a engenharia impossível. Engenharia, no fundo, serve para sustentar o gosto. Por exemplo, algo pode ser perfeitamente engenheirado e mesmo assim não ter sentido se ninguém precisa ou quer aquilo

• Mau gosto acaba nos levando à situação incerta X que estamos tentando evitar. Para mim, bom gosto é, no fim, preparar uma base sólida e proteções no codebase para as incertezas futuras que virão. É assim que se evita entrar em risco

[gagamel]

Muito bom

[castedice]

O texto original é bom, mas o conteúdo dos comentários também é realmente muito bom.

[edunga1]

Quando se fala em "bom gosto", esse vídeo TED do Torvalds sempre me vem à mente:
https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux

A partir de 14:20, o bom gosto visto pela forma de implementar o código de remoção de um entry em uma linked list

[bakyeono]

Até mesmo uma "decisão objetivamente ruim (por exemplo, busca O(n) em uma lista vs. busca O(1) com um dicionário)" mencionada nos comentários do Hacker News pode precisar ser tomada de forma diferente dependendo do contexto.
Se a consulta for feita apenas uma única vez, o custo de criar uma tabela hash pode ser maior do que fazer uma busca O(n) em uma lista.

[shakespeares]

Bom comentário.