La différence entre les meilleures pratiques et le bon sens?

Il y a beaucoup de discussions concernant les meilleures pratiques ¹ en développement logiciel. J'ai vu au moins trois points majeurs faire l'objet de nombreuses discussions à la fois sur SE et ailleurs:

• Qu'est-ce qui constitue une meilleure pratique et pourquoi?
• Les meilleures pratiques valent-elles même la peine d'être discutées en premier lieu, car il est raisonnable d'affirmer qu'aucune pratique n'est une "meilleure" pratique?
• Quand faut-il renoncer à une meilleure pratique - ou peut-être à la plupart des meilleures pratiques - soit parce qu'elle ne semble pas applicable, soit en raison de contraintes externes (temps, argent, etc.) qui rendent le compromis impossible?

Quelque chose qui semble revenir beaucoup moins souvent, mais plus que jamais, est une notion de bon sens dans le développement de logiciels. L'expérience récente a de nouveau mis cette notion à l'esprit.

Mon impression initiale est que c'est une discussion différente des meilleures pratiques, mais avec peut-être une pollinisation croisée.

Quand je pense au bon sens en général, je pense à un ensemble de règles que vous avez soit repris, soit appris, qui vous donnent une base pour raisonner et prendre des décisions. Suivre le bon sens est un bon moyen de vous éviter de tirer sur toute votre jambe. Mais au-delà d'une base de référence assez faible, le bon sens cède la place à un besoin de prendre des décisions éclairées, et les décisions éclairées peuvent même l'emporter sur le bon sens lorsque les preuves semblent suffisamment convaincantes. Je joue peut-être un peu avec la définition ici, mais je pense qu'elle est assez proche pour diriger mon exemple.

Quand je pense au bon sens dans le développement de logiciels, je pense à toutes les règles d'hygiène de base pour empêcher une base de code de se dégrader rapidement en un gâchis incompréhensible. Par exemple, des choses comme: ne pas utiliser une seule structure globale pour maintenir et communiquer l'état dans un programme non trivial; ne pas utiliser de variables / méthodes / noms de classe qui ne sont que du charabia aléatoire; des choses qui ressemblent probablement à ce que nous avons appelé assez étroitement des anti-modèles. Lorsque l'application des meilleures pratiques de l'analogue pratique aux modèles d'apprentissage, l'application du bon sens pourrait être considérée comme l'analogue pratique de l'apprentissage des anti-modèles.

Dans cet esprit, je voudrais poser quelques questions pour lesquelles le fait de voir les réponses des autres pourrait m'aider à raisonner.

D'autres croient-ils qu'il existe une notion de bon sens dans le développement de logiciels? Serait intéressé de connaître le raisonnement de toute façon.

Si oui, est-ce une notion qui mérite d'être discutée? Est-ce quelque chose que nous devrions pousser autant que nous le faisons parfois avec les meilleures pratiques? Cela vaut-il la peine de pousser encore plus fort?

Si l'analogie avec les anti-modèles semble raisonnable, la règle générale est que les anti-modèles ne sont utilisés que s'il n'y a pas d'autre moyen, et même alors seulement dans des circonstances très limitées. Dans quelle mesure faut-il être flexible pour permettre à une base de code de s'écarter du bon sens? Il semble déraisonnable que la réponse soit "pas du tout", car parfois l'opportunité exige des écarts. Mais cela semble être un type d'argument différent de celui de savoir quand utiliser une «meilleure pratique». Ce n'est peut-être pas le cas; si vous ne le pensez pas, j'aimerais savoir pourquoi.

C'est beaucoup plus ouvert et peut-être digne d'une question de suivi qui lui est propre, quelles sortes de recommandations pourriez-vous suggérer qui semblent être des questions de bon sens?

D'autres réflexions sont également les bienvenues.

¹ Je ferais peut-être mieux de les appeler «modèles de domaine récurrents», mais le nom «meilleures pratiques» est suffisamment courant pour que tout le monde sache ce qu'il en est, même s'il n'est pas d'accord. Si la «meilleure» partie vous dérange, imaginez que j'ai remplacé les «meilleures pratiques» par quelque chose de moins autoritaire.

