Comment les équipes de développement peuvent-elles empêcher un ralentissement des performances dans les applications grand public?


32

Lorsque j'ai demandé précédemment ce qui est responsable des logiciels lents, quelques réponses que j'ai reçues ont suggéré que c'était un problème social et de gestion:

Ce n'est pas un problème technique, c'est un problème de marketing et de gestion ... En fin de compte, les chefs de produit sont chargés d'écrire les spécifications de ce que l'utilisateur est censé obtenir. Beaucoup de choses peuvent mal se passer: le chef de produit ne met pas la réponse du bouton dans la spécification ... nous les programmeurs ne pouvons pas compenser cela. - Bob Murphy

Les gens travaillent sur des applications de bonne taille. Au fur et à mesure qu'ils fonctionnent, des problèmes de performances se glissent, tout comme les bogues. La différence est - les bogues sont "mauvais" - ils crient "trouvez-moi et corrigez-moi". Les problèmes de performance restent là et s'aggravent. Les programmeurs pensent souvent "Eh bien, mon code n'aurait pas de problème de performances. La direction doit plutôt m'acheter une machine plus récente / plus grande / plus rapide." Le fait est que si les développeurs recherchent périodiquement des problèmes de performances ( ce qui est en fait très facile ), ils pourraient simplement les nettoyer. - Mike Dunlavey

Donc, s'il s'agit d'un problème social, quels mécanismes sociaux une organisation peut-elle mettre en place pour éviter d'envoyer des logiciels lents à ses clients?


2
Cela m'a rappelé un blog récent de Jeff Atwood .
rahmu

2
Commentateurs: si vous aimez la question, votez-la. Si vous avez une réponse, veuillez la laisser comme réponse , pas comme commentaire. Sinon, veuillez ne laisser un commentaire que si vous pensez que la question a été clarifiée ou améliorée, ou si vous avez un lien vers une ressource connexe.

Réponses:


34

Avec des exigences correctement écrites et complètes, il n'y a pas de distinction entre les bogues et les mauvaises performances . Parce que vous spécifiez les performances comme une exigence non fonctionnelle, les mauvaises performances deviennent un bogue comme tout autre bogue, et seront détectées par QA et résolues par les développeurs avant la publication.

Y a-t-il un problème social? Je ne pense pas. Le problème majeur est que les exigences sont incomplètes. Travaillant pendant des années en tant que pigiste, je n'ai jamais vu d'exigence non fonctionnelle indiquant qu'une tâche spécifique doit effectuer en N secondes maximum en moyenne. Si le gestionnaire / client / partie prenante ou quoi que ce soit d'autre ne se soucie pas des actifs de performance, pourquoi moi, en tant que développeur, m'en soucierais-je, car les gens qui doivent s'en soucier ne s'en soucient pas du tout?

Il y a un autre facteur qui influence les mauvaises performances: le fait que les développeurs travaillent sur des PC coûteux qui fonctionnent bien . Lorsque vous travaillez depuis des années sur un PC quadricœur avec 8 Go de RAM, un SSD haut de gamme, le dernier système d'exploitation, etc., il est très difficile d'imaginer comment votre application s'exécutera sous Windows XP sur un PC double cœur avec 512 Mo de RAM et un vieux disque dur rempli à 90% et non défragmenté depuis des années. Malheureusement, dans certains pays, le dernier cas est celui que nous voyons pour la plupart des consommateurs d'une application. Plus l'écart entre les PC développeurs et les PC grand public est grand, plus il est compliqué pour un développeur de prendre en charge les performances de son application.


