Модулирование веб-приложений

Ответ 1

Веб-разработка определенно приносит определенные организационные трудности. HTML/CSS - не совсем среда сна для разделения работы. Очень важно определить определенные правила и строго следовать им.

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

Например:

вместо

div.question_title
div.question_body

вы можете использовать

div.so_question_title
div.so_question_body

div.su_question_title
div.su_question_body

Также соглашайтесь с командами по некоторым общим данным, например цветам цветовой схемы. Определите их где-нибудь глобально и повторно используйте их везде.

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

Например, если вы определяете стиль CSS таким образом:

div.main_news *
{
    /* ... */
}

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

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

div.news_container
{
    /* Reset styles */
}

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

ОБНОВЛЕНИЕ: Что касается div с UID. Если вы имеете в виду Facebook, я не уверен, какие UID вы имеете в виду. Только скрытые входы имеют некоторые длинные секретные идентификаторы в качестве их значений (главная страница, а не вход в систему), но это, вероятно, является результатом того, что структура автоматически генерирует эти значения по какой-либо причине. Я как-то написал код (для ASP.NET MVC) для помощников Html для создания уникальных идентификаторов во всей области (я хотел полностью привязать флажки с ярлыками по идентификаторам автоматически и прозрачно для меня). Другим случаем может быть то, что среда с ведомыми событиями (например, ASP.NET WebForms) имеет уникальную идентификационную группу, созданную сервером, в качестве требования для поддержки ее работы. Каждый элемент управления должен иметь уникальный идентификатор, чтобы на стороне сервера было известно, какой элемент поднял событие на странице. Также некоторые редакторы WYSIWYG добавили бы автоматические идентификаторы к элементам, когда вы перетаскиваете их и переходите к форме.

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

Ответ 2

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

Не пытайтесь решить проблему на уровне "стандартов" или "как"... решить ее на уровне человека на уровне управления.

Мы используем несколько методов для обеспечения согласованности на уровне управления:

• Поддерживайте инструменты, чтобы разработчик сообщал остальным. Это включает Вики, внутренние дискуссионные форумы и т.д.
• Достаточно среднего уровня управления. Ни одно тело не может знать обо всем, но имеет смысл для человека осознавать все, что находится на его уровне. Таким образом, группа управления пользователями может синхронизироваться с группой безопасности, а группа безопасности может быть синхронизирована с группой управления контентом. Миссия этого среднего руководства состоит в том, чтобы знать достаточно обо всем, не нужно знать каждую деталь, достаточно, чтобы передать ей знания, где это должно быть.
• Добавьте уровни, как вы сочтете нужными, но на каждом уровне должен быть один человек, который смотрит вверх, все делают более или менее одно и то же. Он будет отвечать за повышение тревоги, если две группы делают вещи совершенно по-разному.
• Поддерживайте хороший поток информации. Наличие стандартов имеет важное значение, но позволяет людям фактически ЗНАТЬ, что они выходят, еще лучше, и обеспечить их использование ими, посредством пересмотра кода и еженедельного собрания, совершенно необходимо, если вы хотите продолжать делать что-то строгое.

Я знаю, что многим людям не нравится "управление". Они думают, что это дополнительный слой, который ничего не делает. Ну, это неправда. Управление помогает решать такие проблемы, как именно это. Помогите передать большие команды и общее представление о том, что происходит... есть много "методов", чтобы определить стандарт о том, как делать вещи... все эти методы терпят неудачу, когда нет человека следя за тем, чтобы люди следовали знанию и соблюдали эти стандарты.

Ответ 3

Проблему конфликтов пространства имен можно избежать, используя соглашение об именах. Дополнительное чтение:

• Практика CSS: псевдопространства в сложных проектах
• Поддержка пространств имен CSS - функциональная и дизайнерская спецификация

Вкратце: это зависит от того, как ваша система построена, но при условии, что все составлено из модулей, а затем назовите свои идентификаторы CSS (или JS ID и т.д.) следующим образом: SiteName-ModuleName-Function.

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

# PHP скрипт
class module_articles {
    public function __construct() {
        $this->GUI = new view;
    }
    public function display_articles() {
        // The CSS file is rendered first by the PHP engine and
        // the identifiers name is constructed with the $this->GUI->id property.
        $this->GUI->load_css('path/to/file.css');
    }
}

class view {
    private static $instance_number = 0;
    public $id;

    public function __construct() {
        $this->id = ++ self :: $instance_number;
    }
    public function load_css($path) {
        // $id can also be the CSS file path (slashes replaced with underscore)
        // or the module name itself (e.g. module_articles)
        $id = $this->id;
        include $path;
    }
}

В конце концов, файл CSS должен выглядеть примерно так:

/* CSS of module_articles */

<?php echo $id ?>author_name { /*...*/ }
<?php echo $id ?>article_date { /*...*/ }

Примечание. Файл должен быть включен через ключевое слово PHP include! Используйте Output Buffering, чтобы вывести его позже.

Ответ 4

В CSS-структурах, таких как Shaun Inman, есть много чего сказать CSScaffold. Он позволяет подразделять таблицы стилей, определять константы, легко обрабатывать локальные контексты и т.д. Это не решает вашу проблему, но это может быть большой помощью.

