Paris-Web 2010 Industrialiser l'artisanat de l'intégration Web by Mind Map: Paris-Web 2010 Industrialiser l
4.0 stars - 1 reviews

Paris-Web 2010 Industrialiser l'artisanat de l'intégration Web

HTML

Production

Zen Coding

Utiliser des patterns existants et/ou reconnus (microformats, microdata, RDFa)

Utiliser des techniques trop techniques (que seul le développeur initial comprend)

Créer des classes HTML "visuelles" (type -left, -right, .redblock, .block214)

Pré-processeurs (HAML)

Gabarits HTML complets (page type)

Framework (Boilerplate)

Équipe

Consensus d'un IDE commun

Versionning et gestion de projet

Considérer l'intégration comme une intervention ponctuelle. Problème de maintenance et d'évolutions par les dev back

Expliquer / montrer son code aux développeurs. Permet d'effectuer des ajustements en amont et de faciliter leur travail d'intégration, et de donner des directives qui permettront de gagner du temps par la suite.

Documentation

Conventions de nommage pour les classes CSS

Antisèche sur le projet (??)

Tests

Validateur HTML (W3C ou ??.nu)

Selenium IDE. Permet de vérifier la génération du back par rapport à la maquette front.

HTML Tidy ; pour vérifier que le code est bien formaté.

Supprimer la visibilité des images, regarder le résultat ; supprimer la visibilité des CSS, regarder le résultat ; supprimer la visibilité du JavaScript, regarder le résultat ; essayer de naviguer. Pour toutes les pages. Permet de tester l'accessibilité.

Outliner (HTML5 Outliner).

Opquast.

Prévoir recette finale HTML/CSS avec l'intégrateur.

JavaScript

Production

Utiliser la délégation d'évènements.

Utiliser la délégation d'évènements sur les évènements de survol ; peut causer des artefacts visuels.

Utiliser e.preventDefault() au lieu de return false.

Ajouter/supprimer des classes plutôt que modifier le style CSS inline.

Gérer la mise en forme.

Intégration non-intrusive (écoute d'évènements).

Écouter les bons évènements (focus en plus de click par exemple).

Masquer en CSS des contenus qui seront affichés en JS. Si pas de JS, on prive l'utilisateur d'une partie du contenu.

Itérer sur des liveElements (à confirmer).

Polluer l'espace de nom.

Ne pas utiliser var (ne pas bien utiliser le scope).

Créer des plugins réutilisables, sous forme de logique métier, plutôt que du code spécifique, hors fonction, non-réutilisable.

Se baser uniquement sur JS pour valider/vérifier un formulaire.

Se fier à JS pour l'aspect sécurité.

Injecter trop de HTML. Mauvais pour la visibilité du DOM et les performances.

Être uber produdent si on étend le DOM.

Minifier.

Concaténer.

Mélanger plusieurs frameworks, redondants de surcroît.

Équipe

N'utiliser que « The Good Part ».

Penser aux impacts sur la performance.

Connaître JavaScript et pas seulement la librairie (jQuery, MooTools etc.).

Versionner.

Documentation

JSDoc.

Pour tous les plugins tiers, y adjoindre/conserver un lien vers la documentation.

Tests

JSLint.

Firebug.

Tests unitaires (QUnit etc.).

CSS

Production

Utiliser des techniques trop techniques (que seul le développeur comprend).

Refactoriser, purger le code mort.

Charger via commentaires conditionnels pour IE.

Utiliser les microformats pour poser le style. Il faut utiliser des classes dédiées ; pour éviter de lier fond et forme.

Ne pas prendre en compte l'ordre de chargement des CSS.

Utiliser des hacks.

Utiliser des filtres IE.

Utiliser "expression".

Concaténer les fichiers.

Atomiser les CSS (multi-classes).

Fragmenter à l'extrême (surtout sans concaténer, peut poser problème avec IE qui a une limite à X fichiers).

Préprocesseurs (LESS, SASS)

Utiliser reset.css + typography/base.

Oublier :focus à côté de :hover. Permet de signaler à l'utilisateur l'élément actif alors qu'il navigue au clavier. :hover implique une utilisation de souris ou d'un dispositif de pointage.

Équipe

IDE (ou éditeur) avec auto-complétion.

Dégradation des CSS par navigateur.

Convention de codage. Indentation, ordre des propriétés, organisation des fichiers etc.

Versionner.

Faire valider le rendu de l'intégration par le webdesigner.

Utiliser un framework/librairie.

Écrire une nouvelle définition systématiquement en fin de fichier. Il vaut mieux respecter la logique de groupement déjà en place.

Documentation

CSSDoc

Placer des liens pour renvoyer vers des fix ou exemples.

Indiquer les fix pour IE au niveau des déclarations concernées.

Utiliser le même sélecteur de règle pour un fix IE.

Tests

Prévoir recette finale HTML/CSS avec l'intégrateur.

Validation (W3C, Jigsaw)

Performances (PageSpeed, YSlow)

Gabarits HTML de test

Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Soyez prêts à commencer

Vous avez déjà un compte ?
Entrer