# Code as An Asset

Catégories de remarques de review:
- expressivité du code
- code incorrect:
- cas null pas testés (devrait l'être systématiquement)
- tout ce qui rentre devrait avoir des pré-conditions / post-conditions
- orthographe
- norme / normalisation
- respect best-practice
- feed-back non explicite
- normalisation de la review

Concept de single responsability pour une classe
La documentation est très importante dès qu'il y a une responsabilité.

Il y a deux types de nommage:
- par fonction (ce qu'il fait)
- par nature (string, int ...)

Une bonne coding style devrait indiquer la politique de nommage.
Recommandation: nommage par nature, l'autre est trop subjectif.

Objectif d'une entreprise d'une code review:
- améliorer la qualité du code
- qualifier ses équipes
- formation continue
- discussion autour des normes collectives

ADR: Architecture Decision Record: log les choix d'architecture. Bonne pratique.

Pourquoi les codes base auraient de la valeur pour les ressources humaines ?
- pour les recrutements : profilage, intérêts et technologies social-dev profiling, éthique de travail
- faire un suivi sur les formations nécessaires
- métrique productivité des employés, éthique de travail des employés, profilage des employés
- qualité de vie, détecter les baisses de motivation, esprit d'équipe

**Recrutement:** Profilage, intérêts et technologies social-dev profiling :
- Ce que la personne aime permet de qualifier la rigueur et les compétences du candidat
- Regarder si la personne participe à des projets de groupes ou des projets open source (forte culture dev, sens de communauté)
- Regarder si la personne fait des hackathon, de quel type ?
- Quels langages sont maîtrisés ou au moins utilisés ?
- Voir si les projets s’inscrivent dans un domaine particulier -> rapport avec le secteur de l’entreprise ?
- Éthique de travail des employes, suivent-ils les regles ?
- Proprete du code
- Documentation du code
- Git log propre
- Analyser la codebase de l'entreprise pour en tirer un profil type
- Entretiens techniques, clareté de l'explication du code

**Qualité de vie:** Détecter les baisses de motivation,Esprit d'équipe :
- Partage de code, et coder en groupe. Rendre l'écriture de code un projet commun
- Analyser la codebase pour vérifier la motivation (horaire des commits, respect des deadlines, qualité)
- Code Showdown: Réunion visant à montrer du code, pour que les employés puissent montrer le code dont ils sont fier, pour augmenter la cohésion et l'esprit de groupe
- Inspection des messages durant les PR, analyse avec des algorithmes

**Profilage/suivi employés :**
- Noter les commits de correction de bugs
- Analyser l'activité de l'employé au niveau de la régularité
- Analyser la clareté de code/fichiers
- Il ne faut pas sur-flické les employés (fausser les résultats)
- Bien mettre en évidence les critères évalués de la code base