Lorsque j'ai extrait le code du projet du référentiel distant vers le local pour la première fois après avoir rejoint et acheté la voiture - "Qu'est-ce que c'est ?!" - J'ai été choqué et surpris.

Pourquoi est-ce que je réagis comme ça ?

Acheter une bonne voiture est une entreprise avec des gènes d'Ali, de nombreux fondateurs et employés sont d'Ali. Comme nous le savons tous, la technologie d'Ali est très bonne. Fondamentalement, il accueille des conférences techniques chaque année, et certains livres techniques sont également écrits ou traduits par des gens d'Ali. Par conséquent, psychologiquement, il y aura des attentes plus élevées pour eux en termes de technologie. Cependant, la réalité qui m'est présentée m'a sorti de mon fantasme...

entretien des codes

Contrairement à la plupart des équipes, le code front-end et back-end sont maintenus ensemble. Notre code de projet est géré et maintenu séparément, c'est-à-dire que le code front-end et back-end ne se trouvent pas dans le même référentiel Git. Le code front-end n'a qu'un seul entrepôt, qui stocke les codes des différents métiers tels que les ressources publiques, les pages d'activités, les sites principaux. Chaque projet est un annuaire, le code back-end est stocké dans plusieurs entrepôts différents sur un projet - par projet. Le déploiement et la mise en service sont également effectués séparément.

Cette approche est appelée par euphémisme "séparation des extrémités avant et arrière", mais cela vaut la peine de se demander si elle est réellement vraie.

Utilisation de Git

Les équipes rencontrent deux problèmes principaux avec Git : les stratégies de gestion des branches et les directives de validation du code.

Stratégie de gestion des succursales

Chaque fois que vous ouvrez Sourcetree, la première chose qui attire votre attention est la "ligne arc-en-ciel" colorée——

image

et certaines branches obsolètes -

.
└─┬─ origin
  ├─── dev_frontend
  ├─── dev_general
  ├─── dev_inquiry
  ├─── dev_maiche
  ├─── pub_20160111
  ├─── pub_20160112
  ├─── pub_20160113
  ├─── pub_20160114
  ├─── pub_20160128
  ├─── pub_20160202
  └─── ...

Ça m'a donné le tournis, je ne sais pas par où commencer !

La raison la plus directe de cette situation est qu'il n'y a pas de bonne stratégie de gestion des succursales. La stratégie de gestion des succursales ici est la suivante :

