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, la console de debug de Firefox.

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 que deux plugins : RESTer pour travailler avec les API et 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

J’utilise Atom comme éditeur de texte. Il semblerait qu’il y ait en ce moment un fort engouement envers VS Code. Mais c’est un produit Microsoft, et les deux évoluant assez rapidement, la situation peut vite changer.

Atom répond à tous mes besoins, possède de nombreux plugins et est Open Source. Si l’envie me dit de modifier le comportement de quelque chose, ou d’ajouter une fonctionnalité, rien ne m’empêche d’ajouter ma brique à l’édifice.

En parlant des plugins, voici la liste des plugins que j’utilise 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 !

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.

Ç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",
  "rules": {
      "indentation": 4,
      "selector-list-comma-newline-after": "always-multi-line",
      "number-leading-zero": "never",
      "declaration-empty-line-before": null,
      "order/properties-order": [
          "position",
          "top",
          "right",
          "bottom",
          "left",
          "z-index",
          "display",
          …
       ]
  }
}

Vous noterez peut-être la partie order/properties-order. Elle permet de forcer l’organisation du CSS via le pluging stylelint-order 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.

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,
        "jquery": true
    },
    "globals": {
        "ga": true
    },
    "rules": {
        "indent": ["error", 4, { "MemberExpression": 0 }],
        "func-names": ["error", "never"],
        "no-new": "off",
        "comma-dangle": ["error", "never"],
        "max-len": ["off", 120],
        "no-plusplus": "off",
        "no-underscore-dangle": "off",
        "no-param-reassign": ["error", { "props": false }],
        "brace-style": ["error", "stroustrup"],
        "import/no-extraneous-dependencies": ["error", {"devDependencies": true, "optionalDependencies": false, "peerDependencies": false}]
    }
}

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
```