Quand j'entends des discussions sur la libération de la version 1 des API, il est toujours accompagné de cette idée de production:
Nous ne pouvons pas encore libérer notre API parce que nous devons le faire correctement la première fois.
Voici un exemple récent de Vic Gundotra , mais il y a de nombreux autres, y compris Stackoverflow lui-même , de retour dans la journée avant la sortie de l'API.
Ce que je ne comprends pas, c'est pourquoi la première version doit-elle être si "droite"? Avec des API, vous pouvez mettre en œuvre des versions et une bonne documentation, et si vous le faites bien, ce qui n'est pas si difficile à faire, pourquoi être si précieux de l'API de la version 1?
de la version à la version, car il est versé, l'API peut changer de manière spectaculaire sans modification de rupture, car l'ancienne version est toujours prise en charge. Je me demandais pourquoi le gros problème sur la libération des API.
3 Réponses :
Je pense que c'est un peu difficile à répondre. Mais laissez-moi essayer. Vous faites votre programmation, mais avez-vous eu la plupart de la première fois?
Eh bien, mon expérience est que je commence par une méthode et qu'il s'agrure. Après que les tests soient verts, je le regarde et je l'ai trouvé pas assez bon. J'ajoute d'autres méthodes que j'essaye de "nettoyer".
Maintenant une API pour un progiciel plus grand, n'est pas si "petit" du tout. Et je parie que vous ne vous trouvez même pas près de quelque chose que vous trouvez «bon» assez, dès le début. Cependant, si vous libérez une API, vous y êtes lié. Vous ne ferez pas beaucoup d'amis briser des API comme vous allez. Donc, si vous êtes un peu sérieux à propos de votre code, vous prendrez en charge les différentes versions.
Je suggère d'examiner l'histoire de GTK. Il y a gtk 1.2.x et des choses au-delà de 2. Nous avons écrit une fois des logiciels selon GTK 1.2 et n'étaient pas "heureux", car on sortait non compatible avec 1.2. Et donc le logiciel colle toujours dans 1.2.x de GTK ...
Donc, pas la façon habituelle n'est pas que vous avez toujours une API OLDE API, mais avez-vous cassé. Et là-bas, les programmeurs ne sont pas si heureux de réaliser une API très tôt (IMHO)
+1 Merci Friedrich ... Je suppose que je n'ai tout simplement pas l'idée d'être "liée". Vous devez simplement prendre en charge les dernières versions "n", où "n" est un nombre assez petit comme 2 ou 3. Un changement d'API n'est également que lorsque l'interface change, pas la mise en œuvre.
de la version à la version, car il est versé, l'API peut modifier considérablement sans modification de rupture, car l'ancienne version est toujours prise en charge.
Cela signifie deux choses:
- Maintenance plusieurs versions d'une API. Même si vous ne soutenez que «les 3 dernières versions», c'est toujours un fardeau. En particulier, si vous exposez une fonctionnalité que vous souhaitez Supprimer plus tard, cela signifie que vous ne pouvez pas faire de nettoyage qui serait disponible dans le retrait jusqu'à ce que N plus versions soient disponibles. et parti. Considérez toutes les ramifications sur les données stockées pouvant résulter de changements importants dans les représentations de stockage de la migration de l'API lorsqu'elles sont utilisées par plusieurs systèmes, mis à jour sur différents calendriers de version, est une véritable douleur. (Oui, il y a une différence entre la mise en œuvre et l'API - mais les changements d'API finissent souvent par le sens changent tout au long de la pile.)
- éventuellement irritant beaucoup de développeurs. Même si vous donnez beaucoup d'avertissement, les gens seront seront agacés s'ils doivent faire des réécrites significatives, car la version 1.0 était des ordures et que 1,4 sort, 1,0 sera supprimé.
Conception correcte d'une API est une entreprise délicate. Oui, il y a un équilibre à frapper entre pragmatisme et perfectionnisme - mais ce n'est pas aussi simple que vous le faites.
J'aurais également souligné qu'il y a une très grande différence d'entretien entre (dire) un projet open source avec 10 utilisateurs qui mettent rapidement quelque chose rapidement, puis une entreprise comme Google ou Microsoft le faire pour une communauté mondiale de développeurs. Il y a même une grande différence entre une API interne dans une grande entreprise (où vous ne pouvez pas facilement corriger l'ensemble de la base de code) et une API interne dans une petite entreprise où vous pourrez changer le monde quand vous le souhaitez.
J'ai une certaine sympathie pour l'étonnement de faire une affaire aussi importante à ce sujet - mais cela suggère que vous n'avez pas expérimenté la douleur qui changeait une API peut signifier. Vous serez peut-être également étonné - ou encore plus, à quel point il est difficile de faire des changements fondamentaux une fois qu'une mauvaise décision s'est échappée dans le monde.
(Disclaimer: Je travaille pour Google, mais pas dans la zone G +. Les opinions de cette réponse sont les miennes et ne représentent pas Google.)
+1 Hey Jon, merci pour votre contribution! Je sais que ma question semble chargée, mais c'est une question et ces réponses sont incroyablement utiles. Cependant, je suis toujours laissé vouloir. Par exemple, votre premier point. Donc, dites que vous passez des âges à essayer de perfectionner votre API. Finalement, votre système sous-jacent peut avoir à changer, puis quoi? Quel était le point de penser aux métaphores pour vous API depuis si longtemps lorsque vous avez frappé le même problème de toute façon. Pourquoi ne pas simplement libérer une API qui ciblez votre système comme c'est le cas et vous inquiétez des changements plus tard, il va arriver de quelque manière que ce soit?
@andy: Nouvelles versions de la structure .NET Généralement Ajouter nouvelles fonctionnalités, mais rarement ils brisent les API existantes. Je doute que les développeurs soient aussi excités d'apprendre que leurs applications existantes ne s'exécuteront pas sur une nouvelle version du cadre.
@andy: Le point de Casablanca est exactement l'important. Une bonne API aura toujours besoin de changer au fil du temps - mais tout ce qui est là doit rester là à moins que vous ne voulez vraiment irriter les gens. De plus, pour des choses comme des interfaces avec d'autres implémentera, vous ne pouvez même pas ajouter à cela, ou vous allumerez les implémentations existantes. Certaines API et ses cadres n'ont pas besoin de s'efforcer de la compatibilité en retard, mais ceux qui ont vraiment besoin d'être réfléchis à soigneusement.
@Jonskeet Hey Jon, merci encore. Je reçois ce que vous dites les gars, mais cela ne traite pas vraiment de cette notion de «vous êtes liée à votre API initiale». Le logiciel est une chose fluide et nous savons toujours que cela changera. Je me demande simplement pourquoi les API sont traités différemment ...?
@andy: C'est parce que si je décide de changer de changement, cela vous affecte et votre investissement dans mon API. Les clients n'ont pas tendance à prendre gentils vers les vendeurs brisant leur code.
Vous pouvez peut-être demander une API extensible, par exemple:
Apiclass :: anapicall (xclass xparam, yclass yparam, vide * userData, vide * extensions);
.. où 'extensions' est transmis comme null en v1.0.
Vous pouvez convenir avec le fournisseur que la fonctionnalité fournie par V1.0 ne sera pas prise en charge (mais continuera d'être fournie), dans les versions ultérieures.
Votre logique est un peu étrange ... N'est-ce pas préférable de bien faire la première fois la première fois et après cela s'appuyer dessus et le rendre meilleur?
"... puisque l'ancienne version est toujours prise en charge" - Maintenir les anciennes versions est un énorme fardeau.
@nile: pas vraiment. Comment pouvez-vous définir «l'obtenir bien». Semble trop "cascade" pour moi. Si vous mettez en œuvre des idées d'un développement agile et même maigre, comment pouvez-vous savoir que c'est bien. De la même manière que la première version de votre logiciel n'est pas "Droite". Vous savez que ça va changer dans le temps.
Eh bien, maintenant je pense que nous ne faisons que faire face à des mots. Les développeurs veulent faire la première gérer une bonne chose, ce qui peut prendre du temps.
@nile: merci Nil. Je suppose peut-être que j'essaie d'examiner comment les API s'intégrent dans la notion de développement Lean, passez cela ici pour obtenir la vue d'autres personnes. Je pense que le tapis, par exemple, a un grand point sur la manière dont le maintien de vieilles versions est en effet un fardeau.