Il y a deux jours de release fixes par semaine.Avant chaque jour de release, un ingénieur de test qui gère la release (oui, nous n'avons pas d'ingénieur d'exploitation et de maintenance) va  créer  une branche release avec master un préfixe préfixé   branche pour publication après passage. Cependant, cette branche ne sera pas supprimée immédiatement après la sortie, mais sera conservée pendant quelques semaines pour éviter les problèmes. Cela laissera beaucoup de branches obsolètes comme dans l'image ci-dessus.pub_master

Pour certains contenus qui ne sont pas publiés immédiatement, les ingénieurs back-end  master créeront une  dev_ branche préfixée basée sur la branche pour développer de nouveaux contenus.

Bien qu'ils aient tous certaines règles pour créer des branches, cette pratique crée des branches "déchets", et rend  master les branches moins stables et "boom" comme une bombe à retardement !

Je pense que Git Flow devrait être utilisé dans l'équipe pour gérer les branches. C'est un modèle de branchement qui a été éprouvé par de nombreuses équipes, et je suis convaincu qu'il peut gérer divers scénarios que notre équipe rencontre.

Directives de soumission de code

Les commits Git de notre équipe sont très "simples", soit écrits avec quelques lettres ou mots simples, soit des nœuds générés lors de la fusion de branches, et d'un coup d'œil, il est impossible de savoir ce que ces personnes ont réellement fait. Si vous voulez trouver l'enregistrement de modification d'un point de fonction, vous devez l'analyser nœud par nœud.

Il y a une règle de base à suivre lors de l'utilisation de Git - gardez le journal de validation aussi concis et détaillé que possible, c'est comme lire un livre. Pour obtenir cet effet, gardez juste quelques points à l'esprit :

  • Contrôler la granularité des soumissions ;

  • Remplissez les informations de soumission ;

  • Ajustez la fréquence de poussée ;

  • Plus de spin-offs et moins de fusions.

Pour rendre chaque validation significative, la granularité est mieux contrôlée sur une petite fonctionnalité ou une correction de bogue, afin que des opérations telles que la récupération puissent minimiser les "blessures accidentelles".

Un bon message de commit est écrit en une phrase concise sur la première ligne, suivie d'une ligne vide détaillant ce qui a été ajouté ou modifié dans le commit :

Redirect user to the requested page after login

https://trello.com/path/to/relevant/card

Users were being redirected to the home page after login, which is less
useful than redirecting to the page they had originally requested before
being redirected to the login form.

* Store requested path in a session variable
* Redirect to the stored location after successfully logging in the user

Ne le poussez pas à chaque fois que vous le soumettez, mais accumulez quelques soumissions supplémentaires et poussez-les en même temps, afin d'éviter de petites erreurs dans le code après la soumission précédente.

Afin de garder les diagrammes clairs et le code intact, il est nécessaire de saisir le timing des opérations de commit et de push -

Lorsqu'il n'a pas été poussé vers l'entrepôt distant, si ce n'est pas nécessaire, soumettez-le simplement et ne le poussez pas, et ne le poussez que lorsqu'il est nécessaire de coopérer avec d'autres pour le développement. Lorsque la branche à laquelle vous appartenez a terminé ses responsabilités, vous devez rebaser le code de la branche mère vers la branche actuelle (vous devez d'abord vous assurer que la branche mère est à jour localement), puis le fusionner dans la branche mère et supprimer la branche courante. Idéalement, cette branche n'a jamais été poussée une seule fois de toute sa durée de vie .

Lorsqu'il a été poussé vers l'entrepôt distant, accumulez plusieurs contenus soumis sans valider. Lorsqu'il est temps de pousser, tirez d'abord le code vers le local, puis faites plusieurs commits selon la granularité ci-dessus, puis poussez-le vers le distant serveur. Ce processus d'opération peut efficacement éviter des problèmes inattendus tels que des validations perdues causées par des conflits de code, et réduire le nombre de nœuds de validation générés par la fusion.

image

Lecture étendue

  • http://nvie.com/posts/a-successful-git-branching-model/

  • https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message

  • http://chris.beams.io/posts/git-commit/

Ingénierie frontale

Par rapport à toute l'équipe technique, il y a de plus en plus de problèmes sérieux dans l'équipe front-end ! Elle peut essentiellement se résumer comme suit :

  • Les référentiels Git sont un mélange de nombreuses entreprises différentes ;

  • La réutilisabilité du code source est faible ;

  • pas d'utilisation équitable des outils de construction ;

  • Le processus de publication des fichiers de ressources statiques est fastidieux ;

  • La façon dont les pages d'événements sont écrites est lourde et peu conviviale pour les moteurs de recherche.

En tant qu'ingénieur front-end, bien que je ne puisse rien faire pour toute l'équipe technique pour le moment, en tant que membre de l'équipe front-end, je peux faire ce que je peux dans l'équipe front-end. A mon avis, "problème" signifie "opportunité", et il est temps pour moi de montrer mes compétences ! Quand j'y pense, je sens beaucoup d'adrénaline sécrétée, et mon sang bout !

Donc qu'est ce que je devrais faire?

Les choses auxquelles je peux penser pour améliorer l'efficacité et la productivité des équipes front-end sont :

  1. Développer des spécifications et des conventions pour le codage et le stockage de fichiers ;

  2. Choisissez un langage efficace pour écrire le code source ;

  3. Choisissez le bon outil d'automatisation ;

  4. Veiller à la bonne mise en œuvre des mesures ci-dessus.

Afin d'améliorer la qualité globale et la force de l'équipe frontale, il reste encore beaucoup à faire. Si vous voulez terminer ces choses du jour au lendemain, la route vers l'optimisation de l'ingénierie frontale est un long chemin à parcourir...

Il y aura beaucoup de résistance à transformer des projets existants.Heureusement, l'expansion des affaires de l'entreprise a besoin de développer de nouveaux projets en ce moment. Décidé de commencer avec ce nouveau projet, d'essayer le couteau, de résumer un ensemble de plans et de mettre en œuvre des rectifications pour d'autres projets.

En prenant cet article comme référence, nous écrirons plusieurs articles sur notre team building front-end à l'avenir, alors restez à l'écoute !