Каковы наилучшие методы разработки согласованных библиотек?

Я работаю над разработкой пары библиотек для работы с REST API. Поскольку мне нужно иметь возможность использовать API в самых разных настройках, в настоящее время я планирую иметь версию на PHP (для веб-приложений) и вторую версию на Python (для настольных приложений и длительных процессов). Есть ли какая-либо передовая практика в развитии библиотек, чтобы помочь сохранить мое собственное здравомыслие?

Таким образом, проблема с развитием параллельных библиотек на разных языках заключается в том, что часто разные языки будут иметь разные идиомы для одной и той же задачи. Я знаю это из личного опыта, поместив библиотеку с Python на PHP. Идиомы – это не просто именование: например, у Python есть много магии, которую вы можете использовать с геттерами и сеттерами, чтобы сделать свойства объекта магическими; Python имеет monkeypatching; Python назвал параметры.

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

«Станьте своим собственным клиентом»: я обнаружил, что метод написания тестов в первую очередь – отличный способ обеспечить, чтобы API был прост в использовании. Сначала тесты на запись означают, что вы будете думать как «потребитель» вашего API, а не просто разработчик.

Попробуйте написать общий комплект тестов для обоих. Может быть, путем упаковки класса на одном языке для вызова его из другого. Если вы не можете этого сделать, по крайней мере убедитесь, что две версии тестов эквивалентны.

Ну, очевидным было бы сохранить ваше именование последовательным. Функции и классы должны быть названы одинаково (если не одинаково) в обеих реализациях. Обычно это происходит естественным образом, когда вы реализуете API отдельно на двух разных языках. Большой билет, хотя (по крайней мере, в моей книге) заключается в том, чтобы следовать языковым идиомам. Например, предположим, что я реализую REST API на двух языках, с которыми я больше знаком: Ruby и Scala. Версия Ruby может иметь класс MyCompany::Foo который содержит метод bar_baz() . И наоборот, версия Scala того же API будет иметь класс com.mycompany.rest.Foo с методом barBaz() . Это просто соглашения об именах, но я нахожу, что это долгий путь, помогая вашему API чувствовать себя «дома» на определенном языке, даже когда дизайн был создан в другом месте.

Кроме того, у меня есть только один совет: документ, документ, документ. Это просто лучший способ сохранить свое рассудительность при работе с спецификацией API с несколькими реализациями.

AFAIKT существует много мостов от языков сценариев. Возьмем, к примеру, Jruby, это Ruby + Java, тогда есть вещи для вставки Ruby в Python (или в другую сторону). Тогда есть такие примеры, как Etoile, где базой является Objective-C, а также мосты для Python и Smalltalk, другой подход к широкому использованию: обтекание библиотек C, примеры libxml2, libcurl и т. Д. Возможно, это может быть базой. Допустим, вы пишете все для Python, но реализуете мост для PHP. Таким образом, у вас не так много развития parrallel.

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

почему бы и не использовать python для веб-приложений? существует несколько инфраструктур: django, web2py – похоже на django, но многие говорят, что это проще в использовании, есть также TurboGears, web.py, Pylons

по линии моста – вы можете использовать межпроцессную связь, чтобы иметь возможность использовать PHP и python (в режиме демона) друг с другом.