S'il y a deux façons d'aborder une tâche, comment choisir entre elles?


11

J'ai un cas d'utilisation spécifique et j'ai trouvé 3 façons de le faire sur Internet, définies pour des cas d'utilisation vagues. Je regarde ces trois-là me demander laquelle appliquer.

J'ai tendance à rester assis sans savoir quoi faire - puis à ne rien faire ... Y a-t-il une bonne façon de choisir? Dois-je les essayer tous?

Pour être plus précis dans un certain contexte, j'essaie de créer un jeu de société très léger où j'ai besoin d'une partie de l'écran sur laquelle je peux faire pivoter la grille du jeu de société, zoomer sur la grille et déplacer des pièces sur cette grille . Je ne savais pas comment faire cela, mais j'ai trouvé des choses en ligne comme Core Animation, Core Graphics, Sprite Kit, et j'ai vu des arguments pour et contre eux - par exemple, le kit Sprite est de haut niveau, mais maintient la fréquence d'images à 60, ce qui est un gaspillage de batterie lorsque rien ne bouge vraiment sur l'écran. Core Animation était une API de niveau inférieur, qui s'oppose aux conseils d'Apple de "prendre le plus haut niveau d'abstraction". Je ne veux pas apprendre 3 choses à utiliser 1. Existe-t-il un moyen de choisir et de me décoller?

Je laisse cette question plutôt vague à dessein, car je pense que cela s'applique à l'ensemble du domaine des logiciels.

Réponses:


16

Vous effectuez une analyse coûts / avantages sur chacune des approches et choisissez l'approche qui présente le rapport avantages / coûts global le plus élevé.

Dans le cas de bibliothèques concurrentes qui remplissent essentiellement la même fonction, la meilleure façon, la plus simple et la plus rapide d'effectuer cette analyse est de dresser de petits prototypes en utilisant chaque bibliothèque. Laquelle préférer devrait alors devenir très claire.

Considérations possibles sur les coûts / avantages pour les bibliothèques:

  • Maintenabilité
  • Facilité d'utilisation
  • Documentation adéquate
  • Courbe d'apprentissage
  • Performance globale
  • Acheter vs construire

... etc. Notez que bon nombre de ces considérations peuvent être quelque peu subjectives.

Qu'il s'agisse d'un passe-temps ou d'une carrière, peu importe. Vous utiliserez (et devriez) utiliser le même processus si vous décidez de poursuivre vos explorations dans une carrière réelle.

Stratégie de prise de décision alternative: choisissez celle que vous aimez.


4
Dans le cas de bibliothèques et d'implémentations tierces, j'ajouterais: le support de la communauté , les versions estables (pas les bêtas, les candidats à la libération ou les instantanés) , la documentation sur le solde
Laiv

6
Obligatoire xkcd: xkcd.com/1445
Sebastian Redl

15

En complément de l'excellente réponse de Robert Harvey, voici mes 2 cents:

Choisissez la seule approche qui semble être le moins d'effort au départ, mais assurez-vous de garder la porte ouverte pour passer à une approche différente lorsqu'il s'avère que la solution que vous avez choisie en premier a trop de problèmes. Et si vous soupçonnez certains problèmes dans certains domaines de votre scénario d'utilisation, assurez-vous de mettre en œuvre ces domaines en premier, afin d'obtenir des commentaires précoces, avant qu'il ne soit trop tard pour revenir sur votre décision initiale.

La façon dont cela fonctionne dépend fortement du cas. Par exemple, si vous avez besoin d'une bibliothèque simple pour accéder à un périphérique externe ou à un certain format de fichier, assurez-vous d'encapsuler tous les accès à la bibliothèque dans une couche de votre application. Cependant, au cas où vous ne seriez pas sûr du cadre à choisir ou du langage de programmation à choisir, une analyse approfondie des coûts / avantages est probablement tout ce que vous pouvez faire.

Parfois, il vaut mieux juste prendre une décision, même si ce n'est que le 2ème meilleur, tant que vous le faites réellement.

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.