2
S'appuyant sur ce commentaire, je pense que la meilleure façon de s'assurer qu'au moins les développeurs (et les testeurs) sont bien conscients de ces problèmes est de les faire TOUJOURS tester sur le matériel plus ancien ou inférieur ou les machines virtuelles . En tant que développeur, il est difficile pour moi de dire ces mots, mais parfois nous ne travaillons pas à résoudre un problème jusqu'à ce que nous le vivions par nous-mêmes. Par conséquent, au moins forcer vos développeurs à tester leurs applications sur des systèmes inférieurs à la moyenne les forcera à trouver des solutions efficaces en raison des mauvaises performances qu'ils connaissent directement.
RLH

3
Je ne suggérerais pas cela quotidiennement, car cela diminuerait la performance globale du département QA et déprimerait les employés travaillant sur des machines lentes. À mon humble avis, mettre des mesures de performance comme exigences suffit, si spécifié correctement (c'est-à-dire sur quelle machine le test de performance automatique doit être fait, avec quelle charge, combien de fois prendre une moyenne, etc.).
Arseni Mourzenko

1
Je travaille à une exigence qui a une exigence de performance formelle (non fonctionnelle). C'est un logiciel critique en temps réel. Les spécifications sont «réponse dans x en moyenne et y dans 95% des cas». Le logiciel est encore lent par rapport à ce qu'il pourrait être, mais nous savons quand améliorer les performances car il devient un défaut, comme toute autre chose que le système fait incorrectement. Laisser les développeurs décider est une très très mauvaise idée. La plupart des développeurs, livrés à eux-mêmes, ont plus d'ingénieurs dans tous les sens, et triplement pour des problèmes de performances.
mattnz

3
Un autre problème avec les performances est que vous ne pouvez pas tester les performances sur autre chose qu'un système trivial jusqu'à ce que l'intégration finale soit terminée, souvent longtemps après que les développeurs de logiciels ont terminé leur travail. Prenez une application de téléphone - fonctionne très bien sur le nouveau téléphone d'usine brillant, car quelques applications téléchargées et la mémoire sont
saturées

2
Le problème ici est que vous n'obtenez JAMAIS "des exigences correctement écrites et complètes". Pas sur une application de n'importe quelle taille ou complexité.
CaffGeek

12

Le problème(?):

  • Le client (ou l'utilisateur final) ne s'en plaint pas (assez)
  • Ainsi, le chef de projet (/ produit) ne considère pas cela comme une exigence
  • Ainsi, le développeur n'a pas le temps de le réparer.

Vous devez commencer au début, éduquer les clients. Mais s'ils achètent l'iPhone au lieu d'un téléphone plus rapide et moins brillant, les développeurs ont raison de consacrer leur temps à l'apparence plutôt qu'aux performances. L'organisation n'est pas le problème.

Bien sûr, certaines choses peuvent aider de toute façon. Attendre des tests automatisés est ennuyeux, donc si vous avez des tests automatisés, les développeurs ont un retour constant sur les problèmes de performances, et ils seront plus susceptibles de le résoudre (en tant que problème technique, pas en tant que fonctionnalité).

Mais vous ne pouvez pas tout faire. C'est optimiser ou ajouter des fonctionnalités, et ceux qui dépensent l'argent décident.

Mais une bonne nouvelle: j'ai remarqué que les applications SaaS / Cloud / Buzzword aident beaucoup ici. Lorsque les utilisateurs choisissent entre quelques applications Web similaires et effectuent des tests en direct au lieu de créer d'abord des listes artificielles de fonctionnalités `` requises '', ils sont plus rapidement influencés par la réactivité, et donc les performances attirent davantage l'attention.


Je le sais très bien, juste un timing +1
mKorbel

8

Malheureusement, je trouve que le plus gros problème est que vous ne pouvez pas tout faire. Vous avez une date d'expédition, et vous savez que c'est lent, mais vous avez besoin de commercialiser les fonctionnalités X, Y, Z.

Dans votre esprit, lent, vous pouvez corriger plus tard, mais l'application fonctionne au moins.

Donc, vous vous souciez de la fonctionnalité et de l'esthétique (car les utilisateurs se concentrent trop souvent sur l'esthétique). La prochaine version vous permettra de corriger les performances.

Mais le PM vous donne juste une liste de fonctionnalités, et pas le temps de corriger les performances.

Et le cercle vicieux continue.


3
Il ne se corrige que lorsque le PM vous donne une "fonctionnalité" nommée "performances améliorées"!
FrustratedWithFormsDesigner

4
Au moment où le PM veut améliorer les performances, la seule vraie façon de le faire est une réécriture :)
Job

