Laisser un commentaire

L'environnement de travail

En tant que développeurs, nous passons d’innombrables heures assis face à notre ordinateur. C’est pourquoi il est primordial de bien s’équiper pour avoir une bonne productivité. De l’écran à l’IDE, j’ai pensé qu’il pouvait être intéressant de partager mes outils de travail.

Les écrans

Quand je parle d’écrans, ce n’est pas tant la marque ou la technologie de dalle qui importe – nous ne sommes pas designers – mais plutôt le nombre. En effet, comme nombre d’entre vous, mon unité centrale se résume à un laptop. Un Macbook Pro 15’’ en l’occurrence.

C’est amplement suffisant en terme de puissance, ça offre une bonne autonomie, l’écran de 15’’ permet de se débrouiller en mobilité, mais un seul petit écran est à mon humble avis suboptimal pour prétendre à une productivité honnête.

On a beau lutter contre le multitasking car notre cerveau n’est pas fait pour cela [en], nous jonglons quotidiennement entre une incroyable quantité de logiciels. Il est bien plus pratique de tout avoir sous les yeux à la fois, plutôt que de constamment naviguer entre différents bureaux virtuels.

bureau config trois écrans
Mon bureau à Lyon
Ainsi, l’écran du laptop sert généralement à héberger des consoles : connexions aux serveurs, outils de build ou de deploy. Et sur un autre bureau virtuel, les emails, des navigateurs de fichiers, des notes…

L’écran du milieu alterne entre le navigateur et mon éditeur de code selon les projets en cours, tandis que l’écran de droite est principalement utilisé pour l’éditeur de code. J’ai également le ou les designs en split view quand je fais de l’intégration.

Partie software

Concentrons-nous maintenant sur les outils que nous utilisons au quotidien. En tant que développeur web, commençons par le navigateur.

Je l’ai déjà mentionné, j’utilise Firefox, la Developer Edition pour être précis. Je n’ai qu’un seul plugin plugin : VueJS devtools. En outre, je trouve le thème sombre très sympa, il s’assortit parfaitement avec les autres outils de dev au design souvent sombre aussi.

Éditeur de code

En 2020, je suis passé de Atom à VSCode, ou plus exactement, VSCodium, la version libre de VSCode. J’ai migré car VSCode est beaucoup plus performant et incroyablement bien documenté.

Par ailleurs, VSCode nécessite peu de configuration et de plugins tiers comparé à Atom. Voici la liste des plugins que j’utilisais dans Atom :

Certains plugins natifs apportent des fonctionalités comme la coloration syntaxique et l’autocomplétion. Il n’est pas inutile de jeter un œil aux snippets d’autocomplétion ainsi que leurs préfixes respectifs. Par exemple, voici ce à quoi vous aurez droit pour le JS.

Les linters

Les linters qui supportent des options permettent en général de les configurer de manière globale ou par projet. La configuration par projet apporte une plus grande flexibilité et présente l’avantage de pouvoir être commité avec ce dernier.

Ainsi, chaque contributeur possède les mêmes préférences. Les préférences locales s’écrivent dans des fichiers de config à la racine du projet. Ces fichiers s’appellent respectivement :

Il faudra également, pour la plupart des linters, installer quelques paquets via Node.js. Nous y reviendrons dans la partie suivante.

L’importance des linters est grande. Ils permettent à la fois d’assurer un style de code homogène et de détecter les erreurs syntaxiques.

Une grosse partie de la config de ces derniers repose en effet sur la partie stylistique. En effet, concernant la partie validité syntaxique du code, il n’y a pas à tergiverser. Soit le code est valide, soit il ne l’est pas !

Linter le HTML

Commençons par le plus facile de tous, htmlhint. Le fichier de conf se génère via le site du projet. Il n’y a pas énormément d’options. Voici le fichier tel qu’il est chez moi.

{
    "doctype-first": false,
    "tagname-lowercase": true,
    "attr-lowercase": true,
    "attr-value-double-quotes": true,
    "tag-pair": true,
    "spec-char-escape": true,
    "id-unique": true,
    "src-not-empty": true,
    "attr-no-duplication": true,
    "title-require": true
}

Mis à part doctype-first que je mets à false car il arrive souvent d’éditer des morceaux de templates qui seront insérés et n’ont donc pas de doctype, le reste se passe d’explications.

