Valeurs par défaut - sont-elles bonnes ou mauvaises?

La question sur les valeurs par défaut en général - valeurs de fonction de retour par défaut, valeurs de paramètres par défaut, logique par défaut pour quand quelque chose manque, logique par défaut pour gérer les exceptions, logique par défaut pour gérer les conditions de bord, etc.

Pendant longtemps, j'ai considéré les valeurs par défaut comme une chose "purement diabolique", quelque chose qui "masque la catastrophe" et a pour conséquence de trouver des bugs très difficiles. Mais récemment, j'ai commencé à considérer les valeurs par défaut comme une sorte de dette technique ... ce qui n'est pas une mauvaise chose, mais quelque chose qui pourrait fournir un "financement à court terme" pour nous permettre de survivre au projet (combien d'entre nous pouvaient se permettre acheter une maison sans contracter l'hypothèque?).

Quand je dis «à court terme» - je ne veux pas dire - «faites d'abord quelque chose rapidement et refactorisez-le plus tard avant qu'il n'atteigne la production». Non - je parle de compter sur des valeurs par défaut codées en dur dans un logiciel de production. Certes - cela pourrait causer des problèmes, mais que se passerait-il si cela ne causait qu'un seul problème en une année entière.

Encore une fois - je parle ici du logiciel traditionnel "moyen" (pas un logiciel pour une centrale nucléaire) - du site Web moyen ou d'une application d'interface utilisateur pour le logiciel de comptabilité, ce qui signifie que la vie des gens n'est pas en jeu, ni des millions de dollars .

Encore une fois, d'après mon expérience, les utilisateurs professionnels préfèrent vivre avec le logiciel qui "fonctionne d'une manière ou d'une autre", plutôt que d'attendre un parfait. Et l'utilisation de valeurs par défaut aide beaucoup si vous développez un logiciel dans un style RAD. Mais encore une fois - les sessions de débogage les plus longues que j'ai passées étaient dues aux bogues introduits par une valeur par défaut qui soit cessait d'être "par défaut" en cours de route, soit parce qu'un petit sous-système a récemment été mis à niveau et que cette mise à niveau ne le fait pas. gérer correctement la valeur par défaut (par exemple, liste vide vs null, ou chaîne null vs chaîne vide).

Ma question est donc - les valeurs par défaut sont-elles bonnes ou mauvaises? Et s'il s'agit d'une dette technique - comment mesurer le montant que vous pouvez emprunter pour vous permettre de rembourser?

J'apprécierais vraiment n'importe quelle entrée.

À votre santé.

ÉDITER:

Si j'utilise les valeurs par défaut comme moyen de couper les coins pendant le développement - et si la coupe des coins entraîne des bugs et des problèmes - quelle est la méthodologie pour récupérer de ces problèmes?

Le concept de convention sur la configuration est impossible sans valeurs par défaut raisonnables . Le mot clé ici est "sensible". Les valeurs par défaut doivent avoir un sens pour au moins 80% (sinon plus) de toutes les utilisations d'une bibliothèque / d'un service / d'un framework.

Règles générales:

• Si une valeur est sensible pour 80% ou plus d'utilisations, elle doit être une valeur par défaut
• S'il n'y a pas de valeurs utilisées dans la majorité des cas, n'utilisez pas de valeurs par défaut.
• Les valeurs par défaut empêchent les erreurs stupides du code de configuration. Si les valeurs par défaut sont raisonnables dans la plupart des cas, moins de personnes gâchent la configuration de travail.
• Les configurations non standard sont plus visibles lorsque vous utilisez des valeurs par défaut.
• Les défauts par défaut sont pires que pas de défauts.

Essentiellement, une fois que vous avez appris comment fonctionne la configuration par défaut, vous pouvez prendre des décisions éclairées sur la façon / le moment de faire des configurations non standard.

Prenons par exemple une bibliothèque qui implémente le protocole FTP. Par défaut, FTP devrait fonctionner sur le port 21. Maintenant, je serais très irrité si je devais spécifier d'utiliser le port 21 à chaque fois que je construis un objet d'une classe FTP aléatoire. Si j'ai besoin d'un autre port, laissez-moi le préciser.

Les valeurs par défaut sont parfaitement correctes lorsqu'il s'agit de valeurs par défaut saines.

Vous utilisez probablement une disposition de clavier par défaut avec des mappages de touches par défaut, des mappages de boutons de souris par défaut, le navigateur par défaut, en tapant la langue par défaut du système, le démarrage à partir du système d'exploitation par défaut dans le chargeur de démarrage, les menus positionnés par défaut, le jeu de couleurs par défaut, la police par défaut largeur / hauteur / visage / style, jeu de caractères par défaut, résolution de moniteur par défaut, par défaut ... vous avez l'idée.

Mais sérieusement, je pense que la préoccupation que vous avez ne concerne pas les défauts mais quelque chose d'autre. Le comportement par défaut ne masque pas intrinsèquement les bogues. La plupart du temps, votre code s'exécutera de toute façon dans des conditions courantes, que vous définissiez ou non les valeurs par défaut. Les cas de bord non gérés sont des choses que vous voudrez vous assurer d'éviter malgré tout (probablement par le biais de tests adéquats et appropriés), lorsque les valeurs par défaut sont modifiées ou qu'un scénario inhabituel se produit.

En outre, la gestion des exceptions «fourre-tout» est sans doute un défaut de conception plutôt que tout ce que vous pourriez appeler «par défaut».

Les valeurs par défaut doivent être utilisées lorsqu'elles empêchent l'utilisateur ou le développeur d'effectuer des tâches répétitives. Ils ne doivent jamais être utilisés pour masquer des erreurs ou des exceptions. Ce n'est pas une mauvaise pratique de les utiliser pour éviter les erreurs, mais seulement tant que la prévention ne masque pas quelque chose de mauvais. Les valeurs par défaut sont un outil comme tout le reste. Bien utilisés, ils peuvent vous faire économiser beaucoup de maux de tête et de temps. Mal utilisés, ils peuvent faire tomber toute la maison.

La cause première des problèmes que vous citez n'est pas les valeurs par défaut en soi, mais les problèmes d'intégration dus à la modification des contrats d'interface, aux malentendus d'interprétation et / ou aux hypothèses non valides. Fondamentalement, tous ces (exemples spécifiques) semblent être le résultat d'une mauvaise communication - entre le client et le développeur, ou entre différents développeurs / équipes. Assez juste, ces problèmes peuvent se manifester comme des valeurs par défaut non valides, mais aussi sous d'innombrables autres formes.

Gérez la cause profonde, pas le symptôme.

Et notez également que - comme d'autres l'ont souligné avec d'excellents exemples - les valeurs par défaut, lorsqu'elles sont utilisées à bon escient, peuvent faciliter considérablement la vie des utilisateurs. Et c'est finalement notre objectif, non?

Les valeurs par défaut qui ne font pas partie du protocole / convention de communication sont mauvaises. En étant «pas une partie», je veux dire qu'ils ne sont pas documentés là où le protocole est strict, ou qu'ils ne sont tout simplement pas attendus, où le protocole est lâche.

Si la valeur par défaut est documentée / attendue, elle peut toujours être mauvaise, mais elle peut aussi sauver des vies. Cela dépend de la zone du domaine. C'est très souvent quand ils peuvent être très dangereux (par exemple la dose de médicament par défaut, le plancher d'ascenseur par défaut, la direction de déplacement par défaut de la voiture), et parfois il peut être dangereux de ne pas les avoir (par exemple la direction de déplacement par défaut de la voiture, l'heure de réunion par défaut).