Le point clé ici est que pour la plupart des applications grand public, les performances ne sont pas une fonctionnalité qui vend des logiciels. Ce n'est pas quelque chose qui semble brillant dans la liste de contrôle des «choses que ce logiciel fait». Les jeux informatiques sont un brillant exemple de cette pensée. La configuration système requise pour les jeux n'a cessé d'augmenter au fil du temps, ce qui signifie que les nouveaux jeux sont plus lents avec le même matériel que vous aviez auparavant, car un débit d'images plus élevé ne va pas déplacer cette boîte hors de l'étagère, mais des environnements réalistes rendus en temps réel avec des détails fractals sera ...
Malachi

1
+1 Voici où il est vraiment utile d'avoir un concurrent avec de bonnes performances. Lorsque les PM voient cela, ils ont peur et vous demandent de faire quelque chose.
Mike Dunlavey

1
@Chad, la probabilité conditionnelle est élevée, mais celle absolue est faible. Je travaille sur une application qui a commencé comme un programme C 16 bits pour la version Windows "à peine après ma naissance". Avance rapide qu'aujourd'hui et de nombreuses années et des dizaines de programmeurs plus tard, vous avez un mélange de C, C ++, C #, VB.Net et de nombreux fournisseurs SQL. Réécrire certaines parties clés de l'application en F # ne semble pas être une idée terrible maintenant ...
Job

4

Je suis d'accord avec les autres, que nous devrions trouver des moyens de faire en sorte que les développeurs se soucient davantage du problème, comme les faire tester sur du matériel plus lent et avoir des objectifs de performances. C'est très bien, mais vraiment, en ce qui concerne le réglage des performances -

Les gens doivent savoir comment - et ils ne le savent pas

Ils peuvent penser qu'ils le font, mais regardez simplement toutes les questions et réponses liées aux performances sur StackOverFlow et sur ce forum. Il est douloureux de voir combien de personnes font preuve de très peu de bon sens en matière de performances.

Ce n'est pas quelque chose dont il suffit de parler, les gens doivent apprendre en le faisant . La seule fois où ils sont dans ce mode, c'est lorsqu'ils prennent un cours ou apprennent de nouvelles choses à partir d'un livre ou d'un blog.

Donc, la seule façon dont je peux penser pour résoudre ce problème est de mettre la main sur les personnes qui enseignent la programmation et de leur apprendre à le faire.

Le ciel sait, j'ai essayé sur ces forums, comme dans -

Tout le monde peut le faire. Ils ont juste besoin de le faire .


4

Faites de la performance une exigence.


+1: C'est aussi simple que ça. Msgstr "La fonction X doit se terminer en Y millisecondes".