Les meilleures pratiques sont des pratiques qui se sont avérées efficaces dans un champ de circonstances relativement large. Le problème avec eux est que A) l'expression est parfois utilisée abusivement pour le marketing et B) en tant que règles fixes, elles ne sont pas assez flexibles; aucun ensemble de règles fixes ne devrait être suivi sans se demander si elles s'appliquent à la situation actuelle.

Les meilleures pratiques sont excellentes lorsqu'elles sont accompagnées d'explications expliquant pourquoi elles sont «les meilleures» et dans quelles circonstances elles doivent être utilisées. Ensuite, vous pouvez raisonner quand ne pas les utiliser.

Le problème avec le "bon sens" est qu'il est trop flexible - il peut être utilisé pour justifier à peu près n'importe quoi, et vous ne pouvez pas vraiment avoir une discussion rationnelle lorsque les gens ne sont pas d'accord et prétendent tous les deux que leur position est du "bon sens". C'est bien d'avoir mais pauvre comme ligne directrice pour une équipe à suivre.

Je pense que vous l'avez à l'envers.

Lorsque j'enseigne aux programmeurs les rudiments de la sécurité, je leur apprends toujours à utiliser best practices, et pourtant, lorsque je traite avec des experts en sécurité (ou des programmeurs plus "expérimentés"), je ne discuterai jamais best practices, en fait je vais souvent les violer.

Une meilleure définition serait:

Les "meilleures pratiques" relèvent du bon sens des experts, comme devraient l'être les non-experts.

Autrement dit, vous ne pouvez pas prétendre au «bon sens» tant que vous n'avez pas suffisamment d'expertise dans le domaine donné pour comprendre les compromis subtils; et lorsque vous le faites, vous ne devriez plus suivre aveuglément les «meilleures pratiques» des emporte-pièces.

Les "meilleures pratiques" sont un espace réservé temporaire jusqu'à ce que vous ayez suffisamment d'expérience pour utiliser votre propre "bon sens".

Meilleures pratiques -> "d'abord, vous apprenez les règles". Expérience -> "alors, vous apprenez quand et comment les briser".

La volonté d'expérimenter des alternatives (dans le code non critique, bien sûr - de préférence des projets personnels et des lancers) peut aider à construire l'expérience dont vous avez besoin.

Le bon sens n'est pas la même chose que l'expérience, bien sûr, et vous n'avez pas toujours besoin de beaucoup d'expérience pour voir le défaut d'appliquer une bonne technique au mauvais endroit - mais il est très facile de construire de fausses rationalisations à la fois pour la sur-application et sous-appliquer une technique, et puisque le "bon sens" n'est clairement pas une connaissance innée de la programmation, ce sens n'est clairement "commun" qu'au sein de groupes particuliers.

Il est très facile de "prendre parti". Impossible d'éviter, en fait - parfois un côté a vraiment raison, et l'autre est vraiment faux, et il serait irrationnel de plaider pour l'équilibre. Le problème ici est que le véritable enfer ne pèse pas tant sur une meilleure pratique pour la pertinence, mais lorsque deux opinions contradictoires de meilleures pratiques entrent en collision.

