Refactoring React Native : de 800 lignes a 100 lignes

Il y a un moment ou tu ouvres un fichier et tu sens physiquement le poids de la dette technique. Mon ecran principal faisait 800 lignes. Un seul fichier. Logique metier, rendu UI, gestion d'etat, appels API — tout melange dans un composant monolithique impossible a maintenir. Et ce n'etait pas un cas isole : j'avais 16 ecrans dans le meme etat.

Ce que je vais te raconter ici, c'est comment j'ai transforme un codebase chaotique en une architecture propre. Pas en une revolution spectaculaire, mais en un refactoring methodique, ecran par ecran, erreur par erreur.

Points cles a retenir :
- Un hook custom par ecran separe la logique metier du rendu UI
- Le pattern "orchestrateur + sous-composants" reduit les fichiers de 800 a 100 lignes
- ESLint avec regles strictes (zero any, promesses awaited) elimine des bugs silencieux
- La dette technique est un cout reel mesurable en temps, bugs et motivation
- Refactorer ecran par ecran permet de livrer en continu sans casser l'existant

Pourquoi un composant de 800 lignes est-il un probleme ?

La reponse evidente : c'est illisible. Mais le vrai probleme est plus insidieux. Un composant monolithique :

• Cache les bugs : quand tout est dans le meme fichier, les effets de bord sont imprevisibles. Modifier la logique de filtre peut casser l'animation de transition sans que tu comprennes pourquoi.
• Ralentit le developpement : chaque modification necessite de comprendre l'ensemble du fichier. Tu passes 20 minutes a "lire" avant de pouvoir ecrire 5 lignes.
• Rend le debug impossible : quand un bug survient, tu as 800 lignes de suspects. Pas de frontiere claire entre les responsabilites.
• Deteriore la motivation : ouvrir un fichier monstrueux chaque matin, ca pese. C'est le genre de friction invisible qui ralentit un projet indie.

"Tu es seul, qui va lire ce code ?" Moi. Moi dans trois mois quand j'aurai oublie pourquoi cet ecran fait ce qu'il fait. La dette technique n'est pas une metaphore. C'est un cout reel qui se paie en temps, en bugs, et en motivation.

Quelle strategie de decoupage adopter ?

J'ai refactore les 16 ecrans en suivant une structure consistante. Le pattern est simple mais puissant :

1. Un hook custom pour la logique metier

Chaque ecran a son hook : useTaskDetail, useFeedScreen, useGroupScreen... Le hook encapsule toute la logique : chargement des donnees, gestion d'etat, callbacks. Le composant ne fait que rendre du JSX.

Avant :

// TaskDetailScreen.tsx - 800 lignes
const TaskDetailScreen = () => {
  const [task, setTask] = useState(null);
  const [loading, setLoading] = useState(true);
  const [editing, setEditing] = useState(false);
  // ... 50 autres useState
  // ... 200 lignes de useEffect
  // ... 300 lignes de handlers
  // ... 250 lignes de JSX
}

Apres :

// TaskDetailScreen.tsx - 100 lignes
const TaskDetailScreen = () => {
  const { task, loading, editing, handlers } = useTaskDetail();
  return (
    <TaskDetailHeader task={task} onEdit={handlers.edit} />
    <TaskDetailBody task={task} />
    <TaskDetailActions handlers={handlers} />
  );
}

Le hook useTaskDetail fait 200 lignes. Les sous-composants font 50 a 100 lignes chacun. Au total, ca fait plus de lignes qu'avant — mais chaque fichier est comprehensible isolement.

2. Des sous-composants pour le rendu

Chaque section visuelle de l'ecran devient un composant dedie : TaskDetailHeader, TaskDetailBody, TaskDetailActions. Chacun recoit ses props et ne connait que sa responsabilite.

Ce pattern est directement inspire du Thinking in React officiel. Ce n'est pas nouveau, mais c'est incroyable a quel point on l'oublie quand on est presse de livrer.

3. Un composant principal pour l'orchestration

Le composant principal devient un chef d'orchestre de 100 lignes : il appelle le hook, distribue les props aux sous-composants, et gere le layout global. Rien d'autre.

Comment passer de 71 a 0 erreurs ESLint ?

En parallele du refactoring des ecrans, j'ai lance ESLint sur le backend avec des regles strictes. Resultat : 71 erreurs.

La tentation : desactiver les regles qui generent le plus d'erreurs. C'est ce que font 90% des developpeurs. J'ai fait l'inverse : j'ai corrige chaque erreur individuellement.

Les corrections les plus impactantes

Elimination des any : chaque any dans TypeScript est une bombe a retardement. Ca compile, ca passe les tests, mais ca crash en production quand une valeur inattendue arrive. J'ai remplace chaque any par un type explicite. Certains cas ont necessite de creer des interfaces dediees, mais le resultat est un code auto-documente.

Promesses correctement awaited : des appels asynchrones sans await qui echouaient silencieusement. Pas d'erreur, pas de warning — juste un comportement incorrect en production. ESLint a detecte 12 cas de promesses non-awaitees. 12 bugs potentiels elimines en une heure.

Variables inutilisees : des imports oublies, des variables declarees puis jamais utilisees. Pas des bugs, mais du bruit qui rend le code plus difficile a lire. Chaque ligne inutile est une distraction pour le "toi du futur" qui essaie de comprendre le code.

Faut-il refactorer tout d'un coup ou progressivement ?

