Quando a programação “adequada” não importa mais?

Eu tenho construído um jogo android no meu tempo livre. Está usando a biblioteca libgdx , então um pouco do trabalho pesado é feito para mim.

Durante o desenvolvimento, selecionei descuidadamente tipos de dados para alguns procedimentos. Eu usei uma hashtable porque queria algo próximo a uma matriz associativa. Valores-chave legíveis por humanos. Em outros lugares para conseguir coisas semelhantes, eu uso um vetor. Eu sei que a libgdx tem classes vector2 e vector3, mas nunca as usei.

Quando me deparo com problemas estranhos e procuro ajuda no Stack Overflow, vejo muitas pessoas redefinindo as perguntas que usam um determinado tipo de dados quando outro é tecnicamente "adequado". Como usar um ArrayList porque ele não requer limites definidos versus redefinir um int [] com novos limites conhecidos. Ou mesmo algo trivial como este:

for(int i = 0; i < items.length; i ++)
{
    // do something
}

Eu sei que ele avalia item.length em cada iteração. No entanto, também sei que os itens nunca terão mais de 15 a 20 itens. Por isso, devo me preocupar em avaliar itens.length em cada iteração?

Fiz alguns testes para ver o desempenho do aplicativo usando o método que acabei de descrever versus o adequado, siga o tutorial e use os tipos de dados exatos sugeridos pela comunidade. Os resultados: A mesma coisa. Média de 45 fps. Abri todos os aplicativos na guia telefone e galáxia. Não faz diferença.

Então, acho que minha pergunta é: existe um limite quando não importa mais ser adequado? Tudo bem dizer - "desde que o trabalho seja feito, eu não me importo?"

Você escreve um programa para resolver um problema. Esse problema é acompanhado por um conjunto específico de requisitos para resolvê-lo. Se esses requisitos forem atendidos, o problema é resolvido e o objetivo é alcançado.

É isso aí.

Agora, a razão pela qual as melhores práticas são observadas é porque alguns requisitos estão relacionados à capacidade de manutenção, testabilidade, garantias de desempenho e assim por diante. Consequentemente, você tem aquelas pessoas chatas como eu que exigem coisas como o estilo de codificação adequado. Não é preciso muito esforço para cruzar seus T's e pontuar seus I's, e é um gesto de respeito para aqueles que precisam ler seu código mais tarde e descobrir o que ele faz.

Para sistemas grandes, esse tipo de restrição e disciplina é essencial, porque você precisa se comportar bem com os outros para que tudo funcione e minimizar a dívida técnica para que o projeto não caia sob seu próprio peso.

No extremo oposto do espectro estão os utilitários únicos que você escreve para resolver um problema específico no momento, utilitários que você nunca mais usará. Nesses casos, o estilo e as melhores práticas são completamente irrelevantes; você junta a coisa, executa e segue com a próxima.

Então, como em muitas coisas no desenvolvimento de software, isso depende.

Há uma citação antiga e sábia: "Não siga os passos dos sábios da antiguidade. Procure o que eles procuravam". Existem razões para todas as regras de codificação 'adequada'. Saber por que essas regras existem é mais importante do que saber quais são essas regras.

Existe uma regra de que você não deve colocar um teste que possa ser recalculado repetidamente em um loop for como esse. Nos casos em que a regra foi inventada para remediar (onde o desempenho seria realmente diferente), faz sentido. Nesse caso, há apenas uma resposta certa. No seu exemplo, sabe-se que não há diferença de desempenho e que não pode haver mais do que algumas dúzias de iterações. Nesse caso, existem duas respostas corretas, seja para aplicar a regra de qualquer maneira, já que é simples e não prejudica nada e pode ajudar a formar bons hábitos, ou ignorar a regra, pois não há diferença de desempenho com que se preocupar.

Eu prefiro a primeira resposta certa e você parece preferir a segunda. Você não está errado sobre isso. Acho que você está errado em sua idéia do que é a programação 'adequada'. Não se trata de seguir um conjunto de regras selecionadas aleatoriamente que não o ajudam e não têm nenhum objetivo. Você não corrigindo o loop for no exemplo está realmente seguindo uma regra muito boa contra a otimização prematura.

Uma programação realmente adequada é seguir boas regras que fazem sentido de maneira inteligente.

A maneira correta de analisar isso é diminuir os retornos: comparar o benefício adicional do desenvolvimento do programa com o custo do desenvolvimento adicional.

