on ne parle pas d'une raison évoquée pour refuser un patch (par exemple, un patch qui corrigerait un détail insignifiant ou invisible sur la chaîne de caractères), mais d'une instruction préventive : "ne pas modifier cette fonction". Du coup, ça renverse quand même pas mal la logique.
Ça me semble être exactement la même logique. Juste qu'on annonce la couleur à l'avance. Je suis pas familier avec la philosophie de développement de ce logiciel en particulier mais j'imagine qu'à un moment il va bien falloir changer quelque chose de toute façon et c'est pas un commentaire qui va arrêter cela. J'imagine que ça freine surtout les changements intempestifs et force à considérer l'intérêt des utilisateurs que ça va casser.
le meilleur logiciel possible
Il reste à définir sur quelles métriques tu te bases pour définir le « meilleur logiciel ». Beaucoup de gens vont décider de juger ça sur le fait que le logiciel serve bien ses utilisateurs existants (i.e. que l'équipe de développement est à leur service). Tu peux s/logiciel/service/g et la logique reste la même. Je ne vois rien de douteux là dedans, même s'il peut y avoir d'autres contraintes qui déprioritisent plus ou moins cette notion de service aux utilisateurs.
les coûts induits par mes choix sur les utilisateurs potentiels ne rentrent pas dans l'équation
Mais du coup, il y a relativement peu d'utilisateurs qui vont utiliser ton truc (« ça change tout le temps »), du coup la loi d'Hyrum est aussi moins pertinente du fait qu'il y a peu d'utilisateurs, du coup tu peux joyeusement continuer de casser la comptabilité et tout le monde s'en fout.
Je pense qu'une autre manière de voir cela c'est qu'en temps que développeur tu dois choisir l'équilibre entre te faciliter la vie, faciliter la vie de tes utilisateurs existants et faciliter la vie de tes futurs utilisateurs. Différents projets et différentes organisations vont faire de choix différents. Tant que le choix est fait de manière intentionnelle, ça ne me choque pas trop.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dette technique...
Posté par Krunch (courriel, site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 5. Dernière modification le 27 novembre 2024 à 17:58.
Ça me semble être exactement la même logique. Juste qu'on annonce la couleur à l'avance. Je suis pas familier avec la philosophie de développement de ce logiciel en particulier mais j'imagine qu'à un moment il va bien falloir changer quelque chose de toute façon et c'est pas un commentaire qui va arrêter cela. J'imagine que ça freine surtout les changements intempestifs et force à considérer l'intérêt des utilisateurs que ça va casser.
Il reste à définir sur quelles métriques tu te bases pour définir le « meilleur logiciel ». Beaucoup de gens vont décider de juger ça sur le fait que le logiciel serve bien ses utilisateurs existants (i.e. que l'équipe de développement est à leur service). Tu peux s/logiciel/service/g et la logique reste la même. Je ne vois rien de douteux là dedans, même s'il peut y avoir d'autres contraintes qui déprioritisent plus ou moins cette notion de service aux utilisateurs.
Mais du coup, il y a relativement peu d'utilisateurs qui vont utiliser ton truc (« ça change tout le temps »), du coup la loi d'Hyrum est aussi moins pertinente du fait qu'il y a peu d'utilisateurs, du coup tu peux joyeusement continuer de casser la comptabilité et tout le monde s'en fout.
Je pense qu'une autre manière de voir cela c'est qu'en temps que développeur tu dois choisir l'équilibre entre te faciliter la vie, faciliter la vie de tes utilisateurs existants et faciliter la vie de tes futurs utilisateurs. Différents projets et différentes organisations vont faire de choix différents. Tant que le choix est fait de manière intentionnelle, ça ne me choque pas trop.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.