N'oubliez pas de spécifier l'environnement dans lequel il sera exécuté - par exemple, nous avons un NFR qu'il fonctionnerait conformément à une norme lorsqu'il est exécuté sur un réseau avec une latence de 40 ms (c'est-à-dire un WAN). Si vous ne le faites pas, les développeurs présenteront quelque chose qui ne fonctionne bien que sur un superordinateur.
gbjbaanb

2

Écrire du code performant est difficile. Cela nécessite une solide compréhension des concepts tels que le threading, la gestion des événements asynchrones, la mise en cache et la complexité asymptotique. À en juger par les groupes de programmeurs avec qui j'ai travaillé, environ 20 à 40% d'un groupe donné ne comprend pas assez bien ces concepts pour intégrer des considérations de performance dans leur travail quotidien.

Cependant, ces programmeurs sont évidemment toujours utiles à l'entreprise, mais ils sont assignés à des tâches qui ne sont pas considérées comme critiques pour les performances, vous vous retrouvez donc avec un lecteur Blu-ray qui peut lire les flux Netflix sans faille sans laisser tomber aucune image, mais cela prend 30 à 60 secondes. pour ouvrir l'élément de menu qui affiche votre file d'attente.

À moins que vous ne soyez une société de logiciels de pointe qui puisse se permettre de licencier 20% de votre personnel et de les remplacer par des développeurs plus expérimentés (et plus chers), la seule véritable façon de résoudre ce problème est la formation des développeurs et le dépôt de rapports de bogues. Je ne sais pas comment cela se passe dans d'autres sociétés, mais ici, si nous, développeurs, voyons un problème de performance que nous n'avons pas le temps ni la priorité commerciale à résoudre, nous sommes pleinement autorisés à déposer notre propre rapport de bogue à ce sujet. Il faudra peut-être quelques versions pour arriver au sommet de l'arriéré, mais elles sont généralement traitées.


De plus, même les grands programmeurs ont besoin d'excellents outils d'instrumentation et de profilage pour mieux comprendre les problèmes de performances. (Il existe de nombreux paradigmes de programmation avec des caractéristiques de performance qui défient l'analyse de trace de pile.) Ces outils sont généralement disponibles pour les plates-formes Linux dans un style open-source, mais dans les plates-formes propriétaires et personnalisées, ces outils sont souvent refusés aux employés.
rwong

Je suis en désaccord avec le sentiment exprimé. Obtenir un maximum de perf peut être très difficile, mais il y a souvent beaucoup de fruits à suspendre. Il suffit donc de faire un simple profilage (peut-être la technique suggérée par Mike Dunlavey ci-dessus) et d'essayer de résoudre les problèmes évidents. Souvent, cela ira loin.
sleske

2

Si la performance est une exigence, testez-la.

Sinon, Wally peut écrire une boucle infinie et partir tôt "Cela prend du temps". Il peut prétendre.

Votre test d'acceptation de logiciel doit avoir un test d'acceptation détaillé pour diverses caractéristiques de performance de fonctionnement.

Si vous ne le faites pas, vous n'ingérez aucune performance dans le produit.

Les performances (comme la consommation de ressources) devraient être budgétisées pour les sous-systèmes. Ensuite, les tests d'acceptation du sous-système peuvent les vérifier.

Ensuite, vous pouvez tester tôt et souvent les performances. Même les tests unitaires peuvent alors le vérifier.

Alors maintenant, les développeurs l'ont comme critère d'acceptation et peuvent organiser leur approche en fonction de cela.

Là où je travaille actuellement, le test de stress de performance est 2x plus grand que n'importe quel ensemble de données client que nous connaissons. Il casse régulièrement une nouvelle version du produit. Bon test.


2

Je me souviens d'une fois au milieu des années 90 et je passais quelque temps à essayer d'optimiser quelque chose et un collègue m'a dit: "Cela fonctionne sur des pentiums, qui s'en soucie?" ... c'était une révélation. Malheureusement, ce n'était que la pointe de l'iceberg, j'ai entendu cette attitude tout au long de ma carrière - bien que la partie "pentium" ait changé au fil du temps.

La seule façon d'attirer l'attention du développeur moyen est de faire en sorte que le manque de performances soit considéré comme un bug par le client. Selon l'application et le public, cela peut être une tâche facile ou difficile (j'ai vu les deux). Si le public ne se soucie pas des mauvaises performances, les développeurs ne le feront jamais (rapidement, bien, vite - choisissez deux).


2

Mais cela ne devrait pas prendre une lettre de QA pour qu'un programmeur se rende compte qu'un décalage de 3 secondes entre la pression de touche et la réponse est inacceptable

D'accord, ça ne devrait pas. Cela devrait prendre plus que cela: une preuve que le décalage obtenu est pertinent pour les utilisateurs finaux .

Étant donné que vous n'avez fourni aucun contexte, il semble tout à fait possible que le retard dans l'environnement dev / QA soit provoqué par leurs problèmes locaux de lenteur d'accès au disque / mémoire / réseau. Si tel est le cas, votre QA et votre développeur gaspilleront simplement leurs efforts à réparer des choses qui n'ont tout simplement pas d'importance pour les utilisateurs finaux.

S'appuyer sur les développeurs dans les tests de performances est à peu près aussi productif que lancer un dé pour choisir un élément de fonctionnalité à accélérer. Oh, et c'est à peu près aussi fiable que cela - "les développeurs ont généralement une horrible intuition sur l'endroit où les problèmes de performances dans une application seront réellement" ( Brian Goetz ).

  • J'ai été dans un projet où une direction boiteuse a décidé une fois que ses brillants spécialistes du marketing et leurs programmeurs intelligents étaient assez bons pour gérer les problèmes de performance des clients. Quelle grande leçon c'était. Rejeté la libération, six mois d'efforts pour la poubelle et l'entreprise a presque perdu un partenaire stratégique. En fin de compte, ils ont invité des professionnels (experts en analyse comparative, statistiques, UX, optimisation de bas niveau, des trucs comme ça) et des professionnels qui ont corrigé ce gâchis.

tous les programmeurs devraient-ils faire leur propre AQ afin de voir ces problèmes immédiatement?

Le fait que ce soit faisable ne signifie pas que c'est la voie à suivre. Plutôt à l'opposé - d'après mon expérience, c'était l'un des moyens les plus fiables de perdre de la productivité des programmeurs . Presque aussi bon que des réunions sans fin et encore mieux que d'interroger des candidats.

  • En tant qu'ex-testeur, j'ai pensé une fois que cela ne devrait pas être un problème de combiner les activités de développement et d'assurance qualité. Il semblait que la différence entre les tests de développement de routine et l'AQ systématique importerait peu. Je pensais que la séparation dev / QA n'est qu'une tradition dans l'industrie du logiciel. J'ai appris de façon assez difficile que ce n'est pas le cas. La séparation s'est avérée être une question de concentration et de productivité, et assez sérieuse.

S'il y a un problème de performances, donnez-moi simplement une référence et définissez des performances cibles et je ferai de mon mieux pour l'atteindre. Je ne suis pas très bon dans les tests de performances, mais je connais un peu ou deux l' optimisation.


downvoter - vous est-il arrivé de travailler avec des testeurs professionnels couvrant les besoins de l'équipe de développement en QA et en test de performance? Sinon, pensez à l'essayer
moucher

1

Je pense que vous constaterez que 99% du temps, le problème est le fluage de la portée. Avec le dvr par exemple. On pourrait penser que c'est facile mais alors TIVO ou un concurrent introduit une nouvelle fonctionnalité qui est bien reçue. La prochaine chose que vous savez est une nouvelle fonctionnalité sur la plaque. Il peut ou non être compatible avec le produit existant et nous ne refaisons pas le produit existant qui prendra trop de temps. Donc, la fonctionnalité est bloquée et elle aspire les performances. Bien sûr, les données sont là pour obtenir les informations, mais si l'on n'a pas pensé à obtenir ces informations, il y a de fortes chances qu'elles ne soient pas faciles à obtenir. Alors maintenant, il a un processus complexe pour construire ces informations chaque fois que vous vous approchez de la liste des programmes.


1

Ignorer les développeurs qui ne semblent pas s'en soucier ...

Je pense que souvent les développeurs qui travaillent sur le code n'ont pas les outils pour mesurer les performances sur une base continue.

Par exemple, s'il est possible de mesurer le temps de réponse de votre application (par exemple, c'est une application basée sur le Web, ou interroge une base de données, etc.) - Recevez-vous actuellement des notifications (e-mail, SMS, etc.) qui indiquent le "top 10" pire effectuer (ou dépasser un seuil déterminé) des réponses?