Retornos decrescentes ocorrem quando o benefício marginal é menor que o tempo / esforço marginal.

Você pode fazer um argumento comercial para items.lengthsair do forcircuito? Economicamente, essa mudança pode justificar o tempo gasto tentando justificá-la? Como não há diferença na experiência do usuário, você nunca receberá nada nem pelo tempo gasto medindo (exceto uma lição útil para lembrar). Os usuários não gostarão mais do programa do que gostam e mais cópias não serão vendidas como resultado dessa alteração.

Isso nem sempre é fácil de avaliar, porque os casos de negócios estão cheios de incógnitas e riscos e, portanto, são suscetíveis de serem vítimas de fatores não considerados que só se tornarão óbvios em retrospectiva. As alterações propostas podem ser completamente não triviais, de modo que elas fazem uma grande diferença.

O tipo de pensamento com retornos decrescentes pode significar uma busca por desculpas para não se tomar alguma ação e evitar correr riscos, o que, em retrospectiva, pode revelar-se uma série de oportunidades perdidas.

Mas às vezes é óbvio quando não fazer algo. Se alguma parte do desenvolvimento parece exigir que um milagre econômico ocorra apenas para pagar pelo custo do desenvolvimento (ponto de equilíbrio), provavelmente é uma má idéia.

Quando você não deve se importar com o seu código ser "adequado"

• Se você conseguir responder à meta de negócios e mantê-la ao longo do tempo com pouca sobrecarga. (os usuários não veem a fonte antes de pagarem)
• MVP / POC - Se escrever código adequado significa perder tempo com um conceito antes que você saiba como ganhar dinheiro com ele (se você gastar anos e 45 milhões de dólares escrevendo seu aplicativo e acabar fechando a loja porque não tinha mercado, ninguém se importa com o quanto adequado era o código)
• Quando havia uma situação de risco de vida (por exemplo, o protótipo 1 do homem de ferro era um truque sujo, mas o tirava da caverna, certo?)
• ou se você simplesmente não sabe escrever código adequado (se alguém conseguir ganhar a vida escrevendo código inadequado, no desemprego de hoje, eu digo, é melhor escrever código ruim do que ficar sem-teto)
• se você simplesmente sabe o que está fazendo ou pensa que pode se safar fingindo que faz

Quando escrever o código adequado

• Se houver um impacto comercial significativo, por exemplo, o desempenho afetará a receita ou impedirá as vendas
• Se não for adequado, manter o código se torna um problema comercial (altos custos de manutenção)
• Se você é um programador conhecido que trabalha em um grande projeto de código aberto
• O mesmo para uma grande empresa que contribui com uma biblioteca interna para o mundo
• Se você quiser mostrar seu trabalho como portfólio em futuras entrevistas

O desempenho é sua principal preocupação? É isso que você está tentando maximizar?

Nesse caso, há uma lição fundamental a aprender e, se você o fizer, será um dos poucos.

Não tente "pensar" o que você deve fazer para torná-lo mais rápido - isso é suposição. Se você está perguntando "Devo usar essa classe de contêiner ou aquela?" Ou "Devo colocar lengthna condição de loop?", Você é como um médico que vê um paciente e tenta decidir qual tratamento dar sem realmente questionar ou examinar o paciente.

Isso é adivinhação. Todo mundo faz isso, mas não funciona.

Em vez disso, deixe o próprio programa dizer qual é o seu problema. Aqui está um exemplo detalhado.

Você vê a diferença?

Sua pergunta é "desde que faça o trabalho, eu não ligo?"

Minha resposta é: "você nunca sabe o que acontecerá com o seu código". Eu estive envolvido em muitos projetos que começaram como "ei, deixe-me escrever uma coisa rápida para cuidar do problema do usuário". Escreva, coloque lá fora, nunca mais pense nisso.

Uma vez, aquilo que escrevi se transformou em "ah, agora todo o departamento do usuário quer usar esse código", que antes que eu pudesse me virar se tornou "toda a empresa está usando esse código e agora tenho que provar que ele sobreviverá a uma auditoria" e há uma revisão de código de 20 pessoas agendada para amanhã e algum vice-presidente já a vendeu para nossos clientes ".