Linter les styles

Ça se complique un peu avec stylelint. Comme il y a de très nombreuses règles, on part sur une configuration standard et on affine selon ses goûts au fur et à mesure.

{
    "extends": "stylelint-config-standard",
    "plugins": [
        "stylelint-high-performance-animation",
        "stylelint-no-unsupported-browser-features",
        "stylelint-order"
    ],
    "rules": {
        "declaration-empty-line-before": null,
        "indentation": 4,
        "number-leading-zero": "never",
        "plugin/no-low-performance-animation-properties": [true, { ignore: "paint-properties", "severity": "warning" }],
        "plugin/no-unsupported-browser-features": [true, {
            "browsers": ["> 1%", "not OperaMini all"],
            "severity": "warning"
        }],
        "selector-list-comma-newline-after": "always-multi-line",
        "order/properties-order": [
            "position",
            "top",
            "right",
            "bottom",
            "left",
            "z-index",
            "display",
            …
        ]
    }
}

Vous avez peut-être noté l’utilisation de plusieurs plugins. Le premier, stylelint-high-performance-animation, permet de vous avertir lorsque vous utiliser des animations peu performantes. Je l’ai tout de même configuré pour ne pas m’avertir lors de l’animation de paint (opacity, background…) car ce n’est pas autant pénalisant que l’animation du propriété qui déclenche le layout comme width ou margin.

Le second plugin, stylelint-no-unsupported-browser-features, avertit lors de l’utilisation de propriétés non supportées par les navigateurs ciblés. Ici, je cible les navigateurs représentant plus de 1% d’utilisateurs en excluant Opéra Mini (lequel ne supporte aucune animation donc génère trop de warning).

Le dernier plugin, stylelint-order, permet de forcer l’organisation du CSS selon un ordre précis des propriétés. Certains préfèrent une organisation par ordre alphabétique, pour ma part, je préfère avoir mes propriétés organisées selon une logique fonctionnelle.

Ainsi, les propriétés CSS appartenant à un même groupe logique (ex. positionnement, bordures etc) se trouvent groupées. C’est plus ergonomique à l’écriture et à la maintenance et surtout, comme l’ordre et la répétition se compressent bien (Huffman inside), ça se compresse mieux !

J’avais regardé du côté des configurations prédéfinies de CSScomb pour organiser les propriétés. Libre à vous de faire votre sauce maison.

Linter le JavaScript

Abordons en dernier lieu la configuration d’eslint. Il n’y a pas de configuration par défaut officielle. Je pars donc sur la configuration de AirBnB qui repose sur leur style guide. De manière similaire à ce que je fais avec stylelint, je modifie ensuite la config pour l’adapter à mon style propre.

Je vous présente ma config sans autre forme de procès, ces préférences étant majoritairement des questions de goûts, inutile d’entrer dans les détails. Les commentaires sont toujours ouverts au besoin !

{
    "extends": "airbnb-base",
    "env": {
        "browser": true, // selon qu'on soit en front ou back
        "node": true, // selon qu'on soit en front ou back
    },
    "engines": {
        "node": ">=10" // si nodejs, je précise la version minimale supportée
    },
    "globals": {},
    "rules": {
        "brace-style": ["error", "stroustrup"],
        "comma-dangle": ["error", "never"],
        "func-names": ["error", "never"],
        "import/no-extraneous-dependencies": ["error", { "devDependencies": true, "optionalDependencies": false, "peerDependencies": false }],
        "indent": ["error", 4, { "MemberExpression": 0 }],
        "max-len": ["off", 120],
        "no-continue": "off",
        "no-new": "off",
        "no-param-reassign": ["error", { "props": false }],
        "no-plusplus": "off",
        "no-underscore-dangle": "off"
    }
}

Dans un second article, je vous présenterai comment tirer parti de NPM, le gestionnaire de paquets de JavaScript afin qu’il remplisse tout à la fois les rôles de gestionnaire de dépendances et de task manager. Nous n’aurons ainsi plus à installer et configurer 50 outils différents : one tool to rule them all!

Commentaires

Rejoignez la discussion !

Vous pouvez utiliser Markdown pour les liens [ancre de lien](url), la mise en *italique* et en **gras**. Enfin pour le code, vous pouvez utiliser la syntaxe `inline` et la syntaxe bloc

```
ceci est un bloc
de code
```