Dans de nombreux cas, les développeurs n'obtiennent pas ces informations des déploiements "réels" et, par conséquent, il est très facile d'ignorer les informations que vous ne voyez pas.

Si toutefois, chaque jour / quelques heures, vous recevez un e-mail indiquant que l'écran "x" prend 13 secondes à charger et qu'il exécute la requête SQL suivante, SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...vous feriez mieux de croire qu'un développeur pourrait (et, espérons-le, le ferait) être en train de réparer il.

Ainsi , bien que je voudrais croire que tous les programmeurs font des performances de prendre , je pense sérieusement que le manque de visibilité à la question (s) est souvent le coupable.

Remarque: Je pense que c'est quelque chose que les développeurs devraient demander l'accès à (ou même développer une telle fonctionnalité) et que la direction devrait fournir / financer de tels outils.


1

Pouvez-vous trouver de meilleurs exemples où nous pouvons réellement blâmer les programmeurs? À part Eclipse, et un commentateur a déjà souligné que ce sont les plugins qui le font (ma première installation de chaque nouvelle version d'Eclipse fonctionne comme un éclair, mais quand j'ajoute les autres outils, cela commence à ralentir), vos exemples peuvent ne pas être programmeur et lié au code mais lié à l'environnement.

L'époque où l'on exécutait un programme sur un ordinateur de manière isolée et qui déterminait s'il était «rapide» ou «lent» est révolue. Les autres exemples que vous donnez dépendent de leur environnement - l'encombrement actuel du réseau, si les serveurs principaux sont surchargés, des cartes réseau mal configurées, un câble défectueux, le nombre d'autres personnes l'utilisant à proximité ou des centaines d'autres variables. par exemple. notre hébergeur a facturé un supplément pour les connexions Gigabit du serveur, mais nous avons finalement déterminé que tout cela passait par un ancien pare-feu avec des ports de 10 Mo. Ces problèmes se déplacent et sont difficiles à trouver.