На стороне Javascript можно работать с локальными контекстами, хотя я редко когда-либо сталкивался с проблемами.

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

Ответ 5

Я работал с несколькими проектами с одним веб-сайтом, из своего опыта

ваши команды diff должны сидеть один раз, чтобы установить несколько простых соглашений css

например

обр-search.css

.mod-search .title { }
.mod-search .text { }

обр-news.css

.mod-news .title { }
.mod-news .text { }

в производстве используйте свой передний фронт, чтобы объединить все ресурсы в один

также делает то же самое с js, на самом деле js легче управлять, чем css

убедитесь, что каждый модуль завернут в свое закрытие

Я использую YUI в качестве примера

MOD-search.js

(function(){
   var node = Y.Node.create('<div/>').addClass('mod-search'); 
   // hook your event to this module node only
   node.delegate('click', handleSearch, 'button.search');
}());

mod-news.js

(function(){
   var node = Y.Node.create('<div/>').addClass('mod-news'); 
   // hook your event to this module node only
   node.delegate('click', handleViewNews, 'a.view-news'); 
}());

all-in-one.js.php

//
// php set content type text/javascript
//
YUI().use('node', 'event', function(Y){
   // php include mod-new.js
   // php include mod-search.js
}); 

HTML

<html>
    <head>
        <link href='all-in-one.css.php' rel='stylesheet' />
    </head>
    <body>
        <script src='all-in-one.js.php' ></script>
    </body>
</html>

Ответ 6

Если вы действительно хотите знать, просто откройте firebug и займитесь spelunking через сайт facebook.

Через 30 секунд вы обнаружите, что они редко применяют css к divs через идентификаторы; и вместо этого использовать много нот класса точек.

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

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

Ответ 7

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

В некотором смысле вы правы, есть компонент, который обрабатывает такие вещи.

Ответ 8

Моя компания делает деловые веб-приложения.

В большинстве случаев мы используем SOA Architectre с интерфейсом ADF или PHP, поэтому не имеет значения, как называются вещи, потому что большая часть HTML отображается из компонентов (это уменьшает свободу, которую вы имеете в свободном HTML, но делает он быстрее развивается).

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

Большим преимуществом является то, что вы можете повторно использовать некоторые Web-сервисы в разных Приложениях, не связываясь с оригинальным разработчиком.

Ответ 9

Соглашения UI должны быть документированы, когда несколько команд разрабатывают интерфейсы.

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

Ответ 10

Это не то, что должно произойти "на лету", оно запекло в структуре компании. Не знаю, как это делает Facebook или любой другой конкретный сайт/компания, но это может быть так же просто, как поддерживать единую таблицу базы данных. Как:

project_namespace

• ID
• Пространство имен
• каталог

Итак, у вас есть ваше основное приложение (1, 'core', '/htdocs/core'). Вероятно, это ответственный представитель PM или старший, и некоторые обезьяны создают и поддерживают его - дополнительную таблицу базы данных, если HR уже не управляет этим отношением, но это не имеет значения здесь. Для каждого пространства имен требуется общая структура. /css для файлов CSS,./templates для шаблонов HTML./js,./images и т.д. Опять же, для этого может быть таблица db, но она не имеет отношения к этому примеру. Добавить любое количество других команд - поиск (2, 'поиск', '/htdocs/search'), учетные записи (3, 'users', '/htdocs/users'), ребята веб-сервисов (4, 'services' '/htdocs/services/') и т.д. Каждое значение уникально, и я просто делаю это, поэтому, пожалуйста, игнорируйте отсутствие деталей.

Теперь у вас есть процесс сборки - script или серия сценариев, которые извлекают все из исходного кода, запускают CSS и JS minifiers и, как правило, компилируют все разрозненные части на веб-сайт. Он загружает пространства имен из таблицы db и добавляет их (или только уникальные идентификаторы) к каждому соответствующему правилу CSS, идентификатору HTML-элемента, классу Javascript или тому, что необходимо. "Ядро" пространство имен, вероятно, будет иметь некоторые специальные правила, позволяющие другим пространствам имен вызывать его, своего рода мета-API (опять-таки не столь соответствующий этому примеру, но реалистичный).

Это суть, по крайней мере, но это не обязательно связано с чем-то, что я только что упомянул. Для некоторых команд, которые могут быть просто напоминанием электронной почты о "FTP ваши изменения здесь, но дергайте, вы лучше не перезаписываете мои вещи", а для других это 3-кольцо связующего правила, реализованного с жесткой конвейерной линией, подключенной к любому количеству контролеры ошибок и инструменты проверки кода, автоматы, выполняющие модульные тесты и обработчики make файлов, а также проверки разрешений и т.д. и т.д. Думаю, Facebook больше склоняется к последнему.

Короче говоря: организация информации и процесс сборки, чтобы поддерживать ее.

Итак, каждый может (и должен) знать, что другие называет свои теги div и JS-функции и все остальное важное, благодаря этому зловещему объекту MCP, поддерживающему правила и выдающему имена. При правильном процессе и инструментах вы никогда не узнаете.