Faire face à cela est probablement beaucoup plus sur les compétences des personnes que sur les compétences techniques. Je suis très mauvais :-(

Malgré cela, il est toujours important d'apprendre de l'expérience des autres ainsi que de la vôtre - c'est-à-dire de découvrir quelles sont les meilleures pratiques, pourquoi elles sont utilisées et quels sont les avantages (et inconvénients).

Il me semble que cette question est une supercherie sémantique. Si nous utilisons ces définitions, il ne fait aucun doute:

Meilleures pratiques: un moyen éprouvé sur le terrain de résoudre un problème dans un domaine donné (c'est-à-dire que les meilleures pratiques en temps réel sont totalement étrangères aux meilleures pratiques de la base de données)

Common Sense: une expérience professionnelle qui sert à avertir le programmeur des pièges à éviter

En fin de compte, une meilleure pratique est un modèle de méta-conception pour résoudre une congruence particulière de problèmes et est choisie en fonction des expériences du monde réel, tandis que Common Sense est un guide de résolution de problèmes basé sur l'observation générale de plusieurs ensembles de problèmes.

Common sense = You.CommonSense

Best practices = Sum(Experts.Experience + Experts.CommonSense)

Moment intéressant. La semaine dernière, cet article a été publié pour expliquer pourquoi le bon sens n'est pas nécessairement idéal dans toutes les situations.

Le bon sens est parfaitement adapté pour gérer le type de complexité qui se pose dans les situations de tous les jours ... Et parce qu'il fonctionne si bien dans ces situations, nous sommes enclins à lui faire confiance dans toutes les situations

(mes mots en gras)

Fondamentalement - les humains ne sont pas bons à utiliser le bon sens dans des domaines comme celui-ci où nous n'avons pas développé de système enraciné, nous devons donc TOUJOURS utiliser un ensemble de normes documentées et ne pas compter sur notre propre bon sens!

Le bon sens ne correspond pas à l'apprentissage d'anti schémas, il n'est ni différent ni contraire aux meilleures pratiques.

Le premier problème du bon sens est son nom - il conduit à la conclusion qu'il est à la fois commun et sensé. Tel qu'il est couramment utilisé, il est sujet à des attaques sur les deux plans. En utilisant votre exemple:

les anti-schémas ne sont utilisés que s'il n'y a pas d'autre moyen, et même alors seulement dans des circonstances très limitées

Je crois comprendre que ce n'est pas ainsi que les anti-schémas se présentent. C'est à partir d'une accumulation de facteurs culturels et sociaux; de ne pas tenir compte des meilleures pratiques et normes sur une période substantielle; d'ignorer les coûts futurs pour obtenir des avantages à court terme - par exemple pour respecter un délai en utilisant une solution de raccourci qui est un cauchemar de maintenance; etc. Aucun organisme ne se propose d'adopter délibérément un anti-modèle - il ne fait que grandir.

De même, le bon sens est beaucoup trop souvent utilisé pour signifier "que cela se fait couramment" et justifie le manque de réflexion, de perspicacité et de dur labeur pour résoudre ce qui est impliqué dans la fourniture d'une solution. Il est également utilisé pour justifier «sa façon de procéder, donc c'est évidemment du bon sens» - et comme défense contre les révisions et les critiques.

En ce qui concerne les meilleures pratiques, les deux premiers paragraphes de Michael sont un excellent résumé de ce que devraient être les meilleures pratiques - une ressource pour aider tout le monde à améliorer ce qu'il fait. Il offre également la transparence des décisions (en particulier les décisions de conception) et la capacité d'apprendre des autres. L'inconvénient des meilleures pratiques est qu'elles génèrent une culture de liste de contrôle - "J'ai coché toutes les cases, donc ce que j'ai fait doit être correct" - sans appliquer la réflexion, le soin et l'attention à la nature de l'applicabilité de la liste de contrôle.

Il s'agit d'un argument de pente glissante qui se transforme souvent en une guerre de religion.

Presque toutes les meilleures pratiques peuvent être contrées par des arguments valables pour faire le contraire.

Certaines meilleures pratiques sont plus «meilleures» que d'autres. Les variables d'état globales sont presque toujours mieux faites d'une manière différente et GOTO est généralement une mauvaise idée, mais lorsque vous entrez dans les arguments motif / anti-modèle ou données directes / données abstraites, cela devient un peu moins clair. Encore plus lorsque vous commencez à parler de méthodologies et de pratiques de développement.

Dans certaines situations, le bon sens et les meilleures pratiques sont même en opposition.

Il n'y a pas d'organe directeur des meilleures pratiques et aucun groupe unique, même s'il existait, ne pourrait définir tous les "meilleurs" possibles pour chaque situation possible. Beaucoup de choses qualifiées de meilleures pratiques ne sont que de la mauvaise commercialisation en essayant de vendre des outils ou de la formation à des individus non informés.

Même lorsque toute votre équipe convient que quelque chose est le mieux, il n'est pas toujours possible de l'implémenter de cette façon pour divers facteurs contraignants.

À mon humble avis, vous devez utiliser les meilleures pratiques comme guide sur ce qu'il faut considérer plus attentivement dans votre conception. Vous pouvez avoir une raison valable de dévier, mais vous devez probablement vous assurer que tous les autres membres de l'équipe sont d'accord avant de partir et de construire quelque chose d'étrange.

Certains des arguments concernant les meilleures pratiques après ce point se résument à peu près à ne pas construire quelque chose que le prochain développeur qui devra y travailler détestera. Tout le monde déteste le code qui n'est pas leur style, et tout le monde blâme tout le monde sur ceux qui partent, alors soit vous allez l'expliquer au prochain développeur après qu'ils se plaignent de quelque chose, soit vous n'allez pas être là et parler mal quelle que soit la façon dont vous le codez. Cela rend cette préoccupation presque hors de propos.

Le bon sens ne donne pas toujours les meilleurs résultats. Cependant, les meilleures pratiques ont été essayées. Cela fait des meilleures pratiques une source d'informations plus fiable.

Les meilleures pratiques ne sont pas les meilleures et le bon sens n'est pas courant. ;-)

Pour les meilleures pratiques ou le bon sens, j'aime à les considérer comme des modèles; Souvenez-vous de la définition d'un modèle: une solution dans un contexte qui résout les forces dans un contexte résultant .

Pour tout ce que vous voulez faire, vous devez connaître le contexte auquel il s'applique, les forces qu'il résout et le contexte résultant qu'il crée. Ensuite, décidez de votre équipe quels sont les modèles que vous allez généralement utiliser. (Cela peut être formel ou informel, mais dans tous les cas, il est beaucoup plus important que le livre Gang of Four. Cela inclut les idiomes linguistiques et les bibliothèques d'aide locales, pas seulement les modèles publiés.)

Si vous sentez, sur la base de votre expérience, que dans une certaine circonstance, il serait préférable de ne pas utiliser un modèle donné, mais de faire autre chose, faites-le savoir. Probablement le contexte ou les forces sont différentes ici (ou peut - être le contexte résultant serait indésirable.) Je ne me soucie pas si c'est une réunion, un commentaire de code ou quoi, mais si vous faites clairement que vous avez brisé le modèle sur le but , vous aurez des kilomètres d'avance.

La meilleure pratique est ce qu'ils vous enseignent à l'école, le bon sens est ce que le patron veut vous former. Le premier crée des logiciels qui répondent à certaines normes d'élégance, de style, etc. Ce dernier paie les factures / gagne de l'argent pour que vous soyez payé chaque semaine.

L'un est l'art, l'autre le métier, trop d'entre nous l'oublient.

Pour exagérer un peu: la différence est que le bon sens est le préjudice, la meilleure pratique est (devrait être) la science

D'après mon expérience, le «bon sens» est utilisé lorsque l'on ne veut pas fournir de preuve ou au moins d'arguments pour une manière de faire les choses. Cela ne signifie pas que la voie est nécessairement erronée, mais cela ne signifie pas non plus qu'elle soit bonne.

Parmi les choses que j'ai rencontrées, qui ont été rationalisées comme étant du bon sens, se trouvent ces joyaux.

• la méthode HTTP est largement hors de propos, utilisez GET lorsque vous transmettez peu de données, utilisez POST lors de la transmission de plus (c'est-à-dire trop pour l'URL)
• les fonctions ne doivent pas être trop petites, car il est difficile de se souvenir de ce qu'elles font. une grande fonction est préférable à 5 plus petites, car vous pouvez la lire comme une seule
• la base de données et le serveur Web DOIVENT fonctionner sur la même machine, sinon le service Web ralentira. La seule façon d'évoluer est d'accélérer le code par des hacks et en renonçant à l'abstraction, afin que la puissance d'une machine suffise.

Ce qui est drôle à propos de «Common Sense», c'est que ce n'est pas si courant: choisissez deux équipes et laissez-les dire ce qu'elles pensent être du «bon sens», et profitez des guerres de religion.

D'un autre côté, en tant que «meilleure pratique», j'envisagerais des façons de faire, qui ont un peu plus «d'examen par les pairs». Pour considérer quelque chose comme une `` meilleure pratique '', je m'attendrais à ce qu'il soit formulé suffisamment clairement pour qu'il puisse être présenté comme un concept (la `` programmation structurée '' est la meilleure pratique, `` les gotos sont déroutants, évitez-les '' est du bon sens), et appliqué plus d'une fois, avec de bons résultats.