D'accord, il y a beaucoup de choses que les programmeurs peuvent faire (minimiser la bande passante, des astuces d'interface utilisateur qui améliorent la réactivité et montrent les progrès pour donner l'impression qu'elle est rapide). Mais lorsque vous vous déployez dans le monde réel, il y a toutes sortes de circonstances que vous n'apprenez que par l'expérience (et vous regardez vos hypothèses s'effondrer devant vous).


Les exemples que j'ai donnés étaient tous des cas où les performances étaient médiocres dans un environnement purement local - le DVR accuse simplement de naviguer dans le menu des programmes enregistrés localement. iTunes est lent à parcourir les données locales, sans regarder le magasin. Même en "mode avion" - pas de réseau du tout - l'iPhone 3G met tellement de temps à afficher des photos que parfois le chien de garde du système d'exploitation tuera l'application avant de pouvoir la lancer. Tous ces exemples sont des cas où les programmeurs savaient exactement quel matériel ils ciblaient lorsqu'ils ont écrit le code, et l'iPhone, d'autant plus que la situation empirait à chaque mise à jour.
Crashworks

@Crashworks - quelqu'un a supprimé ces exemples de votre question. Pouvez-vous les ajouter à nouveau avec des détails? L'exemple de photo ressemble à quelque chose d'autre qui se passe, comme une dépendance manquante ou il essaie de rechercher quelque chose sur Internet et arrive à expiration. Avez-vous exécuté un débogage pour voir ce qui se passe? Une bonne histoire est lorsque MS a publié HyperV, un critique de VMWare a joyeusement souligné que même s'il l'avait installé le lendemain de sa sortie, il devait télécharger un tas de mises à jour Windows. Pourquoi? le processus d'activation HyperV a réutilisé une DLL IE8. Il existe de nombreux pièges dans les environnements modernes.
2011

1

Combien êtes-vous prêt à payer pour un meilleur logiciel? Combien le marché attendra-t-il un meilleur logiciel? Quel petit cru voudra ajouter à la prochaine version?

C'est un marché à couper le souffle où de nombreux compromis sont faits. Si c'est vraiment de la merde, le marché échouera (ou devrait) échouer. Peut-être qu'il y a suffisamment de clients qui peuvent vivre avec le statu quo?


0

Je pense que la réponse la plus générale à ce problème est également la plus difficile à gérer, à savoir que chaque programmeur doit être attentif aux performances avec tout ce qu'il fait. Je réalise aussi que c'est un peu flic.

Selon la taille du projet et l'équipe correspondante, je pense qu'il peut être très utile d'avoir des programmeurs de performance dédiés.

À titre d'exemple, j'ai travaillé sur une équipe où l'équipe projet (comprenant environ 30 développeurs) avait au moins 2 personnes dédiées à l'optimisation des performances. Cette application particulière était également sujette à des problèmes de performances car il y avait une multitude de composants d'interopérabilité, non seulement sur les services Web, mais également en termes de couches héritées avec divers composants de mappage de données et d'adaptateur.


0

L'expérience de première main est importante. Donnez aux développeurs un ordinateur rapide pour compiler et développer, mais un ordinateur surchargé très lent (comme un certain pourcentage d'utilisateurs peut en avoir) pour exécuter leurs applications. (Cela peut être fait dans des environnements de développement basés sur le cloud / serveur en partitionnant les machines virtuelles ou les serveurs par fonction.) Donnez-leur un téléphone portable avec une batterie à moitié morte et demandez-leur de ne l'utiliser que pendant les premiers jours du test de l'application mobile.

