Skip to content

module-05-outillage-devops-et-automatisation.md

Latest commit

 

History

History
808 lines (622 loc) · 23.6 KB

module-05-outillage-devops-et-automatisation.md

File metadata and controls

808 lines (622 loc) · 23.6 KB
Raw

🔝 Retour au Sommaire

Module 5 : Outillage DevOps et Automatisation

Formation : Maîtriser C sur Ubuntu - De la Syntaxe au Système Niveau : Avancé ⭐ • Durée estimée : 35-45 heures de lecture et expérimentation intensive

🎯 Objectifs du module

Bienvenue au premier module de niveau Avancé. Vous avez acquis les fondamentaux du C (Modules 1-4). Maintenant, il est temps de professionnaliser votre workflow et d'adopter les outils qui font la différence entre un développeur et un ingénieur DevOps C moderne.

Ce module transforme votre façon de travailler en introduisant l'automatisation, la qualité continue, et les pratiques DevOps dans le développement C.

À l'issue de ce module, vous maîtriserez :

  1. ✅ CMake : Le build system moderne standard (priorité absolue) 🔥
  2. ✅ GNU Make : Comprendre les Makefiles (legacy mais encore utilisé)
  3. ✅ Bibliothèques statiques et dynamiques : Créer et distribuer du code réutilisable
  4. ✅ Sanitizers : Détecter les bugs dès le développement (ASan, UBSan, TSan, LSan)
  5. ✅ GDB : Déboguer efficacement avec le debugger GNU
  6. ✅ Valgrind : Analyser la mémoire et les performances
  7. ✅ Analyse statique : cppcheck, clang-tidy
  8. ✅ Code coverage : Mesurer la couverture de tests

🚀 Pourquoi ce module est critique en 2025

Le développement C a évolué

Année 2000 : Développeur C typique

$ vim programme.c
$ gcc programme.c -o programme
$ ./programme
# Ça marche ? Super. Commit.

Année 2025 : Ingénieur C moderne

$ cmake -B build -DCMAKE_BUILD_TYPE=Debug
$ cmake --build build
$ ctest --test-dir build
$ ./build/programme
# Sanitizers activés automatiquement
# Tests passent
# Coverage > 80%
# Pas de warnings
# Valgrind clean
# Commit avec CI/CD

Le gap entre juniors et seniors

Ce qui différencie un développeur junior d'un senior :

  • ❌ Junior : Code qui fonctionne sur sa machine
  • ✅ Senior : Code qui fonctionne partout, testé, sans bugs mémoire, maintenable

Ce module vous donne les outils pour devenir senior.

L'impact business

Les bugs de production coûtent cher :

  • 💰 1 bug en production = 100x le coût de détection en développement
  • 🔥 Buffer overflow = Vulnérabilité de sécurité = Réputation détruite
  • ⏱️ Fuites mémoire = Serveurs qui crashent = Clients perdus

Les outils de ce module détectent 90% des bugs avant la production.

🧩 Place dans la formation globale

D'où venez-vous ?

Modules 1-4 vous ont appris à :

  • Écrire du code C fonctionnel
  • Gérer la mémoire manuellement
  • Créer des structures de données
  • Organiser du code en modules

Mais vous manquez de :

  • Automatisation du build
  • Détection précoce des bugs
  • Outils de qualité
  • Pratiques DevOps

Le changement de paradigme

Modules 1-4 : "Comment coder en C ?"
              ↓
         [Changement de niveau]
              ↓
Module 5    : "Comment coder en C PROFESSIONNELLEMENT ?"  
Module 6-8  : Applications avancées

Ce module est la clé du professionnalisme