Progressivement. Toujours progressivement. Un "big bang refactoring" ou tu reecris tout en une semaine, c'est la recette du desastre pour un dev solo. Tu casses tout, tu ne peux plus livrer, et si un bug critique arrive en production, tu ne peux pas le corriger rapidement.

Ma methode :

1. Choisir l'ecran le plus douloureux (celui que tu dreades d'ouvrir)
2. Extraire le hook custom en premier (la logique, pas le rendu)
3. Tester que tout fonctionne encore exactement comme avant
4. Extraire les sous-composants un par un
5. Livrer l'ecran refactore, passer au suivant

Chaque ecran refactore prenait entre 2 heures et une demi-journee. Les plus complexes (le Feed, l'ecran de groupe) ont pris une journee complete. Mais a chaque etape, l'app restait fonctionnelle et livrable.

Ce workflow est similaire a ce que Martin Fowler decrit dans son livre sur le refactoring : des transformations petites, incrementales, et toujours reversibles.

Quels gains concrets apres le refactoring ?

Apres deux semaines de travail :

• 16 ecrans refactores : chacun suit le meme pattern (hook + sous-composants + orchestrateur)
• 0 erreur ESLint sur le backend (contre 71 avant)
• Temps de comprehension divise par 3 : ouvrir un ecran et comprendre ce qu'il fait prend 2 minutes au lieu de 10
• Bugs reduits : les 3 semaines suivantes ont ete les plus stables du projet
• Motivation retrouvee : ouvrir un fichier propre le matin, ca change tout

Le gain le moins mesurable mais le plus important : la confiance. Apres le refactoring, je n'avais plus peur de modifier un ecran. Je savais exactement ou chaque chose se trouvait, quelles etaient les dependances, et ce qu'un changement allait impacter.

Comment la dette technique affecte-t-elle un projet solo ?

La dette technique dans un projet solo a des effets specifiques qu'on ne retrouve pas en equipe :

Pas de filet de securite. En equipe, un collegue peut relire ton code, detecter une regression, ou corriger un bug quand tu es absent. Seul, si ton code est incomprehensible, c'est toi — et toi seul — qui paies le prix.

L'effet compose. Chaque shortcut que tu prends aujourd'hui se multiplie. Un any ici, un // TODO: fix later la, et en quelques mois, tu as un codebase ou chaque modification prend 3x plus de temps qu'elle ne devrait.

La spirale de demotivation. Code sale → bugs → frustration → patches rapides → code encore plus sale. J'ai vu cette spirale sur d'autres projets. Le refactoring l'a brisee nette.

C'est la meme logique que j'applique a la restructuration de la base de donnees et a l'audit de securite : investir du temps maintenant pour en gagner exponentiellement plus tard.

Quelles regles ESLint recommander pour un projet React Native ?

Voici les regles qui ont eu le plus d'impact sur la qualite du code TAMSIV :

• @typescript-eslint/no-explicit-any : interdit les any. Non negociable.
• @typescript-eslint/no-floating-promises : detecte les promesses non-awaitees. Critique pour eviter les bugs silencieux.
• @typescript-eslint/no-unused-vars : elimine le bruit du code mort.
• react-hooks/exhaustive-deps : verifie les dependances des hooks. Essentiel en React Native.
• no-console : force a utiliser un logger plutot que console.log en production.

Active-les toutes en mode "error", pas "warn". Un warning, ca s'ignore. Une erreur, ca se corrige.

Ce que j'ai appris de cette semaine de refactoring

Cette semaine a ete la meilleure du projet. Pas la plus excitante — aucune feature visible pour l'utilisateur. Mais la plus impactante pour la suite. Chaque feature que j'ai construite apres — le systeme de gamification, les groupes hierarchiques, l'agenda collaboratif — a beneficie de cette architecture propre.

Si tu es dev solo et que tu repousses un refactoring parce que "ca ne livre rien de visible", arrete. C'est l'investissement le plus rentable que tu puisses faire. Pas glamour, pas excitant, mais fondamentalement necessaire.

La meilleure semaine du projet. Et je le repete sans hesiter.

FAQ

Combien de temps prend un refactoring de 16 ecrans ?

Pour moi, environ deux semaines a temps plein. Chaque ecran prend entre 2 heures et une journee selon sa complexite. L'ecran le plus simple (un formulaire basique) : 2 heures. Le plus complexe (le Feed avec gamification) : une journee complete.

Le refactoring introduit-il de nouveaux bugs ?

C'est le risque principal. Pour le minimiser, je refactorais un ecran a la fois et testais manuellement chaque flow avant de passer au suivant. Aucune regression majeure n'est apparue pendant les deux semaines de refactoring.

Faut-il ecrire des tests avant de refactorer ?

Dans l'ideal, oui. En realite, sur un projet solo avec 16 ecrans a refactorer, ecrire des tests exhaustifs avant le refactoring doublerait le temps. J'ai opte pour des tests manuels rigoureux et des tests automatises apres le refactoring, sur l'architecture propre.

Le pattern hook + sous-composants fonctionne-t-il pour tous les ecrans ?

Oui, avec des variations. Certains ecrans simples n'ont pas besoin de sous-composants — le hook seul suffit. D'autres ecrans complexes ont plusieurs niveaux de sous-composants. Le principe reste le meme : separer logique et rendu.

ESLint ralentit-il le developpement au quotidien ?

Les premieres heures, oui — le temps de corriger les erreurs existantes. Ensuite, c'est l'inverse : ESLint accelere le developpement en detectant les erreurs avant meme de lancer l'app. C'est comme un copilote qui corrige ta trajectoire en temps reel.