Como diferenciar software trivial e não trivial? [fechadas]


11

Então, o que realmente torna um programa trivial?

'A menos que seu software trivial' seja usado com tanta frequência nas discussões de programação. Acho muito vago no sentido de que não consigo realmente descobrir se 'algo é essencial porque é um software não trivial' ou 'é um software não trivial porque algo se tornou muito essencial'.

Por exemplo, muitas vezes na questão do teste de unidade, eu ouço 'a menos que seja trivial que você precise fazer o teste de unidade'.


9
A julgar por alguns dos programadores com quem trabalhei, eu diria que, para eles, a distinção se resumia a "seu código é trivial; meu código não é".
PSU

Você poderia fornecer uma discussão de programação na qual vê essa citação usada? Parece que existem diferentes interpretações nas respostas.
Steven Jeuris

Verifique a pergunta atualizada.
NVM

Respostas:


12

Vou sair do ramo aqui e dizer:

Um programa trivial é aquele que não afeta diretamente os negócios.

Uma empresa de manufatura consideraria seu software de contabilidade trivial, mas o software que controla o braço robótico que move o aço fervente é crítico. Eles podem lidar com bugs e com baixa recuperação do suporte no primeiro, mas não no segundo. Se houver um problema, eles precisam ser corrigidos agora .


Embora outra resposta tenha mais pontos, eu gosto mais dessa resposta. Fiz a pergunta porque não tenho muita certeza se o trabalho que estou realizando é trivial ou não, e essa é uma maneira certa de descobrir se isso é considerado trivial pelo "negócio" ou não. Por ex. um software trivial pode escapar sem teste de unidade e realmente não depende de linhas de código ou complexidade. Tudo o que importa é se é crítico para os negócios ou não.
NVM

+1, bom ponto. Os senhores corporativos às vezes têm idéias muito diferentes sobre o que é considerado "trivial". Adicionei alguns à minha resposta para refletir isso.
FrustratedWithFormsDesigner

+1 - Penso que esta resposta descreve melhor o contexto do termo conforme é aplicado na pergunta. A outra "resposta de ponto mais alto" é precisa, mas apenas em um contexto geral. Eu tenho certeza que este irá superá-lo em votos, se for considerado.
Joel Etherton

2
Quando os desenvolvedores de software dizem trivial, eles geralmente se referem à complexidade do software, não ao impacto nos negócios. Um script que copia alguns arquivos de A a B seria trivial, mas ainda pode afetar diretamente os negócios se não funcionar.
JacquesB

16

Acredito que a intenção mais comum dessa declaração seria que um programa tivesse as seguintes características:

  • É pequeno.
  • Vida útil curta.
  • Não há necessidade de mais extensões.
  • Apenas um desenvolvedor.

2
+1, tudo isso é crucial. Infelizmente, em um mundo com requisitos em constante mudança, você às vezes precisará expandir software "trivial" além da vida útil natural.
L0b0

1
Pequeno em termos de LOC, pequeno em termos de tamanho binário compilado, pequeno em termos de tempo necessário para desenvolvê-lo? Além disso, eu argumentaria que a vida curta não implica trivial e trivial não implica vida curta. Eu vi casos em que um software com tempo de elevação de apenas 6 meses estava em desenvolvimento pelo menos duas vezes mais e era um sistema de ponte crucial. Vi sistemas de conversão de dados que foram usados ​​exatamente uma vez, mas estavam em desenvolvimento há mais de um ano e estavam longe de serem triviais. E programas triviais como o Campo Minado parecem ter uma expectativa de vida muito longa.
FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner: pequeno como em, é claro, uma janela de 100x100px. ; p quero dizer, pequeno como nas linhas de código que precisam ser escritas, o que é proporcional ao tempo necessário para desenvolvê-lo. O tempo de vida não é essencial, você está certo, mas geralmente é uma característica ao discutir uma abordagem mais avançada versus uma abordagem simples.
Steven Jeuris

