RETOUR
Cet épisode devait être publié en décembre, avant les vacances de Noël, et il semble donc que ce soit moi qui sois responsable de ce retard. J'ai continué à retarder la publication semaine après semaine en raison de quelques tâches prioritaires, mais aujourd'hui, c'est LE jour.
Dans le dernier épisode, j'ai tenté de commenter l'article sur l'importance de l'humour sur le lieu de travail, mais entre-temps, j'ai compris qu'il méritait beaucoup plus d'attention et je vais donc écrire un article entier sur le blog à ce sujet bientôt.
Les choses qui m'ont occupée ces deux dernières semaines :
a) Avant Noël, j'ai commencé avec le premier épisode de Série de webinaires "Bulletproof CTO" (en anglais) (attendez le deuxième épisode, en février, consacré au SaaS) CTOs(détails à venir sur mon LinkedIn).
b) Nous mettons au point notre plan de croissance pour 2021, avec l'objectif d'aller au-delà de notre activité principale Ruby et JS et de développer une activité Magento et Produit Compétence en matière de conception interne.
Assez d'autopromotion, laissez-moi vous inviter au 5ème épisode de notre série #TheCodestReview.
Sujets mon équipe s'est préparée pour cette période :
Les commentaires sur l'application frontend et les commits conventionnels sont livrés cette semaine par nos ingénieurs React tandis que Ruby 3.0.0 est livré par notre Ruby dream team.
Aujourd'hui, de nombreux développeurs utilisent, pour gagner du temps, des bibliothèques d'interface utilisateur et des composants réutilisables. C'est une bonne pratique et cela nous aide à gagner beaucoup de temps, mais lorsque notre projet devient plus importante - vous comprendrez qu'il n'est pas suffisant de gérer avec des code.
Il existe deux bons modèles de développement back-end : le développement piloté par le domaine (DDD) et la séparation des préoccupations (SoC). Nous pouvons également les utiliser dans l'architecture frontale.
Dans le cadre de la méthode DDD, nous essayons de regrouper des fonctionnalités similaires et de les découpler autant que possible d'autres groupes (modules).
Alors qu'avec SoC, nous séparons par exemple la logique, les vues et les modèles de données (par exemple en utilisant le modèle de conception MVC ou MVVM).
Il existe un grand nombre de bonnes pratiques et de modèles à utiliser, mais c'est cette méthode que je préfère.
Lorsque nous utilisons ce modèle, nous obtenons l'image suivante :
Au début, l'utilisateur est redirigé vers le bon module par le routage de l'application. Chaque module est entièrement contenu. Mais comme l'utilisateur s'attend à utiliser une seule application, et non plusieurs petites, il y aura un certain couplage. Ce couplage porte sur des fonctionnalités spécifiques ou sur la logique d'entreprise.
Et nous avons cette structure :
dossier app - couche application
assets - dossier pour les images, les polices, les icônes, etc.
composants - il s'agit de composants réutilisables qui n'ont pas de logique compliquée
config - c'est ici que nous stockons l'état global
lib - dossier pour les fonctions compliquées et les calculs logiques
modules - voici nos modules
pubsub - lieu de stockage des schémas décrivant la structure des données.
styles - pour notre code css/scss
Cette structure nous aidera à gérer la croissance de notre application et à réduire les bogues. Elle nous aidera également à travailler plus confortablement avec des modules séparés, à les tester et à faciliter le remaniement et le débogage (grâce à la séparation des modules).
Si nous examinons plus en détail l'architecture des modules et leurs connexions avec l'API, nous obtiendrons quelque chose comme cela :
Dans le dossier "app", nous créerons un autre dossier "api" avec le code pour les appels à l'API et les données que nous enregistrerons dans "config/store". Nous conservons ici les données statiques et immuables que nous utilisons dans l'ensemble de l'application.
Dans le dossier "pubsub/schema", nous décrirons également les types de données spécifiques pour les éléments suivants JavaScript objets.
Tous les modules contiennent des données que nous devons utiliser (utilisateurs, itinéraires, tables, actions, etc.). Chaque module est connecté à la couche d'application et prend toutes les données nécessaires.
Le front-end est le premier point d'entrée pour nos utilisateurs. Avec l'augmentation des fonctionnalités de nos projets frontaux, nous introduirons également plus de bogues. Mais nos utilisateurs s'attendent à ce qu'il n'y ait pas de bogues et à ce que de nouvelles fonctionnalités soient introduites rapidement. C'est impossible. Pourtant, en utilisant une bonne architecture, nous ne pouvons qu'essayer d'y parvenir autant que possible.
Imaginez que vous soyez au point de départ d'une entreprise dans laquelle vous venez d'être embauché. Tous les gens sont gentils avec vous et tout semble bien se passer jusqu'au moment où l'on vous présente une base de code datant d'avant que le JavaScript ne soit un langage et que Netscape ne charge une page pendant ce qui semblerait être une éternité.
L'héritage du code semble être un problème majeur lorsque l'on présente un projet à de nouveaux développeurs. Lire le code est une chose, mais comprendre comment l'application a été développée n'est pas tout à fait la même chose. Souvent, les commits s'avèrent utiles et donnent le contexte pour expliquer pourquoi ces console.logs n'ont pas été capturés par linter ou pourquoi ce méchant // TODO est là pour les enfants du développeur qui a initialement fait l'annotation.
Commençons par expliquer pourquoi les règles de validation conventionnelles sont préférables aux règles de validation non standardisées.
Si nous recrutons de nouveaux développeurs pour un projet dans lequel la plupart des commits consistent en des messages du type "ça devrait marcher" ou "Sleepy fix for footer ASAP", qu'est-ce qui vous vient à l'esprit ?
Je dirais qu'il y a des signaux d'alarme parce que.. :
Comme votre équipe peut appliquer des règles personnalisées au moment de la validation des modifications, il y a moins de place pour l'erreur, car votre validation doit être solide. Il ne s'agit plus d'un simple moyen de quitter le site. C'est une signature qui indique aux autres personnes que vous connaissiez le contenu du commit. Inutile de préciser que si le travail que vous avez effectué n'est pas correctement signé, il en résultera très probablement une erreur et un message d'avertissement.
Il est possible que votre équipe souhaite mettre en place une règle interdisant certains mots-clés, de sorte que ASAP ou tout juron puisse figurer sur la liste noire.
Au début du projet, il est très utile de présenter à tout le monde la façon dont votre projet est mis en œuvre. équipe de développement aimerait que les nouveaux développeurs livrent leurs modifications. Ensuite, mettez en place un outil qui les aide à suivre ce sur quoi vous vous êtes mis d'accord.
L'un des outils avec lesquels j'ai eu l'occasion de travailler est le suivant commitlint et cela a fait des commits conventionnels ma pratique de prédilection lorsque j'arrive sur de nouveaux projets qui n'ont pas de règles et que l'équipe est ouverte à l'idée de les introduire.
Lorsque vous vous occupez des paramètres et que vous les répartissez au sein de votre équipe, vous pouvez simplement créer un paquet npm et l'ajouter à chaque projet. Cela aidera certainement tous les membres du projet à être sur la même longueur d'onde à tout moment et, si nécessaire, à passer d'un projet à l'autre en comprenant ce qu'ont été les derniers changements (et pourquoi ils ont été faits).
Maintenant, après avoir mis tout cela en place et compris pourquoi il pourrait être une bonne idée de commencer à utiliser CC, la meilleure partie serait de programmer autour des règles que vous venez d'appliquer ! Nous utilisons une méthode standardisée de validation, nous prêtons plus d'attention à ce que la validation était vraiment, alors pourquoi ne pas mettre en place des crochets qui vous permettent de faire des tests rapides sur la mise en scène lorsqu'un drapeau est présent ? Nous ne voulons pas surcharger les services et réduire les coûts quand c'est nécessaire, et il y a quelques raisons de tester sur un serveur de type production plutôt que sur l'hôte local.
Supposons que vous travaillez sur une PWA et que le SSL est nécessaire pour tester tout le potentiel et que vous avez un SSL sur votre plateforme de test. Tout ce dont vous avez besoin maintenant, c'est d'un bon commit. Quelque chose comme feat(PWA) : manifest icons workbox setup upload déclencherait toute la machinerie de test et de déplacement des roues dentées. Nous n'avons pas besoin de cela lorsque nous téléchargeons simplement des données statiques comme manifest.json, nous ajoutons donc un drapeau [TEST_SKIP] en postfixe à notre commit. Cela permet à notre CI de simplement télécharger de nouveaux actifs dans l'environnement de test et de sauter les tests. Pour en savoir plus ici
Au bout d'un certain temps, vous pourrez constater d'autres avantages, tels que la facilité de génération de CHANGELOG et un meilleur versionnage avec version sémantique. Si cela ne suffit pas à vous convaincre de changer votre façon de rédiger des messages d'engagement, peut-être que le fait de tremper vos orteils dans l'eau fraîche et d'essayer de les utiliser dans votre dépôt privé pendant un certain temps vous fera changer d'avis.
Joyeux engagement conventionnel !
Longtemps attendue par la communauté, la version 3.0.0 de Ruby a vu le jour à Noël, afin que tous les développeurs Ruby puissent la trouver sous le sapin dès leur réveil. Chez The Codest, nous cultivons la culture du partage des connaissances en organisant des réunions hebdomadaires au cours desquelles nos ingénieurs discutent des tendances technologiques et de leurs nouvelles découvertes qui méritent l'attention. Vous trouverez ci-dessous un lien vers les diapositives de la journée de démonstration au cours de laquelle notre ingénieur Ruby senior a discuté de quelques changements importants dans Ruby 3.0.0 de son point de vue subjectif :
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
De plus, notre mentor Ruby a contribué à la nouvelle version avec sa demande d'extension qui a été fusionnée avec succès. Pour en savoir plus sur les méthodes de contrôle de la vie privée, vous pouvez consulter l'article de notre responsable du développement.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
Merci beaucoup d'avoir lu et si vous êtes arrivé jusqu'ici, j'apprécie votre temps et chaque commentaire est le bienvenu sur LinkedIn ou à mon adresse électronique.
Nous vous reviendrons avec le prochain épisode à la fin du mois de février avec la revue d'un podcast interviewant CTO de Shopify, l'homme derrière une équipe d'ingénieurs travaillant sur la magnifique application monolithe Ruby !
A bientôt.
En savoir plus :
TheCodestReview #4 - jus hebdomadaire de génie logiciel
French 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
Arabic 
Italian 
Japanese 
Korean 
Polish