Preuve empirique du choix du paradigme de programmation pour résoudre un problème


11

Le wiki C2 a une discussion sur les preuves empiriques pour la programmation orientée objet qui conclut essentiellement qu'il n'y a rien au-delà de l'appel à l'autorité. Ceci a été édité pour la dernière fois en 2008. La discussion ici semble le confirmer : les questions de savoir si OO est obsolète , quand la programmation fonctionnelle est un mauvais choix et les avantages et les inconvénients de l'AOP sont toutes répondues avec les opinions des contributeurs sans s'appuyer sur des preuves.

Bien sûr, les opinions de praticiens établis et réputés sont les bienvenues et précieuses, mais elles sont plus plausibles lorsqu'elles sont cohérentes avec les données expérimentales. Ces preuves existent-elles? Je sais que le génie logiciel basé sur des preuves est une chose, mais puis-je le pratiquer dans ce contexte? Plus précisément, si j'ai un problème particulier Pque je veux résoudre en écrivant un logiciel, existe-t-il un ensemble de connaissances, d'études et de recherches qui me permettraient de voir comment le résultat de la résolution de problèmes tels que Pdépend du choix du paradigme de programmation?

Je sais que le paradigme qui apparaît comme «la bonne réponse» peut dépendre des paramètres auxquels une étude particulière prête attention, des conditions dans lesquelles l'étude reste constante ou varie, et sans doute également d'autres facteurs. Cela n'affecte pas mon désir de trouver ces informations et de les évaluer de manière critique.

Il devient clair que certaines personnes pensent que je recherche une solution "tourner la manivelle" - une machine à saucisse dans laquelle je mets des informations sur mon problème et d'où sort un mot comme "fonctionnel" ou "structuré". Ce n'est pas mon intention. Ce que je recherche, c'est une recherche sur la façon dont - avec beaucoup d'avertissements et d'hypothèses que je ne vais pas aborder ici, mais une bonne littérature sur le sujet - certaines propriétés du logiciel varient en fonction du problème et du choix du paradigme.

En d'autres termes: certaines personnes disent que "OO donne une meilleure flexibilité" ou "les programmes fonctionnels ont moins de bugs" - (une partie de) ce que je demande en est la preuve. Le reste demande des preuves contre cela, ou les hypothèses sous lesquelles ces déclarations sont vraies, ou des preuves montrant que ces considérations ne sont pas importantes. Il existe de nombreuses opinions sur la raison pour laquelle un paradigme est meilleur qu'un autre; y a-t-il quelque chose d'objectif derrière tout cela?


1
la recherche sur le Web pour l' ingénierie logicielle fondée sur des preuves montre de nombreux liens
gnat

@gnat EBSE consiste à résumer systématiquement la littérature et à tirer des conclusions générales sur la manière dont nous pourrions améliorer la pratique. Ma question est de savoir si cette littérature existe; s'il y a assez pour que les revues systématiques ou les méta-analyses soient productives.

Réponses:


12

Pour la prise précédente, voir la révision 1 de cette réponse . Cependant, les commentaires et les modifications à la question clarifient davantage ce que la question cherche et me permettent d'être plus clair.