Sei que você está "apenas escrevendo um jogo Android no seu tempo livre", mas nunca se sabe se esse jogo decolará e se tornará seu bilhete para a fama e a fortuna. Pior ainda, esse jogo pode se tornar seu ingresso para a infâmia, porque continua batendo nos telefones das pessoas. Você quer ser a pessoa que recebe uma oferta de emprego porque os filhos de alguém não podem parar de jogar seu jogo em seus telefones ou quer ser a pessoa que é difamada em quadros de mensagens como este?

A resposta é que isso nunca importa, e sempre importa ...

Isso nunca importa, porque a programação, adequada ou não, é uma maneira de atingir um objetivo, não um objetivo em si. Se esse objetivo for alcançado sem uma programação "adequada", tudo bem (do ponto de vista comercial, geralmente é melhor que o objetivo possa ser alcançado sem programação).

Sempre importa, porque a programação adequada é uma ferramenta que o ajudará a alcançar seus objetivos. A maneira correta de fazer as coisas é simplesmente o reconhecimento de que fazê-lo de outra maneira causa mais dor a longo prazo do que economiza.

O que responde à pergunta de quando você pode ignorá-lo - quando você tem certeza de que outra maneira será mais fácil a longo prazo (possivelmente porque não haverá longo prazo).

Normalmente, as ferramentas únicas são feitas da maneira mais rápida e suja possível, com pouca ou nenhuma verificação de erro ou outra validação, sem registro de exceções, código cut-n-paste com pequenas alterações ou mesmo sem alterações, em vez de funções genéricas, etc. .

Cuidado: às vezes, esses aplicativos rápidos e sujos ganham vida própria, o que significa que todos os atalhos te mordem no ...

Ou mesmo algo trivial como este:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

Eu sei que ele avalia item.length em cada iteração. No entanto, também sei que os itens nunca terão mais de 15 a 20 itens. Por isso, devo me preocupar em avaliar itens.length em cada iteração?

Na verdade, no código final, items.length não será avaliado em todas as iterações porque o compilador a otimiza. E mesmo que não fosse, length é um campo público no objeto array; acessá-lo não custa.

Então, acho que minha pergunta para você é a seguinte: Existe um limite quando já não importa> para ser adequado? Tudo bem dizer - "desde que o trabalho seja feito, eu não me importo?"

Realmente depende do que você espera do seu produto final; a diferença entre um produto médio e um ótimo produto depende de detalhes. Um carro como Tata Nano e um carro como Mercedes S "fazem o trabalho" - levam você de um lugar para outro. A diferença está nos detalhes: potência do motor, conforto, segurança e outros. É o mesmo com qualquer produto existente, incluindo produtos de software; por exemplo, por que alguém pagaria ao banco de dados Oracle, IBM ou Microsoft for Oracle, DB2 ou MS SQL Server, já que o MySQL e o Postgre são gratuitos?

Se você deseja prestar atenção aos detalhes e obter um produto de alta qualidade, deve se preocupar com essas coisas (e com outras coisas, obviamente).

Se você está programando em casa, talvez possa cortar alguns cantos; e quando você está experimentando e testando coisas, isso é completamente justificado.

No entanto, tome cuidado. No exemplo que você dá, não há realmente nenhuma necessidade de cortar esse canto, e você precisa ter cuidado. Isso pode iniciar uma tendência e os maus hábitos que você faz em casa podem se infiltrar no seu código no trabalho. É muito melhor praticar e melhorar os bons hábitos em casa e deixá-los penetrar no seu código no trabalho. Ajudará você e ajudará outros.

Qualquer programação que você faz e qualquer pensamento sobre programação é exercício. Faça valer a pena, caso contrário ele voltará e morderá você.

Olhe para o lado bom embora. Você perguntou sobre isso, então talvez você já esteja ciente do que estou dizendo.

Se um fabricante de móveis estivesse fabricando um móvel a ser usado onde a qualidade não era de extrema importância ou onde a qualidade pudesse passar despercebida, eles ainda deveriam tentar corrigir os cortes e fazer um trabalho adequado unindo as peças?

Muitas pessoas vêem o software como habilidade. O que construímos não deve apenas executar uma função, ele precisa ser confiável, sustentável e robusto. Fazer esse software requer habilidade, e essa habilidade vem da prática.

Portanto, mesmo que a escolha de uma construção em loop para o que você está trabalhando hoje possa não importar, o fato de você se esforçar para usar as construções adequadas o tempo todo fará com que, com o tempo, você seja um programador melhor.