Як я можу писати HTML, CSS та JavaScript, щоб полегшити роботу бек-енд-розробників?

Коли я отримую дизайн від дизайнера, я отримую його як файл PSD (Photoshop). Я завжди очікую належних назв шарів і папок, в основному чистий і керований PSD. З цього дизайну я розробляю HTML, CSS та JavaScript і доставляю його до бек-енд-розробників. Щоб полегшити їм розуміння, я

• написати семантичний код,
• зберігати JavaScript і CSS у зовнішніх файлах,
• додайте корисні коментарі у файли HTML, CSS та JS,
• використовувати CSS-спрайти (хоча розробникам це не подобається),
• використовувати плиту котла HTML5,
• використовувати jQuery для JavaScript,
• намагайтеся використовувати нові теги HTML5 та CSS3, коли це можливо і
• надіслав Zip-файл, що містить HTML, CSS, JS та зображення.

Я очікую, що якщо у макеті будуть потрібні невеликі зміни, розробники впораються з цим.

Мені хотілося б почути від бек-енд-розробників та інших CSS-ніндзя, що ще можна зробити з точки зору організації файлів і розмітки, щоб полегшити інтеграцію з бек-енд-системами (тобто бек-енд-технології, PHP, .NET , Ruby тощо). Різний клієнт використовує різні системи.

Багато цих відповідей охоплюватимуть широкий спектр ідей, але ось мої особисті:

• Залиште місце у дизайні форми для повідомлень про помилки.
• Не вставте мітки у поля введення!
• Помістіть свій CSS та JavaScript в окремий файл, якщо ви не знаєте, що робите, і не відчуваєте себе погано.
• Зберігайте елементи дизайну однаковими між сторінками. Вражає, коли компонент дизайну (як-от "недавно переглянуте" вікно) має різну розмітку на кожній сторінці.
• Не робіть того, що вам легко, робіть те, що правильно. <button>теги смоктати. backround-imageдля речей, які дійсно повинні бути <img>тегами смоктати.
• Переконайтеся, що якщо ви створюєте компонент сторінки, він може масштабувати. Я знаю, що це робить більшість хороших розробників, але я мав багато випадків, коли хтось використовував одне зображення в тому, що повинно було бути вгорі та внизу. Програмістам не подобається відкривати Photoshop.
• Перечитай свої шаблони. Програмісти (хороші) - віддані, орієнтовані на деталі люди. Якщо вони починають бачити проблеми у вашому дизайні (можливо, навігація в колонтитулі має орфографічні помилки або непослідовність написання), це змусить їх задавати питання та уповільнити роботу.

Нарешті, і, можливо, найголовніше:

• Вивчіть основні умовності мови, що розробляється в кінці. Можливість перегляду шаблону PHP та розуміння основного синтаксису позаду foreachабо ifоператора, а також відформатування echoзаяви чи переміщення <?php ?>тегу значно збільшить ваше значення як розробника переднього типу - я люблю, коли потрібен розробник переднього типу. щоб зробити просту зміну, і це можна зробити в шаблоні, а не передавати мені нову поштову всіх своїх файлів.
• Як додаток, навчіться використовувати програмне забезпечення для управління версіями. Вам не потрібно бути експертом, але якщо я можу розібратися на розмову, а не намагатися розібратися, що змінилося між двома поштовими файлами, це полегшує мені роботу в сто разів.

Це лише декілька - я впевнений, що їх ще багато, але якщо ви виконаєте все це, ви впевнені, що заслужите повагу та вдячність того, хто перетворює ваші шаблони на веб-сайт.

Очевидне, що я можу придумати, що полегшило б життя хлопця-бійця - це простота в поведінці. При розробці елементів веб-сторінки, що мають різні способи поведінки (перекидання, меню тощо), всю цю поведінку слід стандартизувати загальноприйнятим чином, щоб розробнику не доводилося постійно повертатися до якоїсь діаграми, щоб визначити, яку функцію він виконує потрібно дзвонити, щоб сторінка вела себе.

