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

Question

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

Answer 1

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

Answer 2

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

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

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

Попросите третьего человека выполнить всю работу переднего конца с помощью jQuery.

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

Answer 3

Если у вас будет несколько человек, работающих с одними и теми же файлами, ваш SCM должен иметь возможность управлять этим для вас.

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

(Примечание: Я не разработчик Java, C# на самом деле, но и может получить идею)

Адрес страницы:

/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 продукта(), прокладывает представление индекса, заменяет любые отображаемые переменные и, наконец, ProductController возвращает завершенный html клиенту.

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