Si les développeurs sympathisent avec le client en ce qui concerne les performances et la durée de vie de la batterie, ils ne considéreront pas les performances comme des spécifications de gestion semi-factices à mettre en bas de la liste des priorités. (Comme dans: "hé, je pensais que c'était une optimisation prématurée" jusqu'à trop tard.)


0

Arrêtez d'acheter les trucs et commentez les mauvaises performances de tous les avis en ligne que vous rencontrez.

Si les appareils se vendent toujours, le logiciel est "assez bon" pour ne pas investir plus de temps et d'argent. Si les mauvaises critiques sur les performances réduisent considérablement les ventes, alors le logiciel n'est "pas assez bon" et doit être réparé.

Les seules mesures qui intéressent un producteur de biens de consommation sont les ventes et le bénéfice par unité.


0

Je suis d'accord que les programmeurs devraient mieux apprendre à maximiser les performances, etc.

Mais je pense que la solution ne donne pas aux programmeurs un matériel presque mourant pour une utilisation quotidienne. À quel point ce sera stressant si votre studio visuel tombe en panne deux fois par jour, il a fallu x secondes pour créer les éléments, y secondes pour ouvrir la solution, z secondes pour changer de fenêtre. Je ne pense pas non plus que c'était très rentable pour l'entreprise, car le matériel est bon marché et le temps des programmeurs est cher.

Étant donné que la prochaine main qui manipulera le code est l'équipe d'AQ (tests), ne serait-il pas préférable de leur enseigner l'importance des performances, d'avoir une norme de ce qui est une norme de performance acceptable, etc. en tant que norme d'entreprise (enfin, dans un monde parfait , la norme de performance doit être conforme aux spécifications, mais cela ne se produit pas très souvent)? (c.-à-d. que la page / l'onglet de changement d'eE d'entreprise devrait se produire instantanément, "la mise à jour de la sauvegarde devrait se produire en x seconde", si c'est une application critique, alors ...). L'ordinateur sur lequel les équipes d'AQ s'exécutent doit être l'ordinateur utilisateur type. (nous ne voulons pas les énerver en leur donnant un 386, mais ne leur donnez pas un quad core avec 8 Go de RAM par exemple). Ne se laisseraient-ils pas aller aux programmeurs s'ils s'énervaient assez avec les performances?

Je pense que le client / chef de projet devrait forcer le programmeur / l'équipe qa / le développeur / le représentant de l'équipe de l'entreprise à faire leur présentation sur le matériel typique le plus bas dont ils disposent. (l'ordinateur le plus faible de l'entreprise par exemple). Si elle est réécrite, ils devront collecter des données sur la vitesse à laquelle il faut effectuer x processus dans l'ancien logiciel et le comparer avec la vitesse à laquelle il est sur le nouveau logiciel (cela pourrait être plus lent, car le nouveau logiciel peut impliquer un processus métier supplémentaire, mais il devrait y avoir une fenêtre acceptable).


-1

Je l'ai déjà dit, mais je le répète: je pense que l'une des meilleures façons de gérer cela est de simplement faire travailler vos développeurs sur du matériel de bord (relativement) de fuite.

Pour votre programmeur type, la plupart des considérations de performances officielles sont secondaires: "est-ce ennuyeux quand j'essaye de l'exécuter?" S'ils trouvent cela ennuyeux, ils vont (au moins essayer) de le réparer. S'ils sont satisfaits de la façon dont cela fonctionne, le mieux que vous obtiendrez sera une tentative timide de réparer. Cela aide également à détecter les problèmes tôt, avant qu'ils ne deviennent beaucoup plus coûteux à résoudre.

Si cela arrive au point où le contrôle qualité doit appliquer des règles auxquelles les développeurs ne croient vraiment pas parce qu'ils pensent que les performances sont adéquates, il est fort probable que la plupart des "correctifs" que vous obtiendrez obtiendront des moyens créatifs de contourner les règles, pas de vrais correctifs qui améliorent la vie de l'utilisateur final.

En même temps, je dois ajouter que j'ai rarement vu cela comme un problème. Si quoi que ce soit, j'ai vu des développeurs passer beaucoup trop de temps à essayer d'améliorer les performances là où je n'avais vraiment pas assez d'importance pour déranger (un péché dont je suis souvent coupable aussi).


1
Il est facile de tomber dans le piège d'être obsédé par des choses qui n'ont pas d'importance, mais si un téléphone portable est livré avec une interface utilisateur si lente que les appels entrants sont envoyés à la messagerie vocale avant que le bouton "Répondre" ne réponde, il est clair que quelqu'un n'a pas amélioré les performances quand il l'a fait matière.
Crashworks

4
Dans ce cas, l'entreprise devrait m'acheter une épée décente, car je vais passer la plupart de mon temps à compiler.
David Thornley

La moitié du problème est qu'il est difficile de tester sur une machine de développement. Les machines de développement ont tendance à être grandes et rapides, donc un développeur peut ne jamais voir le problème. Il est difficile de réparer quelque chose si vous ne voyez pas mesurer (être affecté par) le problème et encore moins comment votre correctif changera le comportement.
Martin York

7
Cela a été suggéré dans un commentaire Slashdot (sur quelque chose) il y a quelques années. La réponse a été: "les développeurs devraient développer sur des machines rapides et tester sur des machines lentes."
user16764

1
@ user16764: On accorde souvent trop peu d'attention aux développeurs pour tester des environnements différents de leur environnement de développement. Ma femme a eu beaucoup de mal à obtenir à la fois un compte administrateur (à développer) et un compte plus limité (à tester), et avant cela, il y avait constamment des problèmes pour mettre accidentellement quelque chose dans un correctif de maintenance qui ne fonctionnerait pas sur un utilisateur ordinaire Compte.
David Thornley
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.