Сначала пишите код с использованием API, а затем фактический API - у этого подхода есть имя и он подходит для процесса разработки API?

Question

Стандартный способ работы с новым API (библиотека, класс и т. Д.) Обычно выглядит так:

• вы думаете о том, какие методы понадобятся пользователю API
• вы реализуете API, который, как вы подозреваете, понадобится пользователю

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

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

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

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

Итак, я хотел бы спросить вас, пробовали ли вы когда-нибудь такой подход, когда нужно было создать новый API, и помог ли он вам? Это какая-то признанная техника, которая имеет название?

Answer 1

Итак, вы пытаетесь угадать, как должен выглядеть ваш API.

И это самая большая проблема при проектировании чего-либо подобным образом: не должно быть (ну, минимально) догадок при разработке программного обеспечения. Разработка API на основе предположений , а не фактической информации опасна по нескольким причинам:

• Это прямо противоречит принципу YAGNI: для того, чтобы что-то сделать, у вас есть , чтобы предположить, что ему понадобится пользователю, без информации для подтвердите эти предположения.

• Когда вы закончите и, наконец, сможете использовать свой API, вы непременно обнаружите, что его отстойно использовать (плохой пользовательский опыт), потому что вы не думали о как используется библиотека (UX), вы думали о , что должна делать библиотека (функции).

• API, по определению, представляет собой интерфейс для пользователей (то есть разработчиков). Проектирование, как и все остальное, просто делает плохой дизайн, в обязательном порядке.

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

И вопреки ответу Габриэля, это не дизайн снизу вверх: он сверху вниз. Вместо того, чтобы проектировать конкретный бэкэнд вашей библиотеки и затем накладывать на него абстрактный интерфейс, вы сначала проектируете интерфейс, а затем беспокоитесь о реализации.

Answer 2

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