Eu discordo que LOC baixo sempre implica trivial. Às vezes, a parte mais complicada de um programa, a parte mais difícil de acertar, os algoritmos mais complicados, se encaixam em <20 linhas de código. E um programa que consiste principalmente de centenas de linhas de getters / setters gerados automaticamente - isso não é trivial, mesmo que ele nem precise de um desenvolvedor para criá-lo?
FrustratedWithFormsDesigner

1
@FrustratedWithFormsDesigner: Acredito que você tenha uma interpretação da questão diferente da minha. Minha resposta está relacionada ao fato de decidir sobre uma solução trivial versus uma solução complexa. Sua resposta está relacionada a problemas 'difíceis' vs 'fáceis' de resolver. Talvez a pergunta do OP deva ser esclarecida um pouco.
Steven Jeuris

14

Jogando fora completamente, binários e fontes. Se alguém percebe, não foi trivial.


6
+1 Isso me fez rir e também faz sentido.
NVM

8

Trivial é ...

  • algo que já existe, então por que reinventar a roda?
  • algo que pode ser facilmente criado com a criação de scripts para alguns outros programas juntos ou a escrita de um pequeno código que faz uso pesado de bibliotecas existentes que fazem o que precisa ser feito.
  • algo que um estudante de graduação em CS médio poderia fazer como tarefa de lição de casa pequena a média.
  • algo que possui requisitos detalhados que podem caber facilmente em um guardanapo.
  • algo que você pode codificar enquanto está distraído / bêbado / no tempo livre de 4 ou 5 minutos.
  • algo que poderia ser criado com uma simples ferramenta de geração de código.

Em um ambiente corporativo, eu adicionaria estes:

  • algo que os usuários empresariais não se importam em esperar um pouco para resolver.
  • algo usado internamente que não possui suporte oficial de TI.
  • algo que é priorizado entre as prioridades mais baixas pela empresa, ao fazer o planejamento e a programação de recursos.

4

Eu definiria um programa trivial como aquele que poderia ser razoavelmente codificado:

  • Em uma sessão.
  • Como um único arquivo / módulo (supondo que você não esteja programando em Java ou em alguma linguagem que force a divisão de módulos super refinada).
  • Por qualquer programador decente "de todos os comércios", em vez de um especialista.

3

Aqui estão meus exemplos de programas "triviais":

  1. Um projeto "fictício" que eu configurei e comecei a codificar para poder experimentar uma parte da tecnologia ou código de exemplo. Nenhuma intenção de ser implantada ou mesmo mostrada a ninguém.
  2. Código de demonstração escrito para apresentações técnicas.
  3. Um "único". Quero dizer, um aplicativo rápido que precisei criar para usar uma vez, porque é uma situação estranha de dados que precisou ser movida de uma certa maneira ou algo que será substituído imediatamente por algo mais permanente.

3

O software Trival não existe, é quando você ouve requisitos e coisas que serão trival quando, na realidade, é sempre não trival

Aqui está uma citação que eu vi na Usenet há uma década, é ainda mais relevante agora.

A complexidade de uma solução de software é inversamente proporcional à complexidade da explicação do que ela deve fazer. - Desconhecido


-1

Um programa que é apenas um monte de métodos getter / setter. Sem lógica de programação. Talvez algo com alguns loops.

Essa é a minha definição de trivial.


-1

Nossa definição de trabalho é "algo em que nada mais depende".

Infelizmente, houve alguns protótipos triviais que se tornaram produtos de produção não triviais.


-3

Também ouvi isso ser usado no contexto do impacto do programa no planejamento geral do projeto. Se uma determinada especificação não altera o cronograma de entrega do produto, ela cai sob o rótulo de trivial.

Eu conhecia um programador que costumava usar "trivial" como sinônimo de "Nem vale a pena discutir".

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.