Comment faire la différence entre un logiciel trivial et un logiciel non trivial? [fermé]


11

Alors qu'est-ce qui rend un programme trivial?

«À moins que son logiciel trivial» soit utilisé si souvent dans les discussions de programmation. Je trouve cela très vague dans le sens où je ne peux pas vraiment comprendre si «quelque chose est essentiel parce que son logiciel n'est pas trivial» ou «son logiciel non trivial parce que quelque chose est devenu très essentiel».

Par exemple, beaucoup de fois sur la question des tests unitaires, j'entends «à moins que ce soit trivial, vous aurez besoin d'un test unitaire».


9
À en juger par certains des programmeurs avec qui j'ai travaillé, je dirais que pour eux, la distinction se résumait à "votre code est trivial; mon code ne l'est pas".
PSU

Pourriez-vous fournir une discussion de programmation dans laquelle vous voyez cette citation utilisée? Il semble qu'il y ait différentes interprétations dans les réponses.
Steven Jeuris

Vérifiez la question mise à jour.
NVM

Réponses:


12

Je vais sortir sur un membre ici et dire:

Un programme banal est un programme qui n'a pas d'impact direct sur l'entreprise.

Une entreprise manufacturière considérerait son logiciel de comptabilité comme trivial, mais le logiciel qui contrôle le bras robotique qui déplace l'acier en ébullition est essentiel. Ils peuvent gérer les bugs et le faible taux de support dans le premier, mais pas dans le second. S'il y a un problème, ils ont besoin qu'il soit corrigé maintenant .


Bien qu'une autre réponse ait plus de points, j'aime mieux cette réponse. J'ai posé la question parce que je ne suis pas tout à fait sûr si le travail que je fais est trivial ou non et c'est une façon sûre de déterminer s'il est considéré comme trivial par les «entreprises» ou non. Par exemple. un logiciel trivial peut s'en tirer sans test unitaire et il ne dépend pas vraiment des lignes de code ou de la complexité. Tout ce qui compte est de savoir si c'est essentiel pour l'entreprise ou non.
NVM

+1, bon point. Les Overlords d'entreprise ont parfois des idées très différentes sur ce qui compte comme «trivial». J'en ai ajouté quelques-uns à ma réponse pour refléter cela.
FrustratedWithFormsDesigner

+1 - Je pense que cette réponse décrit le mieux le contexte du terme tel qu'il est appliqué dans la question. L'autre «réponse à un point plus élevé» est exacte, mais uniquement dans un contexte général. Je suis sûr que celui-ci le dépassera dans les votes à mesure que cela sera envisagé.
Joel Etherton

2
Lorsque les développeurs de logiciels disent banale, ils se réfèrent généralement à la complexité du logiciel, pas à l'impact commercial. Un script qui copie certains fichiers de A vers B serait trivial, mais pourrait toujours avoir un impact direct sur les affaires s'il ne fonctionne pas.
JacquesB

16

Je crois que l'intention la plus courante de cette déclaration serait qu'un programme ait les caractéristiques suivantes:

  • C'est petit.
  • Durée de vie courte.
  • Pas besoin d'extension supplémentaire.
  • Un seul développeur.

2
+1, tous ces éléments sont cruciaux. Malheureusement, dans un monde avec des exigences en constante évolution, vous devrez parfois étendre un logiciel "trivial" au-delà de sa durée de vie naturelle.
l0b0

1
Petit en termes de LOC, petit en termes de taille binaire compilée, petit en termes de temps nécessaire pour le développer? En outre, je dirais que la courte durée de vie n'implique pas triviale et triviale n'implique pas la courte durée de vie. J'ai vu des cas où un logiciel avec une durée de levage de seulement 6 mois était en développement depuis au moins deux fois plus longtemps et était un système de pont crucial. J'ai vu des systèmes de conversion de données qui ont été utilisés une seule fois, mais qui étaient en développement depuis plus d'un an et étaient loin d'être anodins. Et les programmes triviaux comme le démineur semblent avoir une très longue durée de vie.
FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner: petit comme dans, une fenêtre de cours de 100x100px. ; p Je veux dire, petit comme dans les lignes de code qui doivent être écrites, ce qui est proportionnel au temps nécessaire pour le développer. La durée de vie n'est pas essentielle, vous avez raison, mais souvent une caractéristique lorsque vous discutez d'une approche plus avancée par rapport à une approche simple.
Steven Jeuris

