Réponse courte : en permettant à chacun de se concentrer rapidement sur la tâche à accomplir.
Par « concentration », j’entends simplement décider de ce qui est concerné et de ce qui ne l’est pas. Pour une entreprise qui existe depuis plus de 200 ans et qui est en ligne pendant un huitième de ce temps, une prolifération de systèmes est inévitable. Personne ne parviendra jamais à saisir toute la complexité. En effectuant un zoom arrière, nous créons des schémas architecturaux pour nous aider à comprendre comment les différentes parties s’emboîtent ; et en zoomant, nous écrire du code qui nécessite aussi peu de contexte que nécessaire.
Dans cet article de blog, je vais :
-
discuter des avantages de la normalisation ;
-
décrire les outils que nous avons créés pour maintenir la cohérence ;
-
proposent quelques réflexions sur l’équilibre entre familiarité et innovation.
-
« Moins nous avons besoin de savoir pour être utiles, plus nous pouvons faire. »
Les avantages de la normalisation
“Moins nous avons besoin de savoir pour être utiles, plus nous pouvons faire. »
Généralement, les tâches d’ingénierie prendront la forme d’un demande de tirage suivi d’un déploiement. Une pull request est une proposition visant à modifier des parties du code d’un projet. Un déploiement prend le code avec les modifications implémentées et l’exécute en production. La première étape consiste à décider ce qui doit changer. Une documentation claire et une organisation du code sont essentielles pour trouver le fichier à modifier. Supposons une grande diligence de la part des développeurs précédents : ils ont trouvé le fichier rapidement. Le choix des nouvelles instructions dépendra de la familiarité avec le langage de programmation. Heureusement, nous organisons des groupes d’apprentissage des langages de programmation pour les langages courants au Guardian, afin qu’ils apportent les changements en toute confiance. Confirmer si le changement a eu l’effet souhaité dépendra de l’exécution réelle du programme. Les commentaires instantanés accélèrent le développement et permettent aux utilisateurs de l’exécuter localement, sur leur propre machine. Après avoir testé localement, ils peuvent émettre la pull request. Cela lancera le Intégration continue pipeline : une série de tests qui garantissent que le changement n’a pas d’effets négatifs sur d’autres parties du programme. En cas de succès, et avec l’approbation de leurs collègues, ils peuvent fusionner les modifications. À son tour, cela devrait déclencher un pipeline de déploiement continu, garantissant que la dernière version du programme est automatiquement exécutée en production.
Pour aider les développeurs à se sentir autonomes, nous promouvons des modèles cohérents qui contribuent à réduire charge cognitive étrangère via un ensemble croissant de recommandations de bonnes pratiques dans toutes nos équipes. Ceci est essentiel, en particulier sur les référentiels contenant des milliers de fichiers, où les possibilités de distractions et de surprises abondent. Les développeurs n’ont pas besoin d’apprendre un tout nouvel ensemble d’outils pour chaque demande d’extraction. La répétition aide à renforcer la confiance. En partageant des outils, nous garantissons que les développeurs peuvent s’appuyer sur leurs connaissances existantes.
De superbes outils pour un bricolage heureux
Lorsque rien n’est fait, les systèmes deviennent de plus en plus complexes au fil du temps, à mesure que des solutions uniques sont appliquées à chaque nouveau problème rencontré. Pour trouver des similitudes, nous devons avoir une vision d’ensemble, à travers le temps et les équipes. Lorsqu’un problème a été rencontré suffisamment de fois, disons au moins trois, il peut être utile de créer un modèle unificateur. Notre équipe d’expérience développeur, créée en 2018, est spécifiquement orientée vers la résolution de ces problèmes en créant les bonnes abstractions sur les tâches courantes. Nous visons des suites de tests, des gestionnaires de packages, des scripts de construction, des stratégies de formatage de code et de déploiement cohérents.
Un exemple d’abstraction est la bibliothèque du kit de développement Cloud (CDK)qui permet de configurer l’infrastructure sous forme de code et de déployer un microservice sur AWS – les déploiements sont également orchestrés avec Racaille, qui permet un déploiement et des restaurations continus. Il peut être difficile de trouver le bon équilibre entre des valeurs par défaut raisonnables et la possibilité de personnalisation, en particulier lors de la création pour des dizaines d’équipes différentes.
L’équipe d’expérience Web, qui s’occupe du site Web du Guardian, utilise un JavaScript isomorphe (JS) pour fournir HTML, CSS et JS à nos lecteurs depuis nous avons revu pour la dernière fois notre niveau de rendu. Cela permet de créer des composants contenant leurs styles, leur représentation DOM et leur comportement dans un seul fichier. En tant que langage de programmation, JavaScript est un langage multi-paradigmes, ce qui signifie qu’il peut être utilisé dans des styles de programmation fonctionnels ou impératifs. Il est typé dynamiquement, ce qui signifie que vous ne pouvez pas appliquer les signatures de méthode. Il évolue également constamment sous le Spécification TC39, ce qui signifie que de nouvelles syntaxes et fonctionnalités sont fréquemment ajoutées, avec différents niveaux de prise en charge dans les navigateurs comme Chrome, Firefox et Safari et les environnements d’exécution de serveur comme Node et Deno. On ne peut pas s’attendre à ce que les développeurs prennent tout cela en considération pour chaque modification qu’ils apportent. Par exemple, vous pouvez transformer un Liste de nœuds dans un tableau de Éléments d’au moins cinq manières différentes :
Si la flexibilité de JavaScript est ce qui lui a permis de gagner en popularité, c’est aussi ce qui le rend très imprévisible. Heureusement, les outils automatisés peuvent vous aider. Nous utilisons TypeScript et ESLint pour minimiser le risque d’erreurs d’exécution. Grâce à un peluchage et un formatage cohérents, nous pouvons réduire le nombre de façons différentes d’accomplir la même tâche. La configuration de ces outils nécessite une multitude de fichiers et de dépendances, qui peuvent eux-mêmes être fragiles. Pour la plupart de ces outils, nous publions les configurations par défaut sous le Portée @guardian sur NPM. Nous avons également créé un monorepo côté client l’année dernière, qui est livré avec tous ces paramètres par défaut préconfigurés et est devenu le foyer de la plupart de nos bibliothèques JS.
Équilibrer familiarité et innovation
Nous voulons que les équipes soient habilitées à prendre les décisions qui soutiendront le mieux leurs objectifs. Plutôt que d’appliquer strictement les normes dans toutes les équipes, nous essayons de démontrer les avantages de chaque norme individuellement. Cela garantit qu’il existe une incitation à créer d’excellents outils qui sont agréables à utiliser, plutôt que des outils où les normes sont perçues comme des obstacles inutiles que les ingénieurs doivent franchir. Nous souhaitons trouver le juste équilibre entre robustesse et résilience. Tous les programmes ne doivent pas être écrits dans le même langage, ni avoir les mêmes garanties de type ou couverture de tests strictes. Le code doit sembler familier, mais cela ne doit pas entraver l’innovation. Heureusement, nos ingénieurs disposent de 10 % de leur temps pour leur développement personnel, où ils sont libres d’explorer de nouvelles idées et de nouveaux modèles audacieux – un élément clé de ce qui aide l’innovation à prospérer et à améliorer constamment nos processus de travail.
Abonnez-vous à notre page Facebook: https://www.facebook.com/mycamer.net
Pour recevoir l’actualité sur vos téléphones à partir de l’application Telegram cliquez ici: https://t.me/+KMdLTc0qS6ZkMGI0
Nous ecrire par Whatsapp : Whatsapp +44 7476844931
Jeu de briques
Snake
Pacman
Bubble