📄️ Le code
Éternel débat sur les commentaires de code, ni trop, ni pas assez. Normalement le nom de fonction suffit à comprendre ce que ça fait, mais pour comprendre certains passages à l'intérieur il peut être bon de clarifier ce que ça fait, ou pourquoi vous l'avez fait (est-ce un workaround ? …).
📄️ La macro-technique
Il est déconseillé de documenter votre projet technique en dehors de votre repository Git. Le simple fait de mettre une distance entre votre code et sa propre documentation fait qu'avec le temps ils seront désynchronisés. Utilisez plutôt des fichiers Markdown qui permettent un formatage assez poussé, tout en bénéficiant du versioning de Git.
📄️ Le schéma de base de données
Nous privilégions l'utilisation d'un ORM pour représenter notre schéma de base de données, comme cela tout comme le code, le schéma est versionné.
📄️ Nommage des commits
Avoir le versioning Git est utile, mais c'est encore mieux si les commits ont une description explicite. Évitez les simples aaa ou fix, essayez d'être plus verbeux en restant succinct comme fix: header was not responsive. Cela vous sauvera quand vous utiliserez la fonction "recherche" dans votre historique de commits, ou bien quand vous ferez un git blame afin de savoir qui a fait la modification et pourquoi (cela sert de documentation dans un sens).