Oui, l'ingénierie logicielle basée sur des preuves (EBSE) est une chose. Il semble y avoir quelques efforts vers les bases de données EBSE, comme celle-ci à l'Université de Durham et SEED, qui a été lancée par un professeur à Cal Poly . Tous ces efforts, ainsi que ceux discutés dans un certain nombre d'articles qui peuvent être trouvés via le serveur IEEE Xplore ou la bibliothèque numérique ACM(abonnement ou achat requis pour de nombreux articles dans les deux), sont basés sur la médecine factuelle. Ils fournissent une revue de la littérature des données empiriques publiées (observation et expérience). En fait, l'inclusion de la «revue de la littérature» dans une chaîne de recherche sur n'importe quelle recherche de publication donne des informations sur la plupart des sujets - plus de 14 000 visites sur l'ACM et plus de 1 000 sur la base de données IEEE (lorsqu'elle est limitée aux seuls sujets informatiques).

En regardant les types généraux de sujets abordés dans ces bases de données EBSE et revues de littérature, je vois un fil conducteur - ils ont tendance à être indépendants de la technologie. L'accent semble être principalement centré sur les processus et la méthodologie plutôt que sur les outils spécifiques utilisés pour effectuer le génie logiciel.

Donc, ce concept existe en génie logiciel. Le milieu universitaire connaît le concept fondé sur des preuves et peut l'appliquer avec succès au génie logiciel.

Plus précisément, la question porte sur l'application des techniques EBSE à la sélection d'un paradigme semble difficile, en raison du grand nombre de variables impliquées, obligeant à faire des hypothèses ainsi qu'à réduire la capacité de répéter l'expérience ou l'observation. Il est dit juste dans la question - "quel paradigme apparaît comme" la bonne réponse "peut dépendre des paramètres auxquels une étude particulière prête attention, des conditions dans lesquelles l'étude reste constante ou varie, et sans doute également d'autres facteurs" . Bien que cela ne signifie pas qu'étudier quel paradigme est le "meilleur" dans une situation donnée, cela rend toute sorte de revue de la littérature de ces documents incroyablement difficile à compléter et à extraire des informations à travers eux.

Il n'y a certainement pas de solution "tourner la manivelle" pour choisir un paradigme.

Étant donné un paradigme de programmation, vous pouvez trouver des études dans les différentes bases de données universitaires et industrielles sur la façon dont ce paradigme influence divers aspects du développement de logiciels - qualité, défauts, efficacité, etc. - dans diverses conditions spécifiques, allant de la connaissance et de l'expérience du équipe au domaine du problème. Tout document rigoureux doit clairement identifier les conditions dans lesquelles les données ont été collectées et les hypothèses. Le problème devient d'essayer d'isoler les facteurs qui le rendent bon dans chacune de ces conditions.

D'un point de vue académique, certaines déclarations sont faciles à rechercher. Par exemple, l'affirmation selon laquelle le paradigme fonctionnel est bien adapté aux applications qui nécessitent une concurrence provient du théorème de Church-Rosser . Pour cette raison, il est probable qu'un système logiciel écrit dans un langage fonctionnel aura moins de défauts liés à la concurrence que le même système écrit dans un langage procédural ou orienté objet.

Cependant, d'un point de vue pratique, une équipe logicielle ne peut pas toujours utiliser "le meilleur" outil ou technique pour le travail simplement parce que la recherche l'indique. Bien que nous nous efforçons de produire des systèmes logiciels de la plus haute qualité, nous opérons dans les limites des contraintes. Souvent, je vois ces contraintes minimisées (ou même supprimées de l'équation) lorsque je discute de l'efficacité de toute méthodologie.

En tant que praticien, lorsque je suis impliqué dans le choix des technologies à utiliser, j'essaie d'identifier les meilleurs outils possibles. Mais ensuite je me contrains à ce qui est connu et bien compris par l'équipe que j'ai. Pour revenir à mon exemple précédent, si j'ai une équipe qui connaît bien la construction d'applications simultanées en C ++ et aucune expérience en Haskell, cela n'a pas de sens de proposer de construire le système dans Haskell car je ne serai probablement pas en mesure de faire calendrier et contraintes budgétaires, et ma qualité souffrira probablement en raison d'un manque d'expérience dans la chaîne d'outils.

Pour récapituler, le génie logiciel fondé sur des données probantes est généralement une bonne chose qui existe et des analyses documentaires existent et sont facilement disponibles. Cependant, il existe des aspects de l'ingénierie logicielle où l'application d'approches fondées sur des preuves offre peu de valeur. La sélection d'un paradigme de programmation pour un effort de développement à grande échelle en fait partie.

Si vous souhaitez savoir comment l'orientation objet résout la réutilisation ou les défauts de programmation fonctionnelle, vous trouverez facilement des publications à ce sujet. Cependant, je n'ai pas trouvé (et je ne ferais pas confiance à) une publication capable de traiter efficacement la sélection de paradigmes dans le large éventail de projets d'ingénierie logicielle du monde réel.


La section sur l'exhaustivité de Turing ignore les compromis, qui sont ce que je veux voir mis en évidence et comparés. Permettez-moi de donner un exemple précis. Beaucoup de gens me disent que la programmation fonctionnelle est idéale pour éviter les bogues de concurrence. Nous constatons maintenant que Scheme est, comme Pascal, Turing-complete. Il devrait donc être possible d'écrire du code sécurisé pour les accès simultanés. D'accord. Mais c'est génial ? Y a-t-il des avantages à choisir une méthode? Ces avantages peuvent-ils être mesurés?

1
@GrahamLee La confirmation ou le rejet de votre hypothèse nécessite des preuves objectives, qui n'existent pas. Il existe des raisons subjectives de créer un nouveau paradigme et un nouveau modèle de représentation des mêmes capacités de calcul exactes - et cela ne se limite pas aux langages de programmation, mais également à la représentation mathématique sous-jacente de ces langages . Ces raisons objectives incluent le ciblage d'un groupe démographique particulier (mathématicien computationnel versus analyste d'entreprise - leur façon de penser est différente nécessite un paradigme différent).
Thomas Owens

2
@Thomas: votre implication que les pratiques de programmation sont uniquement opaques à la science est particulière. Il y a beaucoup de recherches en cours. Un exemple souvent cité est le groupe de recherche de Lutz Prechelt . Je ne connais pas suffisamment la région pour savoir si quelqu'un a abordé les questions spécifiques de Graham, mais il n'y a aucune raison de croire qu'elles ne sont pas applicables au type de méthodes utilisées par Prechelt et d'autres.
Cris

1
@Chris Je ne pense pas qu'ils soient opaques à la science. Cependant, je crois qu'il y a certaines choses qui, au moment où vous, comme le dit Graham dans la question, ajoutent "beaucoup de mises en garde et d'hypothèses" à la recherche, elles ne sont plus utiles aux praticiens. À ce stade, d'un point de vue pratique, dans les tranchées, il est tout simplement plus efficace de baser vos décisions sur l'histoire et l'expérience. Avoir de bonnes données solides et valides est une très bonne chose. Mais il arrive un moment où il est trop difficile à obtenir ou n'est valable que dans une situation très spécifique qu'il n'est pas utile à l'industrie.
Thomas Owens

1
@Thomas J'en doute. La pratique médicale générale est au moins aussi sensible à la situation et au contexte que le génie logiciel, et, euh, les preuves s'accumulent que le médecin généraliste fondé sur des preuves produit des améliorations mesurables. C'est en grande partie une question de quantité et de qualité de la recherche.
Cris

7

J'ai lu The Art of Unix Programming par Eric S. Raymond. Il contient des informations historiques très intéressantes sur les choses que nous tenons maintenant pour acquises. Il cite quelques bonnes études du logiciel IEEE qui utilisent des preuves empiriques comme la densité des défauts. Cela pourrait être une bonne source si vous recherchez des études de style académique.

Même des techniques comme la modularisation à l'aide de fonctions n'étaient pas toujours une pratique courante. Une de mes citations préférées du livre jusqu'à présent:

Dennis Ritchie a encouragé la modularité en disant à tout le monde que les appels de fonction étaient vraiment, vraiment bon marché en C. Tout le monde a commencé à écrire de petites fonctions et à modulariser. Des années plus tard, nous avons découvert que les appels de fonction étaient encore chers sur le PDP-11 et que le code VAX passait souvent 50% de son temps dans l'instruction CALLS. Dennis nous avait menti! Mais c'était trop tard; nous étions tous accrochés ...

- Steve Johnson

Cependant, il y a vraiment deux problèmes à devenir trop empirique. La première est que la qualité du code est une chose très subjective. Le code peut être terrible et toujours correct. La perception qu'ont les gens d'un paradigme de programmation est une mesure très valable, car le code est écrit pour que les gens lisent autant que pour les ordinateurs, sinon plus.

Le deuxième problème est que 50% des développeurs ont un talent de programmation inférieur à la moyenne. Peu importe si votre développeur principal est plus productif en utilisant la programmation fonctionnelle si le "rabble" a du mal à écrire un logiciel de travail en l'utilisant, sans parler de beaux logiciels bien architecturés. De même avec les langages de programmation TMTOWTDI , votre développeur principal va toujours écrire du code propre et modulaire, mais des codeurs moins talentueux écrivent du bruit de ligne en raison du manque de structure imposée.

C'est pourquoi je pense que la POO a atteint le sommet de la popularité malgré ses lacunes. Ce n'est pas si restrictif qu'il entrave les plus talentueux, mais sa structure offre un moyen concis de communiquer et d'imposer de bons principes de conception aux moins talentueux.

Dans notre ligne de travail, nous avons tendance à évaluer une solution trop basée sur ses seuls mérites techniques. Une entreprise réussie doit également tenir compte du côté humain de l'équation.


"La qualité du code est une chose très subjective", a-t-on convenu - vous devez faire attention à ce que vous mesurez, et la perception est un facteur important. Mais la perception, comme beaucoup d'autres choses, est également malléable: regardez l'augmentation et la baisse et la montée de la programmation fonctionnelle pour voir que ce que les gens pensent de leur façon de travailler n'est pas directement lié à leur façon de travailler. J'ai aussi récemment relu TAOUP. Une partie de ma motivation pour cette question est de voir dans les premières publications des solutions aux problèmes qui sont courants en génie logiciel.

+1, "Le deuxième problème est que 50% des développeurs ont un talent de programmation inférieur à la moyenne." Cette phrase me soulage. C'est mieux que de nombreuses pilules que j'ai essayées :)
NoChance

3

Il existe des concours de programmation qui utilisent un système de notation informatique et vous permettent d'écrire dans différentes langues et de publier toutes sortes de résultats et de choses. Je parie qu'ils ont de bonnes données pour vous. Voici une liste de 8: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

J'imagine que vous pouvez faire des comparaisons significatives de solutions à des problèmes très simples et clairs, comme la somme des carrés ou la série de Fibonacci, ou tracer une ligne droite en utilisant l'algorithme de ligne de Bresenham. La plupart des tâches de programmation du monde réel n'ont pas de tels objectifs clairement définis et chaque langue a ses points faibles. La plupart des avantages d'une langue sont subjectifs. Vous pouvez trouver des données plus significatives en sondant le bonheur du programmeur et du client qu'en comptant des lignes de code ou des nombres de défauts.

Je me souviens que lorsque j'ai passé une demi-journée à écrire l'un de mes premiers programmes Awk, je pensais que cela m'aurait pris une semaine entière pour faire la "même" chose en Java. Mais c'est parce que ma solution Java se serait concentrée sur la robustesse alors que la solution Awk était rapide et sale et nécessitait quelques ajustements manuels sur l'entrée et la sortie et était vraiment jetable quand j'avais fini. Awk et Java sont tous les deux géniaux, mais pas pour les mêmes choses.

Je suppose que ce que je dis, c'est que pour les applications du monde réel, comparer les langues ou les outils de manière significative est extrêmement difficile - le problème des vieilles pommes et oranges. Bonne chance! J'adorerais voir ce que vous découvrirez.


2

J'étudie différentes façons de développer des logiciels depuis plus de 30 ans. Il y a un manque de bonnes preuves publiées sur le choix d'un paradigme.

J'ai rassemblé une grande bibliographie ASCII consultable. Cela comprend de nombreux articles et articles IEEE et ACM. J'étiquette les articles avec le type de preuve fourni. Voici les balises les plus courantes:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

Maintenant, recherchez PARADIGM et comptez les balises

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

Si vous souhaitez creuser plus profondément, http://cse.csusb.edu/dick/lab.html et j'espère que cela vous aidera ...


1

Il semble que dans de nombreux cas, il n'y a pas de corpus de recherche suffisamment important ou de qualité suffisante pour permettre de tirer des conclusions générales sur la question de savoir si une pratique en génie logiciel est meilleure qu'une autre. Je cherchais spécifiquement des recherches sur le travail dans différents paradigmes, mais le manque de disponibilité ne se limite pas à ce domaine, donc je vais cadrer ma réponse dans un sens plus large.

Un article de 2004, Evidence-Based Software Engineering par Kitchenham et al , couvre assez succinctement les avantages à tirer d'une approche factuelle et les problèmes de sa mise en œuvre en génie logiciel. Je ne vais pas discuter du côté des avantages ici (il ressort clairement de la question que j'aimerais pouvoir travailler de cette façon), mais les problèmes sont pertinents en tant que réponse à la question que j'ai posée.

  • Premièrement, si vous n'êtes pas membre de l'ACM, vous ne pouvez probablement pas lire le lien ci-dessus, qui couvre le premier problème: toutes les recherches existantes ne sont pas réellement disponibles pour les praticiens.
  • une grande partie de la pratique du génie logiciel se déroule en secret dans le cadre de processus commercialement confidentiels, il n'y a donc aucune visibilité sur ce qui a fonctionné ou non pour ces personnes.
  • le génie logiciel est une pratique qualifiée, il est donc difficile (pas impossible, simplement difficile) d'organiser une étude en aveugle.
  • les différentes parties du cycle de vie du logiciel affectent les résultats des autres dans une mesure difficile à contrôler dans toute expérience.
  • comme en témoignent les discussions ici, de nombreux praticiens ne considèrent pas «la littérature» (ou l'aspect académique du génie logiciel en général) comme pertinent pour leur travail.

Donc la réponse que je recherche est "non", les preuves que je recherche n'existent probablement pas. Je devrais choisir mon paradigme en fonction des critères populaires existants de ce que je sais, de ce qui est cool et de l'opinion d'experts.


2
extrait de l'article cité, je souligne: "Le facteur de compétence signifie que les expériences en génie logiciel sont vulnérables aux biais des sujets et des expérimentateurs . Le facteur du cycle de vie signifie qu'il est difficile de déterminer comment les technologies se comporteront une fois déployées . Conclusions: Le génie logiciel bénéficierait de adopter ce qu'elle peut de l'approche fondée sur les preuves, à condition qu'elle traite des problèmes spécifiques qui découlent de la nature du génie logiciel . " À quoi j'ajouterais: bonne chance avec ça! ;)
Steven A. Lowe

Steven: une partie de la motivation derrière EBSE est de passer de "Je peux deviner les problèmes suivants, donc je rejetterai toute chance que votre solution fonctionne" à l'analyse des résultats en fonction de leurs mérites. Il y a bien plus qu'un article que son résumé.

2
J'apprécie votre enthousiasme. La science médicale et le développement de logiciels sont des disciplines radicalement différentes. Bien que l'analogie soit intéressante, elle n'est guère révolutionnaire. Le document complet est disponible ici labada.inf.utfsm.cl/~gvaldes/ESE/docs/… La section 5 reflète le décalage d'impédance mentionné dans le résumé. Une cartographie plus directe des techniques médicales consisterait à déboguer les systèmes existants, et non à en construire de nouveaux. ;) Si vous voulez construire de meilleurs produits, construisez de meilleures équipes. Les gens sont bien plus importants que les outils (cf Peopleware)
Steven A. Lowe