Сітки не повинні вимагати комірки шляхом керування коміркою даних або функціональних можливостей. Блокові елементи сторінок повинні бути легко визначені як загальні елементи, щоб вони могли легко сегментуватися в коді позаду. Це допоможе розробнику в повторному використанні коду та / або полегшенні зв’язку між різними гранями сторінки.

Області сторінки не повинні перетинати конкретні межі дизайну. Елементи з одного елемента не повинні втручатися в елементи з іншого елемента.

Однак настає момент, коли ви просто не можете уникнути того, щоб розробники стрибали через обпали. Деякі елементи інтерфейсу просто складно побудувати за своєю суттю.

Зауважте, що іноді вам доводиться робити вибір між полегшенням модифікації рішення для бек-енд-розробника та внесенням оптимізованого.

Спрайти CSS, які ви цитували, є хорошим прикладом. Я не розумію, як хтось може створити веб-сайт, коли важлива масштабованість та продуктивність, і посилання на 100 зображень, 5 CSS та 15 файлів JavaScript з кожної сторінки. З іншого боку, спрайти CSS непрості в обслуговуванні, і невеликі зміни в дизайні можуть зажадати великої роботи.

Наприклад, якщо у вас є три піктограми стану, одна нижче іншої, і ви повинні додати четвертий стан, чи додаєте ви четвертий значок у нижній частині зображення, окремо від трьох інших? Або ви додаєте його після третьої піктограми, переміщуючи все інше на дно, щоб було порожнє місце для неї?

Те саме стосується комбінування та мінімізації файлів CSS та JavaScript. Ви повинні зробити це для веб-сайту певного масштабу, але це вимагатиме додаткових зусиль.

Це точно те ж саме для CDN. Ви повинні використовувати його для великих веб-сайтів, але зміни було б важче внести. Наприклад, якщо ви змінили файл CSS, вам доведеться змусити браузери завантажити новий, змінивши URI у файл cdn.example.com/g.css?r=2, а потім cdn.example.com/g.css?r=3і т.д.

Також "легше" відносне . Дивіться, наприклад, рекомендації щодо написання CSS-коду: особисто я віддаю перевагу одному стилю на рядок, без пробілів:

#TopMenu a{text-decoration:none;color:#fff;padding:5px 10px;float:left;}

в той час як більшість людей ненавиджу цей синтаксис і віддають перевагу тому, кого я ненавиджу і мені важко читати (ні, я не божевільний):

#TopMenu a
{
    text-decoration: none;
    color: #fff;
    padding: 5px 10px;
    float: left;
}

Таким же чином, використання jQuery не означає, що ви будете спрощувати бек-енд-розробник змінювати свої файли, оскільки деякі розробники мають більше досвіду з прототипом або іншими рамками.

