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

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

É isso.

Agora, a razão pela qual as práticas recomendadas são observadas é porque alguns requisitos têm a ver com a capacidade de manutenção, testabilidade, garantias de desempenho e assim por diante. Conseqüentemente, você tem aquelas pessoas irritantes como eu, que exigem coisas como o estilo de codificação adequado. Não é preciso muito mais esforço para cruzar seus T's e pontilhar seus eus, e é um gesto de respeito àqueles 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ê tem que jogar bem com os outros para fazer tudo funcionar, e você tem que minimizar a dívida técnica para que o projeto não desmorone sob seu próprio peso. .

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

Assim, como acontece com tantas coisas no desenvolvimento de software, isso depende.

Há uma sábia e antiga citação: "Não siga os passos dos sábios de antigamente. Procure o que eles procuraram". 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 que você não deve colocar um teste que possa ser repetidamente recalculado 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 correta. No seu exemplo, sabe-se que não há diferença de desempenho e que não pode haver mais de uma dúzia de iterações. Nesse caso, há duas respostas certas, seja para aplicar a regra de qualquer maneira, já que é simples e não vai doer nada e pode ajudar a formar bons hábitos ou ignorar a regra, já que não há diferença de desempenho para se preocupar.

Eu prefiro a primeira resposta certa e você parece preferir a segunda. Você não está errado sobre isso. Eu 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 ajudam você e não têm propósito. Seu não consertar o loop for no exemplo está realmente seguindo uma regra muito boa contra a otimização prematura.

Real programação adequada é sobre seguir boas regras que fazem sentido de uma maneira inteligente.

A maneira correta de ver isso é um retorno decrescente: comparar o benefício adicional de desenvolver o programa com o custo do desenvolvimento adicional.

Diminui os retornos quando o benefício marginal é menor que o tempo / esforço marginal.

Você pode criar um caso de negócios para mover items.length do ciclo for ? Economicamente, essa mudança pode até justificar o tempo gasto tentando justificá-la? Como não há diferença na experiência do usuário, você nunca obterá nada nem mesmo pelo tempo gasto medindo (além de uma lição útil para lembrar). Os usuários não gostarão mais do programa do que eles, e mais cópias não serão vendidas, como resultado dessa mudança.

O tipo de pensamento sobre retornos reduzidos pode ser uma busca por desculpas para não tomar medidas e evitar riscos, o que pode ser uma série de oportunidades perdidas.

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

Quando você não deve se preocupar 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 visualizam a origem antes de pagar)
• MVP / POC - Se escrever o código adequado significa perder tempo com um conceito antes de saber 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, não Ninguém se preocupa com a adequação do código)
• Ao ter uma situação de risco de vida (por exemplo, o protótipo 1 do homem de ferro era um hack sujo, mas o tirou da caverna, certo?)
• ou se você simplesmente não sabe como escrever o código adequado (se alguém consegue ganhar a vida escrevendo código não adequado, no desemprego de hoje, eu digo, melhor escrever código ruim do que ser sem-teto)
• se você simplesmente sabe o que está fazendo ou acha que pode se safar fingindo que faz

Quando escrever o código adequado

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

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

Se assim for, há uma lição fundamental para aprender, e se você fizer isso, você será um dos poucos.

Não tente "pensar" o que você deve fazer para torná-lo mais rápido - isso é uma suposição. Se você está perguntando "Devo usar essa classe de contêineres ou essa?", Ou "Devo colocar length na 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 é suposição. Todo mundo faz isso, mas não funciona.

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

Você vê a diferença?

A sua pergunta é "desde que seja feito o trabalho, não me importo?"

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

Uma vez, aquela coisa que eu escrevi se transformou em "oh, agora todo o departamento do usuário quer usar esse código", que antes eu podia me virar "toda a empresa está usando esse código e agora eu tenho que provar 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. "

Eu percebo que você está "apenas escrevendo um jogo android no seu tempo livre", mas você nunca sabe se esse jogo vai decolar e se tornar o seu bilhete para a fama e fortuna. Pior ainda, esse jogo pode se tornar seu ingresso para a infâmia, porque fica bloqueando os telefones das pessoas. Você quer ser a pessoa que recebe uma oferta de emprego porque as crianças de alguém não podem parar de jogar seu jogo em seus telefones, ou você quer ser a pessoa que é vilificada em fóruns como este?

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

Nunca é importante porque a programação, apropriada ou não, é uma maneira de atingir uma meta, não uma meta em si. Se esse objetivo for alcançado sem uma programação "adequada", tudo bem (do ponto de vista de negócios, geralmente é melhor se o objetivo puder ser alcançado sem programação).

É sempre importante porque a programação adequada é uma ferramenta que irá ajudá-lo a alcançar seus objetivos. A maneira correta de fazer as coisas é simplesmente um reconhecimento de que fazê-lo de outra maneira causa mais dor a longo prazo do que economiza.

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

As ferramentas one off são normalmente executadas da forma mais rápida e suja possível, com pouca ou nenhuma verificação de erros ou outra validação, sem registro de exceções, código cut-n-paste com pequenas alterações ou até mesmo sem alterações em vez de funções genéricas. e assim por diante.

Apenas fique de olho: às vezes, esses aplicativos rápidos e sujos tomam vida própria, o que significa que todos os atalhos o incomodam ...

Or even something trivial like this:

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

I know it evaluates item.length on every iteration. However, I also know items will never be more than 15 to 20 items. So should I care if I evaluate items.length on every iteration?

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

So I guess my question to you is this: Is there a threshold when it no longer >matters to be proper? Is it ok to say - "so long as it gets the job done, I >don't care?"

Isso 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 o Tata Nano e um carro como o Mercedes S "faz o trabalho" - leva você de um lugar para outro. A diferença depende de detalhes: potência do motor, conforto, segurança e outros. É o mesmo com qualquer produto que exista, incluindo produtos de software; por exemplo, por que alguém pagaria à Oracle, IBM ou Microsoft por banco de dados Oracle, DB2 ou MS SQL Server, já que o MySQL e o Postgre são gratuitos?

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

Se você estiver programando em casa para si mesmo, talvez possa cortar alguns cantos; e quando você está experimentando e tentando as coisas isso é completamente justificado.

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

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

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

Se um fabricante de móveis estava fazendo uma peça de mobília para ser usada onde a qualidade não era da maior importância ou onde a qualidade poderia passar despercebida, eles ainda deveriam tentar fazer os cortes, e fazer um bom trabalho juntando-se à pedaços juntos?

Muitas pessoas veem software como artesanato. O que nós construímos não deve apenas executar uma função, ela precisa ser confiável, sustentável, robusta. Fazer tal software requer habilidade, e essa habilidade vem da prática.

Portanto, mesmo que a escolha de uma construção de 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 em todos os momentos, com o tempo, fará de você um programador melhor.