1
addendum: le site EBSE contient des informations utiles, dur.ac.uk/ebse/evidence.php serait particulièrement utile pour les nouveaux venus dans le domaine SE - mais prenez les enquêtes avec un bloc de sel, car (1) les preuves disponibles est faible et (2) les résultats moyens peuvent ne pas être pertinents pour la performance de votre équipe d'individus spécifiques avec des compétences et des aptitudes hautement spécialisées.
Steven A. Lowe

0

Je ne crois pas que ce type d'étude existe. On pourrait croire que ce n'est pas le paradigme de programmation qui compte autant que l'algorithme réel qui est utilisé. Par exemple, étant donné tout système non trivial qui s'appuie sur des algorithmes à petit espace, un qui s'appuie sur des algorithmes à petit temps générerait des métriques différentes. Celui qui a le meilleur temps serait probablement jugé plus valide, sauf si l'espace est un problème, alors l'inverse est vrai. Je trouve cela similaire à paver une route. Bien que l'algorithme ou la recette de fabrication des matériaux soit constant tout au long de tous les processus, il serait possible qu'une entreprise pense que paver deux voies à la fois (une de chaque côté de la route) est mieux que de paver deux voies du même côté de la route à la fois . À la fin de la journée, cela n'a pas d'importance car le processus de fabrication du haut noir est toujours le même, la seule différence est l'approche. Pour en revenir à la programmation, si vous avez une équipe de développeurs C, écrivez le code de manière procédurale, si vous avez une équipe de développeurs Java, écrivez-le en OO. Ne vous accrochez pas tant au paradigme qu'à l'implémentation de l'algorithme. Parce qu'à la fin de la journée, vous pouvez écrire Java comme C et vous pouvez essayer d'écrire C comme Java.