У всіх випадках корисна детальна документація , якщо розробник хоче її прочитати (більшість з них не робить). Ви також можете полегшити життя розробника, точно запитавши конкретного розробника, як він надає перевагу тому, що потрібно робити, і працюючи поруч на початку, будуючи рамку (наприклад, проектуючи робочий процес, який використовується для мінімізації і об'єднати файли).

Найкраще з усіх світів - це коли дизайнер не кидає поштовий файл на стіну і насправді працює в проекті як один із розробників. Для налаштування потрібне трохи рукоятки, але це справді дивовижно, коли між дизайном та розробником немає перекладу, і кожен може брати участь у одних і тих же ітераціях. Якщо у вас хороший рухливий процес без тертя, це не так важко зробити.

Я б вирішив у більшості випадків дизайнерів, які працюють у контрольованій версії та використовують це як механізм розповсюдження. Я дійсно не хочу мати справу з великим поштовим файлом щоразу, коли є невеликі зміни.

Гнучкість для вас - це гнучкість для них, як правило. Усі ці найкращі практики, яких ви дотримуєтесь, - це виграші з обох сторін програми.

Одним з найважливіших та часто пропущених моментів є написання надійного інтерфейсу користувача. Занадто багато компонентів користувальницького інтерфейсу надмірно прив’язані до одного контексту або надто вимогливого набору HTML, і CSS налаштовано на збій.

Наприклад, якщо у вас є спадне місце, то набагато менше роботи JS прив’язати компонент, що випадає з абсолютним розміщенням у відносно встановленому (не потрібні координати) клацнутому контейнері, ніж витягнути молоток JQuery і отримати координати, щоб його навести поверх елемента і просто приклейте його на місце. Також набагато менше шансів зламатись у випадках, коли сторінка зміщується або якась нова функція браузера скидає інформацію про позиціонування. Чим більше ви покладаєтесь на навички HTML / CSS, щоб уникнути роботи JS, тим більш надійним буде ваш інтерфейс.

Як правило, я намагаюся переконатися, що єдине, в чому потрібні мої компоненти інтерфейсу, - це тег HTML для проживання з відповідним ідентифікатором чи класом. Чим більше ви можете зробити з цим контейнером, без того, щоб інтерфейс інтерфейсу всередині був розбитий або з контейнером фактично розміщувався, як розширення / скорочення, щоб відповідати зміні розмірів контейнера, тим більше це можна легко реалізувати в будь-якій частині програми, не потребуючи клієнта. експерт. Все, що їм потрібно зробити - це наклеїти на нього клас.

Віддайте перевагу делегуванню подій на контейнерах інтерфейсу, щоб призначити слухачам безпосередньо вузли кінцевих точок, як кнопки. Цей компонент інтерфейсу може працювати зі статичним HTML зараз, але ви ніколи не знаєте, коли хтось захоче мати змогу зірвати та переписати HTML всередині черезHTML чи щось подібне. Якщо контейнер недоторканий і всі події делеговані (див. Метод jquery 'on'), вам не доведеться про це турбуватися, і вони ніколи не дізнаються важкий спосіб, що заміна HTML ламає слухачів.

В інтересах збереження делегації як опції не використовуйте stopPropagate ніде, окрім вузлів кінцевої точки, і не надсилайте ненависні листи розробникам ідіотських фреймворків, які розсипають її всюди.

Що стосується макета, то зберігайте HTML мінімально, семантично та уникайте обгортки для ділів. Чим менше HTML, тим простішими проблемами компонування є діагностика новобранців.

Використовуйте назви класів, що роз'яснюються, для утиліти CSS. Клас "рядок", ймовірно, буде більш зрозумілим для нобіїв CSS, ніж "clearfix".

Завжди надайте унікальні секційні елементи, унікальні ідентифікатори. Це набагато простіше визначити, де відбувається матеріал, специфічний для певного розділу, легше переосмислити речі, а також може бути розбірливість та виграш у JS.

Очевидно, що погана новина стає надмірною за допомогою класової схеми, але чим більше "back-dev" може встановити просто додавання правильних класів до речей, тим простіше буде робити зміни на існуючій сторінці.

І звичайно, на початку проекту змушуйте їх погодитися хоча б з цим одним: задній і передній кінці з'єднуються лише через HTML та JSON. Не дозволяйте їм використовувати те, що "пише JavaScript для вас!" Це кривавий безлад і кошмар на підтримку.

Як і у всьому, що стосується розвитку, віддайте перевагу DRY та мінімалізму.

Це все ще не дозволить мені просто коментувати (так дурно), але як зазначення особистого, я б зазначив, що я працюю спільно з кодером PHP щодня (а також допомагаю в його роботі), і найпростіший інструмент, який ми знайшли, це використовувати панель інструментів Комодо і перераховувати "перенесені" змінні кожного перегляду / контролера / моделі в панелі інструментів, так що в будь-який час, якщо я дивлюсь на створення сторінки навколо набору даних, що надсилаються на цю сторінку, я Ви можете заглянути в панель інструментів і побачити, які саме дані надсилаються та які "типи" "вони надсилаються, а також навпаки на його кінці. Просто підказка.