Лучшая практика - Как разбить проект на django, все еще разрешая повторное использование кода

Question

Я знаю, это звучит немного расплывчато, но, пожалуйста, позвольте мне объяснить - я начинаю работу над новым проектом, в котором будут два основных компонента: «ACME PRODUCT» (например, Gmail, Meebo и т. Д.) И «САЙТ "(справка, информация, маркетинговые материалы, рекламные целевые страницы и т. Д. Много маркетингового мошенничества).

Таким образом, в основном URL-адрес /acme/* будет загружать вещи в приложение uber cool ajaxy и любые другиеURI загрузит материал на другом сайте.

Проблема: компонент «САЙТ» не в моих руках и будет обрабатываться командой консультантов, которая будет тесно сотрудничать с маркетингом, и я, и моя команда будем работатьисключительно на ACME PRODUCT.

Вопрос: Как настроить проект django таким образом, чтобы мы могли иметь:

• Отдельные выпуски.(Они могут продвигать новые маркетинговые страницы и функциональные возможности, не беспокоясь о состоянии нашего кода. Может быть, даже отдельные «проекты» Subversion)
• Минимизировать влияние (на наш продукт) любого летающего единорога-фокус-покусадругие команды пишут на сайт.
• Все еще допускают повторное использование кода.

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

Как вы справились с этим?Есть идеи?Спасибо!

Answer 1

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

Answer 2

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

продукт ACME должен быть надежным и поэтому должен быть несколько изолирован от любых ошибок / ошибок кода, допущенных консультантами на их маркетинговой стороне сайта.

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

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