Comment traiter avec une API / Framework non documentée sous .NET? [fermé]

Question

Pour le travail, je dois coder avec l'API d'une entreprise externe pour gérer sa solution de base de données propriétaire. Malheureusement, la documentation fournie est plus un exemple de guide que de documentation d'API appropriée. Il est donc très clair sur les détails les plus importants tels que les codes d'erreur, les retours de méthode et les exceptions.

Ainsi, par exemple, une classe aura une méthode .GetErrorCode (), mais je n'ai aucune idée de la signification de ces numéros d'erreur car ils n'ont pas documenté quel numéro correspond à quelle erreur. Dans de nombreux cas, une méthode retourne un objet, sans documentation sur le type d'objet renvoyé. Je leur ai demandé à maintes reprises une documentation appropriée, mais ils semblent penser que des détails comme ceux ci-dessus sont des secrets de propriété. Alors, y a-t-il des outils ou des méthodes pour contourner ma documentation limitée ou, dans certains cas, inexistante.

Veuillez noter que j'utilise Visual Studo 2005 et que je code en C # sous .Net.

Et avant que quiconque ne réponde, "n'utilisez pas l'API", je dois le faire, c'est pour le travail.

Answer 1

Un mauvais scénario. Je n'aime pas le suggérer, mais peut-être que réflecteur est votre ami s'il n'est pas obscurci . Il peut y avoir des problèmes de propriété intellectuelle, mais dans ce cas, l’inversion semble être le seul moyen viable de déterminer l’API. Cependant, je soupçonne (avec des méthodes telles que .GetErrorCode ()) qu’il s’agit d’un repère au-dessus de P / Invoke. Dans ce cas, même le réflecteur vous montrera simplement de nombreux appels externes ...

L’autre chose principale que je peux dire est: écrivez beaucoup de tests unitaires qui décrivent comment vous essayez de l’utiliser. Ainsi, si vous devinez faux et que quelque chose change, vous saurez tôt.

Answer 2

Si je ne parviens pas à obtenir des exemples de code ni à parler à un développeur d'origine, je recourt généralement à Reflector pour examiner le code sous-jacent. C'est lent et inefficace, mais parfois c'est tout ce que vous pouvez faire.

Answer 3

Cela dépend de votre situation. Si vous payez pour l’API, vous devez continuer à faire pression sur la société pour obtenir une meilleure documentation sur son utilisation.

Si cela ne fonctionne pas, je commencerais par créer ma propre documentation au fur et à mesure de mon développement. Conservez un cahier, un wiki personnel ( wiki de tournevis vous vient à l’esprit), ou une sorte de fichier électronique. Documentation. Comme d'autres personnes l'ont mentionné, vous pouvez utiliser Reflector pour vous rendre à la source (si elle n'est pas obscurcie).

Créer votre propre documentation n'est peut-être pas ce que vous recherchiez, mais si vous ne pouvez pas obtenir une vraie documentation, créez-en au moins une partie à mesure que vous apprenez des choses afin que vous puissiez avoir quelque chose à vous guider quelques mois (ou années) sur la route lorsque vous essayez de maintenir le code construit avec l'API.

Answer 4

Les meilleurs outils qui me viennent à l’esprit sont le téléphone et le courrier électronique. J'espère que vous pourrez continuer à embêter les gens là-bas jusqu'à ce qu'ils vous donnent des informations plus utiles ...: (

Answer 5

Utilisez Reflector pour afficher le code source. Devrait vous montrer l'énumération du message GetErrorCode.

Reflector est d'ailleurs le programme le plus important de l'histoire de l'univers.