METTRE À JOUR

Pour répondre au commentaire, Graham m'a laissé:
Je suppose que par architecture, vous entendez le paradigme de programmation. Si vous comptez utiliser Clojure, vous devriez peut-être embaucher une équipe de programmeurs Clojure. Cependant, basé sur une recherche rapide, Clojure est un langage basé sur Java, il se trouve qu'il est fonctionnel. Étant donné ces informations, je prendrais les programmeurs Java (car techniquement, ils peuvent simplement écrire Java et cela vous donnera les mêmes résultats) ou chercher des programmeurs fonctionnels tels que les développeurs Haskell. Maintenant, en termes de choix de ce qui est le mieux, cela dépend complètement de votre équipe. Je n'aurais jamais une équipe d'experts en bases de données relationnelles pour organiser une solution cloud pour moi ni une équipe de programmeurs fonctionnels pour construire une solution orientée objet pour moi. Vous devez utiliser les forces de l'équipe, vous n'avez pas la vision glorifiée que vous avez dans votre tête pour ce qu'une équipe "devrait"


Comment choisir d'embaucher une équipe de programmeurs Java ou une équipe de programmeurs C? Dois-je les recycler à Clojure? Une fois que j'ai choisi mon algorithme, quelle architecture est le "meilleur" moyen de l'encapsuler dans une solution logicielle, pour des valeurs données de "meilleur"?

