Как бороться с недокументированным API / Framework в .NET? [закрыто]

Question

Для работы мне нужно написать код API сторонней компании, чтобы справиться с их собственным решением для баз данных. К сожалению, предоставляемая ими документация является скорее примером руководства, чем правильными документами API, так что она очень легка на мельчайших деталях, таких как коды ошибок, возвращаемые методы и исключения.

Так, например, у класса будет метод .GetErrorCode (), но я понятия не имею, что означают эти числа ошибок, потому что они не документировали, какое число совпадает с какой ошибкой. Во многих случаях метод возвращает объект без документации о том, какой тип объекта он на самом деле возвращает. Я неоднократно просил их предоставить надлежащую документацию, но они, похоже, считают детали, подобные приведенным выше, секретами приличия. Итак, есть ли какие-либо инструменты или методы, которые я мог бы обойти с помощью моей ограниченной или, в некоторых случаях, несуществующей документации.

Обратите внимание, что я использую Visual Studo 2005 и пишу на C # в .Net.

И прежде чем кто-нибудь ответит, "не используйте API", я должен, это для работы.

Answer 1

Гадкий сценарий. Я не хочу это предлагать, но, возможно, отражатель станет вашим другом, если его не запутывают , Могут быть некоторые проблемы с IP, но в этом случае реверсирование кажется единственным реальным способом выяснить, что такое API. Однако я подозреваю (из таких методов, как .GetErrorCode ()), что это прокладка поверх P / Invoke - в этом случае даже отражатель просто покажет вам множество внешних вызовов ...

Главное, что я могу сказать: напишите много модульных тестов, которые описывают, как вы пытаетесь его использовать ... таким образом, если вы догадаетесь неправильно и что-то изменится, вы будете знать, рано.

Answer 2

Если я не могу получить примеры кода или поговорить с оригинальным разработчиком, я обычно прибегаю к Reflector , чтобы посмотреть на основной код. Это медленно и неэффективно, но иногда это все, что вы можете сделать.

Answer 3

Это зависит от вашей ситуации. Если вы платите за API, вы должны продолжать оказывать давление на компанию, чтобы получить лучшую документацию о том, как использовать API.

Если это не сработает, я начну с разработки собственной документации. Держите записную книжку, персональную вики (на ум приходит wiki) ) или какую-то электронную документация. Как упоминали некоторые другие люди, вы можете использовать Reflector, чтобы помочь добраться до источника (если он не запутан).

Создание собственной документации может быть не тем, что вы искали, но если вы не можете получить реальную документацию, по крайней мере, создайте ее по мере изучения вещей, чтобы у вас было что-то, что могло бы помочь вам в течение нескольких месяцев (или лет) в будущем, когда вы пытаетесь поддерживать код, созданный с помощью API.

Answer 4

Лучшие инструменты, которые приходят на ум, включают телефон и электронную почту. Надеюсь, что вы можете продолжать обзывать людей, пока они не дадут вам более полезную информацию ...: (

Answer 5

Используйте Reflector , чтобы просмотреть исходный код. Должен показать Enum для сообщения GetErrorCode.

Reflector, кстати, самая великая программа в истории вселенной.