Je ne serais pas d'accord que le faible LOC implique toujours trivial. Parfois, la partie la plus compliquée d'un programme, la partie la plus difficile à comprendre, les algorithmes les plus délicats, tiennent dans <20 lignes de code. Et un programme qui se compose principalement de centaines de lignes de getters / setters générés automatiquement - est-il alors non trivial même s'il n'a même pas besoin d'un développeur pour le créer?
FrustratedWithFormsDesigner

1
@FrustratedWithFormsDesigner: Je pense que vous avez une interprétation de la question différente de la mienne. Ma réponse concerne le fait de décider entre une solution triviale et une solution complexe. Votre réponse concerne les problèmes «difficiles» vs «faciles» à résoudre. Peut-être que la question du PO devrait être clarifiée un peu.
Steven Jeuris

14

En le jetant complètement, les binaires et les sources. Si quelqu'un le remarque, ce n'était pas anodin.


6
+1 Cela m'a fait rire et cela a aussi du sens.
NVM

8

Trivial est ...

  • quelque chose qui existe déjà, alors pourquoi réinventer la roue?
  • quelque chose qui peut facilement être construit en scriptant quelques autres programmes ensemble ou en écrivant un petit code qui fait un usage intensif des bibliothèques existantes qui font ce qui doit être fait.
  • quelque chose qu'un étudiant de premier cycle CS moyen pourrait faire comme devoir petit à moyen.
  • quelque chose qui a des exigences détaillées qui pourraient facilement tenir sur une serviette cocktail.
  • quelque chose que vous pourriez coder pendant que vous êtes distrait / ivre / en temps libre de 4 ou 5 minutes.
  • quelque chose qui pourrait être créé avec un simple outil de génération de code.

Dans un environnement d'entreprise, j'ajouterais ceux-ci:

  • quelque chose que les utilisateurs professionnels ne craignent pas d'attendre un certain temps pour un correctif.
  • quelque chose utilisé en interne qui n'a pas de support officiel de l'informatique.
  • quelque chose qui est priorisé parmi les priorités les plus basses par l'entreprise, lors de la planification et de la planification des ressources.

4

Je définirais un programme trivial comme un programme qui pourrait raisonnablement être codé:

  • En une fois.
  • En tant que fichier / module unique (en supposant que vous ne programmez pas en Java ou dans un langage qui force un fractionnement très fin des modules).
  • Par n'importe quel programmeur décent de "cric de tous les métiers", plutôt qu'un spécialiste.

3

Voici mes exemples de programmes "triviaux":

  1. Un projet "factice" que j'ai installé et commencé à coder pour que je puisse essayer un morceau de technologie ou un exemple de code. Aucune intention d'être déployé ou même montré à personne.
  2. Code de démonstration écrit pour les présentations techniques.
  3. Un "unique". Je veux dire une application rapide que j'ai dû créer pour utiliser une fois, car c'est une situation étrange de données qui devait être déplacée d'une certaine manière, ou quelque chose qui sera ensuite immédiatement remplacé par quelque chose de plus permanent.

3

Le logiciel Trival n'existe pas, c'est quand vous entendez des exigences et des choses qui seront trivalentes alors qu'en réalité il est toujours non-trival

Voici une citation que j'ai vue sur Usenet il y a dix ans, elle est encore plus pertinente maintenant.

La complexité d'une solution logicielle est inversement proportionnelle à la complexité de l'explication de ce qu'elle doit faire. - Inconnu


-1

Un programme qui n'est qu'un tas de méthodes getter / setter. Pas de logique de programmation. Peut-être quelque chose avec quelques boucles.

Voilà ma définition de trivial.


-1

Notre définition de travail est «quelque chose dont rien d'autre ne dépend».

Malheureusement, il y a eu quelques prototypes triviaux qui sont devenus des produits de production non triviaux.


-3

Je l'ai également entendu utilisé dans le contexte de l'impact du programme sur la planification globale du projet. Si une certaine spécification ne change pas le calendrier de livraison du produit, elle tombe sous l'étiquette de trivial.

Je connaissais un programmeur qui avait tendance à utiliser "trivial" comme synonyme de "Pas même la peine d'être discuté".

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.