@GrahamLee voir ma mise à jour
Woot4Moo

Je pense que nous discutons du même problème mais à différents niveaux d'abstraction. «Utiliser les forces de votre équipe» aurait signifié ne jamais construire d'ordinateur, car Bletchley Park n'avait personne avec la force de construire des ordinateurs. Parfois, vous devez dire "nous pourrions créer une meilleure solution si nous utilisions cette chose"; ce que je recherche, ce sont des informations sur ces cas.

0

Différents paradigmes conduisent à des solutions différentes. Le meilleur ajustement dépend en grande partie:

  • la solution
  • l'équipe de développement
  • l'environnement opérationnel

Je ne connais aucune étude aussi définitive, et même s'il y en avait une, je n'y ferais pas confiance.

C'est le travail de l'architecte.

Remplacer la sagesse de l'architecte par les conclusions éventuellement non pertinentes d'une étude est une recette pour un désastre.

Remarque: un commentaire mentionne le choix de "l'algorithme" puis le choix de la langue. Les algorithmes sont le mécanisme structurel central des langages procéduraux. Les langages orientés objet se concentrent sur les classes et les modèles de collaboration / communication. Si vous êtes convaincu (en tant qu'architecte) qu'une solution centrée sur l'algorithme est «la meilleure», alors restez avec des langages procéduraux ou fonctionnels.

Addendum: ne pas se fier aux études n'est pas de la «superstition», c'est du bon sens. Les expériences scientifiques doivent être objectives et reproductibles. Les projets logiciels sont très subjectifs, mais pire encore, ce sont des expériences irremplaçables . Vous ne pouvez tout simplement pas implémenter un projet X avec l'équipe Y, mesurer les résultats, puis revenir en arrière, effacer les souvenirs et refaire le même projet avec la même équipe. Les informations découvertes ou sous-entendues par les études peuvent être utiles à l'architecte, mais elles ne peuvent jamais être définitives.


1
Est-il donc hors de la portée d'un architecte de rechercher des travaux antérieurs sur lesquels fonder son opinion? Probablement pas - d'où la question de savoir si et où de tels résultats peuvent être trouvés.

2
S'il y avait une étude définitive avec une méthode expérimentale raisonnable, les résultats de l'étude pourraient être intéressants; en l'état, ces réponses semblent indiquer que toute étude est sans valeur, quelle que soit la méthode qui est un peu trop non scientifique à mon goût
jk.

3
@Steven: le mot pour ne pas faire confiance aux résultats d'une étude vraiment définitive est «superstition». Peut-être que ce que vous voulez vraiment dire, c'est que vous ne croyez pas qu'il puisse y avoir des études définitives en SE (ce qui nécessiterait évidemment un grand nombre de preuves bien étayées).
Cris

1
La qualité d'une méthode logicielle réside dans son adéquation avec les besoins humains locaux. En général, il n'est pas contraint par les lois de la physique (Scotty). Il faudra beaucoup de temps avant que le «logiciel» [discipline] parvienne à distiller ses lois fondamentales immuables. Par exemple, voir «Mesures de qualité logicielle: trois mesures nuisibles et deux mesures utiles» dans ppi-int.com/newsletter/SyEN-046.php#feature et ppi-int.com/newsletter/SyEN-047.php#feature
Philip Oakley

1
@Cris: Pour mémoire, non, je ne pense pas qu'il puisse jamais y avoir d'étude vraiment définitive dans ce domaine; voir addendum. L'idée qu'une étude `` définitive '' puisse être utilisée à la place d'un jugement d'expert pour prendre une décision architecturale critique est un `` appel à l'autorité '', qui est une forme d'erreur logique :) D'après mon expérience - et je ne fais pas de couverture accusations, juste une observation - la recherche de telles choses est le plus souvent soit une tentative d'éviter la responsabilité d'une décision, soit une tentative de soutenir une décision qui a déjà été prise.
Steven A. Lowe
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.