Sans ces outils, vous êtes :

  • ❌ Lent (builds manuels, debugging sans outils)
  • ❌ Dangereux (bugs cachés en production)
  • ❌ Seul (impossible de collaborer efficacement)
  • ❌ Limité (pas d'automatisation)

Avec ces outils :

  • ✅ Rapide (builds automatisés, feedback immédiat)
  • ✅ Sûr (bugs détectés avant commit)
  • ✅ Collaboratif (environnements reproductibles)
  • ✅ Scalable (CI/CD prêt)

📚 Structure du module

Ce module est organisé en trois chapitres essentiels qui couvrent l'ensemble de la chaîne d'outillage moderne :

🏗️ Chapitre 13 : Build Systems - De Make à CMake ⭐🔥

Contenu : 4 sections principales • Niveau : Avancé • Durée : 15-18 heures

Section 13.1 : CMake - Le standard moderne (PRIORITÉ ABSOLUE)

  • Pourquoi CMake est incontournable en 2025
  • Installation et premiers pas
  • Structure d'un CMakeLists.txt
  • Targets, properties, generators
  • Gestion des dépendances (find_package, FetchContent)
  • Build types (Debug, Release, RelWithDebInfo)
  • Out-of-source builds (build/ séparé du code source)
  • Intégration VS Code, CLion

Section 13.2 : GNU Make - Fondamentaux (pour comprendre le legacy)

  • Syntaxe des Makefiles
  • Règles, cibles, dépendances
  • Variables et macros
  • Pattern rules et automatic variables

Section 13.3 : Comparaison Make vs CMake

Section 13.4 : Autres build systems (Meson, Bazel, Ninja)

Concepts clés - CMake :

# CMakeLists.txt moderne
cmake_minimum_required(VERSION 3.15)  
project(MyProject VERSION 1.0.0 LANGUAGES C)

# Standard C11
set(CMAKE_C_STANDARD 11)  
set(CMAKE_C_STANDARD_REQUIRED ON)

# Warnings et sanitizers
add_compile_options(-Wall -Wextra -Werror)  
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
    add_compile_options(-fsanitize=address -fsanitize=undefined)
    add_link_options(-fsanitize=address -fsanitize=undefined)
endif()

# Bibliothèque
add_library(mylib STATIC src/mylib.c)  
target_include_directories(mylib PUBLIC include)

# Exécutable
add_executable(myapp src/main.c)  
target_link_libraries(myapp PRIVATE mylib)

# Tests
enable_testing()  
add_test(NAME test_mylib COMMAND myapp)

Workflow CMake :

# Configuration (une fois)
cmake -B build -DCMAKE_BUILD_TYPE=Debug

# Build (à chaque modification)
cmake --build build

# Run tests
ctest --test-dir build --output-on-failure

# Install (optionnel)
cmake --install build --prefix /usr/local

Pourquoi c'est crucial :

  • 🌍 Cross-platform : Linux, Windows, macOS avec le même CMakeLists.txt
  • 🔧 Intégration IDE : Support natif VS Code, CLion, Visual Studio
  • 📦 Gestion de dépendances : find_package pour bibliothèques système
  • 🚀 Build moderne : Out-of-source, caching, parallélisation
  • 📊 CI/CD ready : GitHub Actions, GitLab CI l'utilisent nativement

CMake vs Make :

Critère Make CMake
Portabilité ❌ Linux/Unix seulement ✅ Cross-platform
Complexité Simple pour petits projets Verbeux mais scalable
IDE Support ❌ Limité ✅ Excellent
Dépendances Manuel find_package
Standard moderne ❌ Legacy ✅ Standard industrie

📚 Chapitre 14 : Les Bibliothèques

Contenu : 7 sections • Niveau : Avancé • Durée : 10-12 heures

Vous maîtriserez :

  • Bibliothèques statiques (.a) : Compilation avec ar et ranlib
  • Bibliothèques dynamiques (.so) : Compilation avec -fPIC
  • Versioning et SONAME (libmylib.so.1.2.3)
  • Résolution de symboles au runtime (dlopen, dlsym)
  • Différences statiques vs dynamiques (taille, flexibilité, portabilité)
  • Gestion du LD_LIBRARY_PATH
  • Outils : ldd, ldconfig
  • Création d'une API propre avec symbol visibility

Concepts clés :

# Bibliothèque statique
gcc -c mylib.c -o mylib.o  
ar rcs libmylib.a mylib.o  
ranlib libmylib.a

# Utilisation
gcc main.c -L. -lmylib -o main

# Bibliothèque dynamique (shared object)
gcc -fPIC -c mylib.c -o mylib.o  
gcc -shared -Wl,-soname,libmylib.so.1 -o libmylib.so.1.0.0 mylib.o  
ln -s libmylib.so.1.0.0 libmylib.so.1  
ln -s libmylib.so.1 libmylib.so

# Utilisation
gcc main.c -L. -lmylib -o main  
LD_LIBRARY_PATH=. ./main

# Voir les dépendances
ldd main

Bibliothèque statique vs dynamique :

STATIQUE (.a)                     DYNAMIQUE (.so)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Pas de dépendances runtime     ✅ Mises à jour sans recompiler
✅ Déploiement simple             ✅ Taille binaire réduite
✅ Performance légèrement         ✅ Partage mémoire entre processus
   meilleure                      ✅ Plugins et chargement dynamique
❌ Taille binaire augmente        ❌ Dépendances complexes
❌ Doit recompiler pour MAJ       ❌ LD_LIBRARY_PATH à gérer
❌ Pas de mise à jour sans        ❌ "Dependency hell"
   recompilation

Symbol visibility :

// mylib.h
#ifdef _WIN32
  #define EXPORT __declspec(dllexport)
#else
  #define EXPORT __attribute__((visibility("default")))
#endif

EXPORT int public_function(void);

// Fonction interne non exportée
static int internal_function(void) { return 0; }

Pourquoi c'est crucial :

  • 📦 Réutilisabilité : Partager du code entre projets
  • 🔒 Encapsulation : API publique vs implémentation privée
  • 🔄 Maintenance : Mettre à jour sans recompiler tout
  • 🌐 Distribution : Créer des bibliothèques pour la communauté

🐛 Chapitre 15 : Débogage et Analyse de Qualité ⭐🔥

Contenu : 7 sections majeures • Niveau : Avancé-Expert • Durée : 15-20 heures

Section 15.1 : Sanitizers - Première ligne de défense 🔥

  • AddressSanitizer (ASan) : Buffer overflow, use-after-free, double free
  • UndefinedBehaviorSanitizer (UBSan) : Overflow d'entiers, null pointer dereference
  • ThreadSanitizer (TSan) : Race conditions, deadlocks
  • LeakSanitizer (LSan) : Fuites mémoire
  • Compilation avec sanitizers
  • Performance et overhead
  • Intégration dans le workflow quotidien

Section 15.2-15.3 : GDB (basique et avancé)

  • Breakpoints, watchpoints, catchpoints
  • Stepping (step, next, continue)
  • Backtrace et analyse de la pile
  • Inspection des variables
  • GDB TUI mode
  • Core dumps
  • Debugging distant (gdbserver)
  • Scripts GDB
  • rr (Time Travel Debugging)

Section 15.4-15.5 : Valgrind

  • Memcheck : Détection d'erreurs mémoire
  • Interprétation des rapports
  • Suppression files pour les faux positifs
  • Helgrind : Détection de race conditions
  • Cachegrind : Analyse du cache
  • Callgrind : Profiling d'exécution
  • Massif : Profiling mémoire

Section 15.6 : Analyse statique

  • cppcheck : Détection de bugs logiques
  • clang-tidy : Modernisation et best practices
  • Configuration et intégration CI/CD

Section 15.7 : Code coverage

  • gcov : Mesure de couverture
  • lcov : Génération de rapports HTML
  • Intégration dans le CI

Concepts clés - Sanitizers :

# Compiler avec ASan + UBSan
gcc -fsanitize=address,undefined -fno-omit-frame-pointer -g \
    programme.c -o programme

# Exécuter
./programme

# Sortie si bug détecté :
=================================================================
==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x...
    #0 0x... in main programme.c:42
    #1 0x... in __libc_start_main

SUMMARY: AddressSanitizer: heap-buffer-overflow programme.c:42 in main

Workflow complet de qualité :

# 1. Compiler avec sanitizers
cmake -B build -DCMAKE_BUILD_TYPE=Debug \
      -DENABLE_ASAN=ON -DENABLE_UBSAN=ON

# 2. Build et test
cmake --build build  
ctest --test-dir build

# 3. Analyse Valgrind
valgrind --leak-check=full --show-leak-kinds=all ./build/programme

# 4. Analyse statique
cppcheck --enable=all src/  
clang-tidy src/*.c -- -Iinclude

# 5. Code coverage
cmake -B build -DCMAKE_BUILD_TYPE=Coverage  
cmake --build build
./build/programme
lcov --capture --directory . --output-file coverage.info  
genhtml coverage.info --output-directory coverage_html

Pourquoi c'est crucial :

  • 🐞 90% des bugs détectés avant production
  • ⚡ Feedback immédiat (sanitizers pendant le dev)
  • 🔍 Zéro fuite mémoire (Valgrind)
  • 📊 Qualité mesurable (coverage)
  • 🚀 Confiance pour refactoriser

Les sanitizers changent la donne :

AVANT sanitizers :               AVEC sanitizers :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Écrire code                   1. Écrire code
2. Compiler                      2. Compiler avec -fsanitize=...
3. Tester manuellement          3. Tester → Bug détecté immédiatement
4. ???                           4. Corriger
5. Bug en production 💥          5. Commit code propre ✅
6. Debugging difficile
7. Corriger
8. Redéployer

🎓 Prérequis

Absolument nécessaire

  • ✅ Modules 1-4 complétés : Solides fondamentaux en C
  • ✅ Maîtrise de la ligne de commande : Bash, redirections, pipes
  • ✅ Compréhension de la compilation : Preprocessing, compilation, linking
  • ✅ Gestion mémoire maîtrisée : malloc/free sans fuites

Fortement recommandé

  • ✅ Git : Commits, branches, .gitignore
  • ✅ Expérience de projets multi-fichiers
  • ✅ Lecture de documentation technique

Nice to have

  • ☑️ Notions de CI/CD (on va les apprendre)
  • ☑️ Connaissance de Python/Bash scripting
  • ☑️ Expérience avec Docker

🗺️ Stratégie d'apprentissage pour ce module

Ce module est différent

Ce n'est plus "apprendre à coder", c'est "apprendre à être un professionnel".

Les outils de ce module sont cumulatifs : vous les utilisez tous ensemble, pas l'un après l'autre.

Workflow journalier recommandé

À partir de maintenant, CHAQUE projet C devrait :

# 1. Structure CMake
cat > CMakeLists.txt << 'EOF'  
cmake_minimum_required(VERSION 3.15)  
project(MyProject C)  
set(CMAKE_C_STANDARD 11)

# Sanitizers en Debug
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
    add_compile_options(-fsanitize=address,undefined)
    add_link_options(-fsanitize=address,undefined)
endif()

add_executable(myapp src/main.c)  
EOF

# 2. Build
cmake -B build -DCMAKE_BUILD_TYPE=Debug  
cmake --build build

# 3. Test avec sanitizers (automatique)
./build/myapp

# 4. Vérification Valgrind
valgrind --leak-check=full ./build/myapp

# 5. Analyse statique
cppcheck src/

# 6. Commit uniquement si tout est vert
git commit -m "Feature: ..."

Ne passez JAMAIS au prochain projet sans

  • ✅ CMake configuré
  • ✅ Compilation sans warnings (-Wall -Wextra -Werror)
  • ✅ Sanitizers activés en Debug
  • ✅ Valgrind clean (no leaks, no errors)
  • ✅ Tests qui passent

C'est non négociable. Zéro exception.

🛠️ Installation et configuration initiale

Installer tous les outils d'un coup

# Sur Ubuntu 22.04/24.04
sudo apt update  
sudo apt install -y \
    build-essential \
    cmake \
    ninja-build \
    gdb \
    valgrind \
    cppcheck \
    clang-tidy \
    lcov \
    clang-format

# Vérifier les installations
cmake --version      # >= 3.15  
gdb --version        # >= 8.0  
valgrind --version   # >= 3.15  
cppcheck --version   # >= 2.0

Configuration VS Code (si utilisé)

// .vscode/settings.json
{
    "cmake.configureOnOpen": true,
    "cmake.buildDirectory": "${workspaceFolder}/build",
    "C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools",
    "C_Cpp.cppcheck.enable": true,
    "files.associations": {
        "*.h": "c"
    }
}

Template de projet moderne

# Créer un template réutilisable
mkdir ~/c-project-template  
cd ~/c-project-template

# Structure
mkdir -p {src,include,tests,build}

# CMakeLists.txt minimal
cat > CMakeLists.txt << 'EOF'  
cmake_minimum_required(VERSION 3.15)  
project(ProjectName VERSION 1.0.0 LANGUAGES C)

set(CMAKE_C_STANDARD 11)  
set(CMAKE_C_STANDARD_REQUIRED ON)  
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

# Warnings
add_compile_options(-Wall -Wextra -Werror -pedantic)

# Sanitizers en Debug
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
    add_compile_options(-fsanitize=address,undefined -fno-omit-frame-pointer)
    add_link_options(-fsanitize=address,undefined)
endif()

# Code coverage
if(CMAKE_BUILD_TYPE STREQUAL "Coverage")
    add_compile_options(--coverage -O0)
    add_link_options(--coverage)
endif()

add_subdirectory(src)  
enable_testing()  
add_subdirectory(tests)  
EOF

# .gitignore
cat > .gitignore << 'EOF'  
build/
*.o
*.a
*.so
*.out
EOF

# Utiliser le template
cp -r ~/c-project-template ~/mon-nouveau-projet  
cd ~/mon-nouveau-projet
# Personnaliser CMakeLists.txt, puis build

⚠️ Pièges et erreurs à éviter

🚨 Erreur 1 : Ignorer les warnings du compilateur

# ❌ JAMAIS faire ça
gcc programme.c  # Warnings ignorés

# ✅ TOUJOURS compiler avec
gcc -Wall -Wextra -Werror programme.c
# Ou dans CMake : add_compile_options(-Wall -Wextra -Werror)

🚨 Erreur 2 : Ne pas activer les sanitizers en développement

# ❌ Oublier les sanitizers
add_executable(myapp main.c)

# ✅ Toujours en Debug
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
    add_compile_options(-fsanitize=address,undefined)
    add_link_options(-fsanitize=address,undefined)
endif()

🚨 Erreur 3 : Confondre build type Debug et Release

# ❌ Release en développement (pas de symboles de debug)
cmake -B build -DCMAKE_BUILD_TYPE=Release

# ✅ Debug en développement
cmake -B build -DCMAKE_BUILD_TYPE=Debug

# Release uniquement pour la production
cmake -B build -DCMAKE_BUILD_TYPE=Release

🚨 Erreur 4 : In-source builds avec CMake

# ❌ Pollution du code source
cmake .  
make

# ✅ Out-of-source build
cmake -B build  
cmake --build build
# Facile à nettoyer : rm -rf build/

🚨 Erreur 5 : Ne pas vérifier avec Valgrind

# ❌ "Ça marche sur ma machine"
./programme

# ✅ Toujours vérifier
valgrind --leak-check=full ./programme
# Avant chaque commit important

🚨 Erreur 6 : Ignorer les rapports de Valgrind/Sanitizers

"Oh, un warning Valgrind... ça doit être un faux positif"
                    ↓
         [6 mois plus tard]
                    ↓
         Crash en production 💥

Règle d'or : Zéro warning, zéro erreur, zéro fuite. Pas de compromis.

🏆 Critères de maîtrise

✅ Niveau 1 : Build systems

  • Créer un CMakeLists.txt pour un projet multi-fichiers
  • Configurer différents build types (Debug, Release)
  • Gérer les dépendances avec find_package
  • Intégrer CMake dans l'IDE
  • Comprendre et lire des Makefiles existants

✅ Niveau 2 : Bibliothèques

  • Créer une bibliothèque statique (.a)
  • Créer une bibliothèque dynamique (.so)
  • Gérer le versioning (SONAME)
  • Utiliser ldd et ldconfig
  • Contrôler la visibilité des symboles

✅ Niveau 3 : Debugging et qualité

  • Compiler systématiquement avec sanitizers en Debug
  • Interpréter les messages d'ASan et UBSan
  • Utiliser GDB pour déboguer un segfault
  • Analyser un programme avec Valgrind sans erreurs
  • Exécuter cppcheck et corriger les problèmes

✅ Niveau 4 : Workflow professionnel

  • Setup automatisé : CMake + sanitizers + tests
  • Zéro warning lors de la compilation
  • Valgrind clean avant chaque commit
  • Couverture de code > 70%
  • Utiliser l'analyse statique dans le CI

📊 Indicateurs de succès

Vous savez que vous maîtrisez ce module quand :

Semaine 1-2 (Build systems)

  • ✅ Tout nouveau projet commence par un CMakeLists.txt
  • ✅ Vous ne tapez plus gcc directement
  • ✅ Vos builds sont reproductibles
  • ✅ L'IDE comprend votre projet automatiquement

Semaine 3-4 (Bibliothèques)

  • ✅ Vous créez des .so réutilisables
  • ✅ Vous comprenez les erreurs de linking
  • ✅ ldd n'a plus de secrets
  • ✅ Vous gérez proprement LD_LIBRARY_PATH

Semaine 5-6 (Debugging)

  • ✅ ASan activé par défaut en développement
  • ✅ Vous déboguez en 5 minutes ce qui prenait 2 heures
  • ✅ Valgrind ne trouve aucun problème dans votre code
  • ✅ Vous profilez avant d'optimiser

📚 Ressources complémentaires critiques

Documentation officielle

Livres essentiels

  • Professional CMake (Craig Scott) - LA référence CMake
  • The Art of Debugging with GDB, DDD, and Eclipse (Matloff & Salzman)
  • Valgrind 3.3 - Advanced Debugging and Profiling (Seward)

Tutoriels et guides

Outils en ligne

💡 Conseils pour réussir ce module

1. Installez TOUT dès maintenant

Ne perdez pas de temps à installer au fur et à mesure. Une session d'installation complète, une fois.

2. Créez votre template de projet

Un template CMake bien configuré vous fait gagner 30 minutes à chaque nouveau projet.

3. Intégrez dans votre muscle memory

# Ces commandes doivent devenir automatiques
cmake -B build  
cmake --build build  
valgrind --leak-check=full ./build/programme

4. Zero tolerance pour les warnings

Traitez chaque warning comme une erreur. -Werror doit être votre ami.

5. Sanitizers = sauveur de temps

ASan trouve en 1 seconde ce que vous chercheriez pendant 1 heure.

6. Lisez les rapports d'outils

Valgrind et les sanitizers sont verbeux pour une raison. Lisez TOUT.

🗓️ Planning de lecture suggéré

Approche intensive (temps plein)

Semaine Contenu Focus
Semaine 1 Chapitre 13 : CMake Configuration, build types, intégration
Semaine 2 Chapitre 13 : Make + comparaison Legacy et alternatives
Semaine 3 Chapitre 14 : Bibliothèques Statiques, dynamiques, linking
Semaine 4 Chapitre 15 : Sanitizers + GDB Détection de bugs
Semaine 5 Chapitre 15 : Valgrind + analyse statique Profiling et qualité
Semaine 6 Pratique et consolidation Projets complets

Approche à temps partiel (10-15h/semaine)

Semaine Contenu
Semaines 1-3 Chapitre 13 complet (CMake prioritaire)
Semaines 4-5 Chapitre 14 complet
Semaines 6-9 Chapitre 15 complet
Semaine 10 Révision et workflow intégré

📑 Prochaines sections

Transformez votre workflow de développement :

🎯 Mot de conclusion

Ce module est un game changer. Avant et après sont deux mondes différents.

Avant ce module : Vous codez en C
Après ce module : Vous êtes un ingénieur C professionnel

Les outils de ce module sont utilisés par Google, Facebook, Netflix, Linux kernel, Redis, PostgreSQL et tous les projets C sérieux.

Ne sous-estimez pas l'impact de ces outils. Ils font la différence entre :

  • Code qui fonctionne ↔ Code qui fonctionne en production
  • Développement lent ↔ Développement véloce
  • Bugs en production ↔ Bugs détectés en dev
  • Junior ↔ Senior

Investissez le temps nécessaire. Vous ne le regretterez jamais. 🚀

📝 Note finale sur l'utilisation

Cette formation est un guide de référence complet. Pour ce module crucial :

  • Installez tous les outils avant de commencer
  • Testez chaque outil sur des exemples simples
  • Intégrez progressivement dans vos projets
  • Adoptez le workflow complet (CMake + sanitizers + Valgrind)
  • Automatisez tout ce qui peut l'être

À partir de maintenant, il n'y a plus d'excuse pour du code de mauvaise qualité.

Les Modules 6-8 utiliseront ces outils intensivement. Vous devez les maîtriser maintenant.

⏭️ Chapitre 13 : Build Systems - De Make à CMake →