структурирование большого веб-приложения для нескольких разработчиков

Question

У меня есть несколько разработчиков, которые собираются начать работу над интерфейсом веб-приложения на основе jquery. Как мы можем структурировать приложение так, чтобы несколько разработчиков могли одновременно работать с пользовательским интерфейсом. Конечным результатом для пользователя будет просто одна веб-страница, но я не делаю всю разработку клиента в одном файле. Уже есть другая команда, работающая в бэкэнде.

Answer 1

Если вы начинаете с нуля, вы можете разбить его на стандартную трехуровневую архитектуру.

Пусть один человек работает над структурой базы данных и создает соответствующие библиотеки доступа к данным.

Пусть один человек работает на уровне бизнеса / рабочего процесса, настраивая все взаимодействие данных.

Пусть третье лицо выполнит всю работу над интерфейсом с jQuery.

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

Answer 2

Попробуйте смоделировать объектно-ориентированный подход к проблеме, чтобы одна группа разработчиков могла кодировать необходимую функциональность внутри объектов, в то время как другие основывались на функциях, которые объекты могли бы предоставить.

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

Конечно, как сказал Джонни, вам следует полагаться на некоторые SCM для управления параллельными изменениями в вашей кодовой базе. Даже если задачи разделены на две части, разработчику может потребоваться изменить чужой код. Я бы порекомендовал git или SVN, если вы находитесь под Windows (потому что он имеет TortoiseSVN, что довольно мило, если вы только начинаете с SCM).

Answer 3

Разложите фрагменты разметки вашей целевой страницы на серверные включения или другие компонуемые фрагменты, каждый из которых обернут в DIV (или другой соответствующий тег) с уникальным идентификатором, затем добавьте отдельные ссылки CSS и JS для стилей CSS и JQuery биты, которые стилизуют и оживляют каждый кусок.

В то время как правила CSS делают каскадные и jQuery-запросы могут конфликтовать (так как они основаны на CSS-селекторе), осторожное использование идентификаторов и классов может иметь большое значение для создания грубых «песочниц» на вашей последней странице, в которой каждая передняя Конечный разработчик может работать относительно независимо.

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

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

Answer 4

Если вы хотите, чтобы несколько человек работали над одними и теми же файлами, ваш СКМ сможет справиться с этим за вас.

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

Answer 5

В итоге мы использовали Dojo (1.3) для этого проекта, поскольку в нем был механизм написания модульного JavaScript (dojo.require), для которого мы не смогли найти эквивалент в jQuery. В настоящее время существует несколько библиотек AMD (Asynchronous Module Definition), таких как RequireJS или curl.js, которые можно использовать с jQuery. Если бы я начинал этот проект сейчас (вместо 2008 года), ответ на мой вопрос включал бы использование некоторой библиотеки AMD и, возможно, фреймворка javascript mvc. У Додзе все еще есть все, мы все еще используем это.

Answer 6

Я знаю, что это может быть не вариант, но именно здесь сияет архитектура MVC или MVP. Он устраняет подход «веб-страницы» к разработке вашего веб-сайта и переходит к строго типизированному дизайну кода модели, используя «методы» для вызова нужной логики. Другими словами, в MVC не существует «физических страниц», только методы для объектов.

(Примечание: я НЕ разработчик Java, на самом деле C #, но вы можете понять)

URL:

    /products/532

При переписывании URL это будет "веб-страница" и ее скомпилированный "код", такой как:

/products/showproduct.jsp?productid=532
/products/showproduct.java (code behind)

Но со страницами в MVC это будет:

/Controllers/ProductController.java <- ProductController.ViewProduct(int id)
/Models/ViewModels/Product.java <- Product() class
/Views/Product/Index.html <- very simple display of html.

ProductController выполняет поиск и получает ViewModel для Product (), связывает представление Index, заменяя любые отображаемые переменные, и, наконец, ProductController возвращает заполненный html клиенту.

Этот подход абстрагирует логику веб-страницы в код, которым можно управлять, создавать версии, объединять, разветвлять и т. Д. В вашем исходном хранилище.

Answer 7

Похоже, вы уже знаете, какая часть продукта вам нужна, над чем работают разработчики, и запланировали рабочие нагрузки, чтобы предотвратить наложение. Что-то вроде subversion позволит вам отследить, кто когда, какой элемент добавил в какой документ, а также отменить нежелательные изменения или объединить то, что ранее было перезаписано, и многое другое. Это бесплатно и спасатель. :) HTH