
L'inversion de dépendances et l'injection de dépendances sont des concepts fondamentaux en développement logiciel qui permettent d'améliorer la modularité, la maintenabilité et la testabilité des applications. Bien que souvent associés aux projets back-end, ces principes ont également une grande importance dans le contexte des projets front-end.

Dans cet article, nous allons découvrir ce que sont l'inversion et l'injection de dépendances et comment les appliquer efficacement dans vos projets front-end avec des exemples en utilisant TypeScript, React.js et Next.js.

Si vous souhaitez approfondir davantage ces concepts, vous pouvez lire l'article que j’ai écrit au sujet de l’architecture hexagonale en front-end (ou clean architecture) en cliquant sur ce lien : [voir l'article sur l'architecture hexagonale en front-end](/blog/hexagonal-architecture-front-end).

## Comprendre l'inversion de dépendances

L'inversion de dépendances est un principe clé du développement logiciel qui consiste à inverser le flux de contrôle au sein d'une application. Au lieu d'une structure où les modules de bas niveau dépendent des modules de haut niveau, l'inversion de dépendances préconise que les modules de bas niveau soient indépendants et que les dépendances soient fournies de l'extérieur.

Dans le contexte front-end, cela signifie que les composants ne devraient pas dépendre directement de services externes, mais plutôt de dépendre des interfaces (ou types) que nous définissons selon nos besoins. Cela améliore la flexibilité de l'application et facilite les tests en permettant de substituer facilement des dépendances réelles par des dépendances simulées lors des tests.

## Les avantages de l'inversion de dépendances
1. **Modularité accrue :** Les modules deviennent plus indépendants et peuvent être réutilisés dans différents contextes.
2. **Facilité de test :** Le code métier ne dépend plus des dépendances externes, nous pouvons simuler rapidement et facilement ces dépendances.
3. **Facilité de maintenance :** Les changements dans une dépendance sont limités à un seul endroit, ce qui réduit les risques d'effets domino.
4. **Couplage réduit :** Les dépendances ne sont pas directement intégrées dans le code, ce qui réduit le couplage entre les différentes parties de l'application.

## Appliquer l'inversion de dépendances avec TypeScript, React.js et Next.js
Maintenant que nous avons vu la partie théorique de l'inversion et de l'injection de dépendances en front-end, nous allons voir comment l'appliquer dans un projet front-end en utilisant TypeScript, React.js et Next.js.

TypeScript offre un fort typage qui peut être utilisé pour définir des interfaces claires et précises pour les dépendances. Vous pouvez utiliser des interfaces ou des types. Définir des interfaces pour les dépendances facilite la substitution de dépendances réelles par des dépendances simulées lors des tests.

Pour le projet d'exemple, nous allons développer une fonctionnalité qui permet de se connecter.

### Exemple sans inversion de dépendances
Afin de comprendre pourquoi l'inversion de dépendances est importante en front-end, voici un exemple de code que vous pouvez retrouver dans la plupart des projets :
```tsx
import { AuthService } from "../auth.service.ts"

const LoginPage: React.FC<{ authService: AuthService }> = ({ authService }) => {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')

  const handleLogin = () => {
	  fetch("https://api.com/login", {
		  method: "POST",
		  headers: {
			  "Content-Type": "application/json",
		  },
		  body: JSON.stringify({ email, password }),
	  })
      .then(response => {
          if (!response.ok) {
              throw new Error("Login failed");
          }
          const user = response.json()
          console.log('Login successful! User:', user)
      })
      .catch(error => {
          console.error("Login error:", error);
          throw error
      })
  }

  return (
    <div>
      <h2>Login Page</h2>
      <input type="email" placeholder="Email" value={email} onChange={e => setEmail(e.target.value)} />
      <input type="password" placeholder="Password" value={password} onChange={e => setPassword(e.target.value)} />
      <button onClick={handleLogin}>Login</button>
    </div>
  )
}

export default LoginPage
```

Dans cet exemple, la requête HTTP à l'API qui permet à l'utilisateur de se connecter se trouve directement dans un composant React. Le problème avec cette pratique, est que nous ne pouvons pas facilement tester ce composant. En effet, nous ne pouvons pas simuler la requête HTTP pour tester le comportement du composant dans différents cas de figure (par exemple, si la requête échoue).

De même, notre composant React, c'est-à-dire notre interface utilisateur, est directement liée à la requête API. Si nous souhaitons changer l'API pour se connecter, nous devons modifier notre composant React. Cela peut être problématique si nous avons plusieurs composants qui dépendent de cette API.

Il y a également un autre problème, si nous souhaitons ajouter une nouvelle fonctionnalité qui nécessite une connexion, nous devons réécrire le code de connexion dans chaque composant. Cela peut rapidement devenir problématique si nous avons plusieurs composants qui nécessitent une connexion.

Enfin, notre interface utilisateur (les composants React) contient de la logique métier, ce qui n'est pas une bonne pratique. En effet, notre composant React doit uniquement se concentrer sur l'interface utilisateur et ne doit pas contenir de la logique métier. Cela rend notre composant plus difficile à maintenir et à tester.

### Exemple avec inversion de dépendances
Pour éviter tous ces problèmes, nous pouvons mettre en place l'inversion de dépendances. Pour commencer, nous allons créer une interface pour le service d'authentification :
```typescript
export type AuthService = {
  login(email: string, password: string): Promise<User>
  logout(): Promise<void>
}
```

Ensuite, nous pouvons implémenter cette interface pour réaliser notre appel API :
```typescript
import { AuthService } from "../auth.service.ts"

export const AuthApi: AuthService = {
  login: (email, password) => {
    return fetch("https://api.com/login", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email, password }),
    })
    .then(response => {
      if (!response.ok) {
        throw new Error("Login failed");
      }
      return response.json()
    })
    .catch(error => {
      console.error("Login error:", error);
      throw error
    })
  },
  logout: () => {
    return fetch("https://api.com/logout", {
      method: "POST",
    })
    .then(response => {
      if (!response.ok) {
        throw new Error("Logout failed")
      }
    })
    .catch(error => {
      console.error("Logout error:", error)
      throw error
    })
  }
}
```

Ainsi, pour réaliser l'appel API, il suffit d’utiliser l’interface dans votre code. Cela évite à vos composants de dépendre des librairies ou des services externes. Voici un exemple de composant React qui utilise l’interface définie plus haut pour l’inversion de dépendances :
```tsx
import { AuthService } from "../auth.service.ts"

const LoginPage: React.FC<{ authService: AuthService }> = ({ authService }) => {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')

  const handleLogin = async () => {
    try {
      const user = await authService.login(email, password);
      console.log('Login successful! User:', user)
    } catch (error) {
      console.error('Login error:', error)
    }
  }

  return (
    <div>
      <h2>Login Page</h2>
      <input type="email" placeholder="Email" value={email} onChange={e => setEmail(e.target.value)} />
      <input type="password" placeholder="Password" value={password} onChange={e => setPassword(e.target.value)} />
      <button onClick={handleLogin}>Login</button>
    </div>
  )
}

export default LoginPage
```

Pour simplifier votre code, vous pouvez créer un type qui regroupe toutes les interfaces :
```typescript
import { AuthService } from "../auth.service.ts"

export type Dependencies = {
   authService: AuthService
}
```

Ensuite, en fonction du contexte de votre code (si vous êtes dans la partie client, dans la partie serveur ou dans les tests, etc.) vous pouvez créer un objet qui regroupe toutes les implémentations de vos interfaces :
```typescript
import { Dependencies } from "../dependencies.ts"
import { AuthApi } from "../auth.api.ts"

export const dependencies: Dependencies = {
   authService: AuthApi
}
```

Ainsi, il ne vous reste plus qu’à appeler vos dépendances grâce à cet objet dans le contexte que vous souhaitez. Dans le cadre d’un projet React en front-end, vous avez plusieurs solutions possibles :

### Appeler directement vos implémentations des dépendances dans votre code, par exemple dans un composant React
```tsx
import { dependencies } from "../dependencies.ts"

const LoginPage = () => {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')

  const handleLogin = async () => {
    try {
      const user = await dependencies.authService.login(email, password);
      console.log('Login successful! User:', user)
    } catch (error) {
      console.error('Login error:', error)
    }
  }

  return (
    <div>
      <h2>Login Page</h2>
      <input type="email" placeholder="Email" value={email} onChange={e => setEmail(e.target.value)} />
      <input type="password" placeholder="Password" value={password} onChange={e => setPassword(e.target.value)} />
      <button onClick={handleLogin}>Login</button>
    </div>
  )
}

export default LoginPage
```

### Créer un contexte et un provider pour permettre à tous les composants d’accéder aux dépendances
1. Création du contexte React
```tsx
// dependencies.context.ts
import React, { createContext, useContext } from 'react'
import { AuthService } from "../auth.service.ts"

// Créez le contexte des dépendances
const DependenciesContext = createContext<Dependencies | null>(null)

// Créez un hook pour utiliser les dépendances dans vos composants
export const useDependencies = () => {
  const context = useContext(DependencyContext)
  if (!context) {
    throw new Error('useDependencies must be used within a DependencyContextProvider');
  }
  return context
}

// Composant Provider pour envelopper votre application avec les dépendances
export const DependenciesContextProvider: React.FC<Dependencies> = ({ children, ...dependencies }) => {
  return <DependencyContext.Provider value={dependencies}>{children}</DependencyContext.Provider>
}
```

2. Implémentation du contexte dans l'application
```tsx
// _app.ts
import React from 'react'
import { DependenciesContextProvider } from '../dependencies.context.ts'
import { dependencies } from '../dependencies.ts'

const MyApp = ({ Component, pageProps }) => {
  return (
    <DependencyContextProvider {...dependencies}>
      <Component {...pageProps} />
    </DependencyContextProvider>
  )
}

export default MyApp
```

3. Utilisation du contexte dans vos composants pour accéder aux dépendances
```tsx
// pages/login.ts
import React, { useState } from 'react'
import { useDependencies } from '../DependenciesContext'

const LoginPage = () => {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')

  const { authService } = useDependencies()

  const handleLogin = async () => {
    try {
      const user = await authService.login(email, password)
      console.log('Login successful! User:', user)
    } catch (error) {
      console.error('Login error:', error)
    }
  };

  return (
    <div>
      <h2>Login Page</h2>
      <input type="email" placeholder="Email" value={email} onChange={e => setEmail(e.target.value)} />
      <input type="password" placeholder="Password" value={password} onChange={e => setPassword(e.target.value)} />
      <button onClick={handleLogin}>Login</button>
    </div>
  )
}

export default LoginPage
```

### Si vous utilisez redux dans votre projet React, vous pouvez utiliser les middlewares comme redux thunk pour injecter vos dépendances

Avec redux toolkit et redux thunk, il faut utiliser la fonction getDefaultMiddleware et utiliser la clé extraArgument de l'objet thunk pour passer les dépendances aux thunks :
```typescript
// store.ts
import { dependencies } from '../dependencies.ts'

const store = configureStore({
  reducer: rootReducer,
  middleware: getDefaultMiddleware =>
    getDefaultMiddleware({
      thunk: {
        extraArgument: dependencies
      }
    })
})
```

Ainsi, vous pouvez accéder aux dépendances injectées depuis vos thunks :
```typescript
// login.thunk.ts
export const login =
  (username, password) => async (dispatch, getState, { authService }) => {
    const response = await authService.login(username, password)
    dispatch(login(response))
  }
```

## Conclusion
L'inversion et l'injection de dépendances sont des pratiques qui apportent de nombreux avantages aux projets de développement. En appliquant ces principes à l'aide de TypeScript, React.js et Next.js dans les projets front-end, cela vous permet de créer des applications modulaires, facilement testables et évolutives.

En réduisant le couplage avec les librairies et les services externes, ces approches améliorent la qualité du code et facilitent la maintenance à long terme. Ces pratiques sont d’ailleurs au cœur de l’architecture hexagonale (clean architecture). Si vous souhaitez en savoir plus à ce sujet, je vous invite à consulter l’article que j’ai écrit à ce sujet en cliquant sur ce lien : [voir l'article sur l'architecture hexagonale en front-end](/blog/hexagonal-architecture-front-end).


Qu'est-ce que l'inversion et l'injection de dépendances et pourquoi l'utiliser en front-end ? Explications et exemple concret d'un projet front-end en React.js et Next.js

Inversion de dépendances en front-end


Dans cet article nous allons découvrir l’architecture hexagonale et comprendre pourquoi il est intéressant de l’utiliser en front-end. Cet article s’appuie sur un projet que j’ai créé en React & Next.js afin de vous fournir un exemple concret. Le projet est disponible sur Github, le lien se trouve à la fin de l'article. Une version de cet article avec Redux sera bientôt disponible.

L'architecture hexagonale se base sur le concept d'inversion de dépendances. Si vous ne connaissez pas ce concept, je vous invite à lire l'article que j'ai écrit à ce sujet avant de lire celui-ci : [voir l'article sur l'inversion de dépendances](/blog/dependency-inversion-front-end).

![Présentation de l'architecture hexagonale](/blog/hexagonal-architecture-front-end/diagramme-architecture-hexagonale.png)



## Qu’est-ce que l’architecture hexagonale ?

### 1. Définition
   C’est une architecture de code basée sur l’utilisation de ports, d’adaptateurs et de l'inversion de dépendances. Le but est d’avoir une application faiblement couplée aux dépendances externes comme une base de données, une API, un framework ou encore une librairie.

Pour simplifier ces termes, le but est d’avoir une interface, c’est-à-dire un contrat, qui définit comment une action va envoyer et recevoir des informations à des services externes comme une base de données, une API, une librairie ou autre.

### 2. Les différentes parties
#### a. Use case
Un use case définit une action de l’utilisateur. L’objectif est de ne pas utiliser de librairies ou de frameworks ici car le but est de ne pas coupler la logique à ces outils.

En front-end, un use case peut être une fonction ou une classe. Plus spécifiquement dans un projet React, redux peut être une exception et être considéré comme les uses cases. Dans ce cas, les actions sont les use cases, le state est le modèle et les sélecteurs sont utilisés pour mapper les données entre différents modèles.

#### b. Port primaire
Ce sont les contrats situés entre les use cases et les adaptateurs primaires. Ils peuvent être représentés par des interfaces. En général, le use case est aussi considéré comme port primaire, ainsi il n’y a pas besoin de créer d’interface pour cela.

#### c. Adaptateur primaire
L’adaptateur primaire est l’élément qui dialogue avec le domaine. Son rôle est de déclencher des use-cases. Par exemple en front, les adaptateurs peuvent être des composants React qui déclenchent des actions redux ou de simples fonctions du domaine.

#### d. Port secondaire
Le port secondaire est l’interface qui définit le contrat entre les uses cases et les adaptateurs secondaires. Cette interface est utilisée par les use-cases pour faire appel à des services externes implémentés par les adaptateurs secondaires. C’est ici que nous retrouvons surtout le principe d’inversion de dépendances.

Pour gagner en flexibilité, vous pouvez également utiliser de l’injection de dépendances afin d’éviter de devoir déclarer votre implémentation de ce contrat à chaque utilisation de use-cases. Pour cela, en front, les middlewares comme redux-thunk ou redux-observable permettent de le faire via des arguments passés à la configuration de votre store redux. Si vous n’utilisez pas redux, vous pouvez utiliser InversifyJS.

#### e. Adaptateur secondaire
L’adaptateur secondaire est l’implémentation du port secondaire. Ils sont appelés indirectement par les use-cases. Par exemple, en front-end, ils peuvent être représentés par des classes ou des fonctions qui effectuent des requêtes HTTP, qui accèdent à une base de données côté client, etc.

## Pourquoi utiliser l’architecture hexagonale en front-end ?
### 1. Ne plus être dépendant des librairies et frameworks
   Grâce à l'architecture hexagonale, la logique de votre projet front-end n'est plus dépendante des librairies et frameworks comme React, Vue ou encore Next.js.

Ce qui implique que si l'un de ces outils n'est plus maintenu ou ne vous convient plus, vous pouvez changer de librairie ou de framework sans avoir à re-développer tout le projet. Il faudra uniquement modifier la partie visuelle du projet.

### 2. Pouvoir tester facilement et efficacement un projet front-end
   Grâce à l'inversion de dépendances et au fait que votre domaine doit être indépendant, vous n'avez plus besoin de rendre vos composants, de "mocker" vos requêtes HTTP, etc.

Vous avez uniquement besoin d'utiliser une fausse implémentation de votre service externe comme l'API dans vos tests. Ainsi, vos tests se découpent en trois grandes catégories :
- **les tests unitaires** : ils servent à tester votre domaine
- **les tests d'intégrations** : ils testent vos implémentations externes
- **les tests de bout en bout** : ils sont utiles pour tester l'intégralité de votre application en même temps

### 3. Avoir le même core pour une app mobile et une app web
   Ce point rejoint le premier point expliqué précédemment. Étant donné que votre logique est indépendante des frameworks et librairies utilisés, vous pouvez avoir le même code pour la logique de vos applications.

### 4. Développer le front-end sans le back-end
   Grâce à l'inversion de dépendances représenté par le port secondaire, vous pouvez développer le front-end d'une application sans le back-end.

Pour cela, il suffit de procéder de la même manière que pour les tests en utilisant une fausse implémentation.

Cette méthode est pratique dans le cas où vous souhaitez développer une fonctionnalité pour la faire tester à quelques utilisateurs. Elle est également utile dans le cas où les développeurs back-end n'ont pas encore pû développer l'API.

### 5. Développer le front-end sans réseau
   Ce point rejoint le point précédent, grâce à l'inversion de dépendances vous pouvez utiliser une fausse implémentation qui simule le back-end ou l'accès à des services externes. Ainsi, vous n'avez pas besoin d'accès internet pour développer le front-end.

## Exemple d'un projet front-end avec une architecture hexagonale en React & Next.js
Au début de cet article, je vous ai présenté un diagramme pour visualiser l'architecture hexagonale. Je vous en propose un nouveau mais avec des termes liés au front-end.

![Présentation de l'architecture hexagonale en front-end](/blog/hexagonal-architecture-front-end/diagramme-architecture-hexagonale-front-end.png)

Maintenant que nous avons vu ce qu'est l'architecture hexagonale et quels sont les intérêts de l'utiliser, nous allons voir comment s'en servir dans un projet front-end, en React et Next.js.

Pour cela, j'ai choisi un sujet simple et connu : une todo list. Le projet est disponible sur Github en cliquant sur ce lien : [voir le projet](https://github.com/dimitridumont/clean-architecture-front-end).

Dans cet article, nous allons nous focaliser sur une fonctionnalité du projet : la récupération de la liste des tâches. Nous allons commencer par développer l'un des adaptateurs primaires, qui est un composant React.

### 1. Création de l'adaptateur primaire
   ![Présentation d'un adaptateur primaire de l'architecture hexagonale en front-end](/blog/hexagonal-architecture-front-end/todolist-component.png)
   Dans ce composant, nous récupérons simplement une liste de tâches via un use case _getTodos_ en lui passant l'implémentation du port secondaire _TodosOutput_. Une fois la liste des tâches récupérée, nous la stockons dans notre state React en utilisant un mapper afin de s'assurer que l'objet récupéré correspond au modèle que nous utilisons dans notre composant.

### 2. Création du use case
   ![Présentation d'un use case de l'architecture hexagonale en front-end](/blog/hexagonal-architecture-front-end/todolist-use-case.png)
   
Le use case utilisé pour récupérer la liste des tâches est représenté par une fonction. Elle prend en paramètre le port secondaire _TodosOutput_ afin de l'utiliser pour récupérer la liste de tâches. Comme vous le voyez, notre use case (domaine) n'a aucune connaissance de la manière dont il récupère les données. Il utilise simplement le port secondaire, qui est une interface, pour récupérer ces données.

### 3. Création du port secondaire
![Présentation d'un port secondaire de l'architecture hexagonale en front-end](/blog/hexagonal-architecture-front-end/todolist-secondary-port.png)

   Ici nous créons notre port secondaire utilisé par le use case. C'est une interface Typescript qui sert à établir un contrat.

### 4. Création de l'adaptateur secondaire
![Présentation d'un adaptateur secondaire de l'architecture hexagonale en front-end](/blog/hexagonal-architecture-front-end/todolist-secondary-adapter.png)
   
Comme vous pouvez le voir, la classe _TodosLocalStorage_ représente l'adaptateur secondaire, qui implémente l'interface _TodosOutput_, le port secondaire. Ici nous utilisons le localStorage pour stocker et récupérer les données, nous aurions aussi pû utiliser des requêtes HTTP pour accéder à une API ou une base de données côté client.

Tout l'intérêt de l'architecture hexagonale est justement d'avoir plusieurs implémentations ou de les changer selon les services utilisés sans avoir besoin de modifier notre core.

### 5. Exemple de deux tests unitaires
![Présentation de tests unitaires avec l'architecture hexagonale en front-end](/blog/hexagonal-architecture-front-end/todolist-unit-tests.png)

Voici un exemple de quelques tests unitaires. Comme je l'ai expliqué au début de cet article, les tests unitaires ont pour objectif de tester le core de l'application, la logique.

Ainsi, notre test utilise le use case _getTodos_ en lui passant cette fois-ci un adaptateur secondaire différent : _TodosInMemory_. Cet adaptateur est une autre implémentation du port secondaire _TodosOutput_. C'est une classe qui implémente l'interface _TodosOutput_.

Les tests sont assez simples, ils exécutent et récupèrent les données renvoyées par le use case _getTodos_ et les comparent à de fausses données attendues.

### 6. Création d'un autre adaptateur secondaire pour les tests unitaires
![Présentation d'un adaptateur secondaire utilisé pour les tests avec l'architecture hexagonale en front-end](/blog/hexagonal-architecture-front-end/todolist-secondary-adapter-in-memory.png)

   Voici l'adaptateur secondaire utilisé pour les tests unitaires précédents.

## Conclusion
Pour conclure, l'architecture hexagonale est un outil permettant d'organiser son code de manière à ce que la logique de votre projet soit indépendante des outils externes.

Elle est tout aussi importante en front-end afin de pouvoir être indépendant des librairies et frameworks qui évoluent régulièrement et rapidement. Elle vous permet de tester correctement et facilement votre application, en plus de pouvoir faire évoluer les services externes utilisés rapidement. Il faut voir cela comme des plugins qui doivent respecter des règles pour être utilisés par notre application.

Si cet article vous a aidé à mieux comprendre l'architecture hexagonale et à savoir comment l'utiliser en front-end, n'hésitez pas à le partager à vos collègues.

Lien du projet sur Github : [https://github.com/dimitridumont/clean-architecture-front-end](https://github.com/dimitridumont/clean-architecture-front-end)


Qu'est-ce que l'architecture hexagonale et pourquoi l'utiliser en front-end ? Explications et exemple concret d'un projet front-end en React.js et Next.js

Architecture hexagonale en front-end


Bonjour, je suis Dimitri Dumont, développeur front-end freelance. Je suis passionné par les notions qui tournent autour du “software craftsmanship”.

J’ai récemment acheté le livre **Clean Code — A Handbook of Agile Software Craftsmanship** de Robert C. Martin (ou Uncle Bob). J’ai décidé de partager mes notes personnelles prises durant sa lecture.

![Livre Clean code de Robert C. Martin](/blog/livre-clean-code.jpeg)

Si vous souhaitez lire la première partie, qui est l’introduction de la notion de “clean code”, vous pouvez la retrouver ici : [cliquez-ici](/blogecrire-code-de-qualite-1)

## Utilisez des noms significatifs
L’objectif de cette deuxième partie est de comprendre pourquoi il faut utiliser des noms significatifs et comment le faire.
En tant que développeur, nous nommons constamment des variables, des fonctions, des classes, des objets, etc. Étant donné que nous le faisons très souvent et dans chaque projet, il est important de faire attention aux noms que nous utilisons.

## Conseil n°1 : utilisez des noms qui révèlent l’intention
Pour commencer, il faut savoir que choisir un bon nom pour une variable, une classe ou tout autre élément dans un programme prend du temps.
Il ne faut donc pas avoir peur de renommer vos variables durant votre projet lorsque vous en trouvez des meilleurs. Avec les IDE, vous pouvez très facilement renommer une variable sans vous soucier de son utilisation, l’IDE se chargera de la renommer lors de ses importations et de ses utilisations.

L’une des premières règles sur le nommage, c’est que le nom doit révéler ce que fait une fonction ou à quoi sert une variable.

Prenons un exemple, si vous souhaitez avoir une variable qui correspond à un utilisateur :

`let u;`

Maintenant, renommons cette variable pour qu’on puisse comprendre plus facilement son usage :

`let user;`

Ainsi, lorsque vous reviendrez sur cette partie de code ou lorsqu’un autre développeur travaillera dessus, il ne perdra pas de temps à comprendre cette variable.

## Conseil n°2 : évitez la désinformation
Qu’est-ce que la déformation ? Imaginons que vous souhaitez déclarer une variable qui représente un groupe d’utilisateurs, il peut être tentant de nommer cette variable userList. Le problème ici, c’est qu’en utilisant le mot List vous pouvez laisser croire que cette variable est une liste au sens développement. On peut donc supposer que cette variable est un tableau par exemple, alors qu’au final, elle peut très bien être un objet qui contient des utilisateurs.

La solution est d’utiliser un nom qui n’a pas de signification sur son type : _userGroup_ ou _users_.

Dans le livre, Robert C. Martin prend aussi l’exemple du 0. En fonction des polices utilisées par votre IDE, le zéro peut être interprété comme un o.
La solution est tout simplement de renommer la variable 0 en zero.

## Conseil n°3 : distinguez correctement vos noms
Vous ne devez pas avoir des noms qui se ressemblent. Par exemple pour des fonctions, évitez ça : _getActiveCustomer()_, _getActiveCustomers()_, _getCustomerData()_
N’utilisez pas des termes techniques : _variable, table, list, etc_.

## Conseil n°4 : utilisez des noms prononçables
Les noms que vous choisissez dans vos programmes seront prononcés régulièrement, que ce soit par vous ou par vos collègues. Utilisez donc des noms facilement prononçables comme _meetingDate, meetingCustomer_ plutôt que _mDt, mCtm_.

## Conseil n°5 : les noms doivent être facilement trouvables
Les noms qui sont composés d’uniquement un caractère, comme par exemple i, u et 0 sont difficilement trouvables au milieu du code.
Uncle Bob conseille d’utiliser ce type de nom (un seul caractère) uniquement dans les petites méthodes. Vous pouvez garder par exemple le caractère i pour représenter l’index dans une boucle. Mais excepté ce cas précis, évitez les noms composés d’un seul caractère.

## Conseil n°6 : n’utilisez pas des noms incompréhensibles
Il est inutile de perdre du temps à comprendre le nom de la variable, d’une fonction ou d’une classe. Choisissez des noms explicites et simples.

## Conseil n°7 : n’utilisez pas de types dans les noms
Uncle Bob nomme le fait de nommer un élément dans le code avec son type, par exemple _addressString_ comme dangereux pour la lecture, pour changer le nom plus tard et pour changer tout simplement l’élément.

Si vous développez en JavaScript par exemple, il peut être intéressant d’utiliser TypeScript pour typer vos objets et vos variables afin d’éviter ce genre de noms.

## Conseil n°8 : utilisez des noms que d’autres personnes connaissent
Lorsque vous travaillez sur un projet, il est intéressant d’utiliser les mêmes termes et mots que les autres. Cela évitera aux autres développeurs de perdre du temps à essayer de comprendre le nom de chaque élément dans le code et ainsi de leur utilité.
Vous pouvez pour cela, utilisez les termes du secteur du projet. Par exemple, si vous travaillez sur une application de gestion de rendez-vous, vous pouvez utiliser les termes suivants : _meeting, appointment, contributor_.

## Conseil n°9 : nom des classes
Les noms des objets et des classes doivent être des noms ou des groupes de noms.
Exemple : _User, Customer, Meeting, Account, Car_.

## Conseil n°10 : nom des fonctions
Les noms des fonctions doivent contenir un verbe.
Exemple : _getActiveUsers(), deleteArticle(), updateAddress()_.

## Conseil n°11 : choisissez un mot par concept
Lorsque vous choisissiez un mot pour un concept. Si par exemple pour récupérer des utilisateurs vous choisissiez le mot get pour la fonction _getUsers()_, n’utilisez pas le mot _retrieve_ ou _fetch_ dans d’autres noms.

## Conseil n°12 : n’utilisez pas deux mêmes noms pour deux choses différentes
Si vous devez utiliser le même mot pour deux éléments différents, alors choisissez deux mots différents car ce ne sont pas les mêmes éléments.

## Conclusion
Pour conclure sur cette deuxième partie, qui correspond au deuxième chapitre du livre **Clean Code — A Handbook of Agile Software Craftsmanship** de Robert C. Martin, le choix des noms que vous utilisez dans votre code est très important.

Plus un nom sera simple, explicite et réfléchi, plus vous gagnerez du temps à vous relire et à comprendre l’utilité d’une fonction, d’une variable ou d’une classe.

_L’une des différences entre un développeur intelligent et un développeur professionnel c’est que le professionnel comprend que la clarté est maitresse. Les professionnels utilisent leurs forces pour écrire du code de qualité que les autres peuvent comprendre.
Robert C. Martin — A Handbook for Agile Software Craftsmanship_


Pourquoi et comment écrire du code de qualité (clean code) en tant que développeur ? Cet article vous introduit la notion de clean code - partie 2

Clean code, écrire du code de qualité - Partie 2


Bonjour, je suis Dimitri Dumont, développeur front-end freelance. Je suis passionné par les notions qui tournent autour du “software craftsmanship”.

J’ai récemment acheté le livre Clean Code — A Handbook of Agile Software Craftsmanship de Robert C. Martin (ou Uncle Bob). J’ai décidé de partager mes notes personnelles prises durant sa lecture.

Si vous souhaitez lire la deuxième partie qui porte sur le nommage, vous pouvez la retrouver en cliquant sur ce lien : [cliquez-ici](/blogecrire-code-de-qualite-2)

## Quel est le but de cette série d’articles ?
Il est intéressant de prendre des notes lorsque nous lisons un livre. Cela permet de mieux retenir les notions abordées et de les approfondir.

Ce livre est destiné aux développeurs qui souhaitent s’améliorer. Il aborde le sujet de “clean code”, qui est une notion importante dans notre métier de développeur. Ainsi, le but de cet article est de vous partager mes notes personnelles concernant le premier chapitre de ce livre. Chaque article de cette série vous permettra de découvrir les notions que je trouve importantes. Si le sujet vous intéresse vraiment, vous pourrez acheter le livre et le lire.

Enfin, un autre objectif de cet article, est de proposer du contenu sur la thématique de “clean code” en français.

Clean Code : écrire du code de qualité — Partie 2 Pourquoi et comment écrire du code de qualité (clean code) en tant que développeur ? Quelle est l’importance des noms…

## Le code existera toujours
Le code représente les détails des fonctionnalités d’un système. Malgré les progrès du no-code, les avancés technologiques et techniques sur les langages, contrairement à ce que certaines personnes disent, nous aurons toujours besoin de développeurs pour créer des systèmes, des applications ainsi que des sites internet. Il est donc nécessaire de porter une attention au code produit.

## Le code de mauvaise qualité
Un code de mauvaise qualité est un code développé sans discipline. Nous avons tous écrit du code de mauvaise qualité un jour. On reconnaît ce genre de code au fait de ne pas le comprendre et de ne pas pouvoir y toucher sans avoir peur de tout casser.

La raison la plus récurrente est que le développeur se dépêche de terminer une fonctionnalité ou un projet. Ainsi, il développe rapidement sans discipline pour finir à temps. Il ne prend pas le temps de nettoyer son code produit dans l’urgence. Il se dit qu’il le fera plus tard, que pour le moment il faut se dépêcher de terminer les fonctionnalités qu’il a promis de faire. Il ne reviendra jamais dessus pour faire du refactoring.

Le problème avec le fait de produire du code de mauvaise qualité, c’est que pour le maintenir ou ajouter une nouvelle fonctionnalité, cela devient très compliqué et demande de plus en plus de temps.

Au début de chaque projet, il est facile et rapide de créer et de modifier des fonctionnalités. Mais au fur et à mesure du développement, sans discipline et en voulant aller vite, cela devient de plus en plus compliqué. Il faut alors de plus en plus de temps pour développer le projet.

Ce qui est problématique, c’est que si les développeurs manquent de plus en plus de temps pour développer les nouvelles fonctionnalités, ils créaient de plus en plus de code mauvais. C’est une boucle dangereuse qui fait diminuer la productivité au fil du temps.

![Graphique de la productivité au fil du temps dans un projet mal codé](/blog/productivity-time.png)

## Vous êtes responsable de votre travail
Certains développeurs pensent qu’ils sont obligés de produire du code de mauvaise qualité car leur manager, leur client ou tout autre personne leur demande de respecter les délais. Ainsi, ils se contraignent parfois eux-mêmes à travailler rapidement sans porter une attention à leur travail.

Vous avez certainement déjà entendu ou même dit :

- “pas besoin de faire des tests, ça prend du temps, ça va ralentir l’avancée du projet”
- “c’est bon, ça fonctionne, c’est le principal. Je vais refactor plus tard, pour le moment, il faut livrer.”

Ce type de remarques est généralement dites soit par des personnes qui n’ont pas connaissances des effets à ne pas produire du code de qualité, soit par des développeurs pour qui manquent de compétences (ou qui n’ont pas envie de travailler correctement, par fainéantise).

Le but d’un développeur n’est pas uniquement de créer une fonctionnalité et qu’elle soit fonctionnelle. C’est aussi de la rendre facilement maintenable et évolutive.

Si le problème ne vient pas de vous en tant que développeur, mais d’une personne externe qui vous dirige. Elle qu’elle vous oblige à ne pas travailler correctement, rappelez-vous que vous êtes le professionnel. C’est donc vous qui savez comment aller vite en produisant un code solide et durable.

Pour cela, il existe plusieurs solutions, en voici deux :
- vous pouvez échanger avec cette personne, si elle est compréhensive et que vous démontrez les avantages de faire correctement votre travail, il comprendra et vous laissera faire
- si elle est totalement contre le fait de travailler avec les bonnes pratiques, alors ne lui en parler pas. Ne dites pas que vous faites des tests, du refactoring, etc. Etant donné que vous ne perdrez pas du temps et que vous en gagnerez, cette personne ne se souciera pas de la manière dont vous travaillez

## Les refontes
Parfois, certains développeurs proposent de réaliser une refonte du projet. Le problème avec cette pratique, c’est que sans discipline, le résultat sera exactement le même que le projet initial.

Vous n’êtes pas obliger de reprendre le projet à zéro, ou d’effectuer des grandes phases de refactoring. Par exemple, lorsque vous devez ajouter une nouvelle fonctionnalité, ou lorsque vous devez en modifier une, vous pouvez commencer par modifier les noms des variables qui ne sont pas définies correctement ou par améliorer une condition if sur le code où vous allez intervenir.

## Définition du “clean code”
Un code de bonne qualité est un code qui a été développé par des développeurs soucieux de leur travail.

Il est facilement compréhensible grâce au choix du nom des variables, des fonctions, des classes, etc. Vous devez comprendre ce qu‘il fait rapidement.

Ce code doit être correctement organisé grâce au formatage, aux différents design patterns et à son architecture.

Il ne contient pas de duplication, il est facilement testable et a peu de dépendances.

## Conclusion
Pour conclure, croire que se dépêcher et qu’écrire du code sans discipline vous aidera à aller plus vite est une erreur. Car comme nous l’avons vu, c’est une boucle qui diminue votre productivité au fil du temps et fait perdre de l’argent au client.

Dans les prochains articles, nous verrons comment écrire du “clean code”.

Si vous souhaitez lire la prochaine partie qui porte sur le nommage, vous pouvez la retrouver ici : [cliquez-ici](/blogecrire-code-de-qualite-2)


Pourquoi et comment écrire du code de qualité (clean code) en tant que développeur ? Cet article vous introduit la notion de clean code - partie 1

Clean code, écrire du code de qualité - Partie 1

Dans cet article je vais vous partager mon expérience lors de l’achat de ma résidence principale avec ma compagne en ayant dans le couple un CDD et une micro-entreprise.

Si vous aussi vous êtes dans une situation similaire, cet article peut vous apporter quelques astuces et conseils pratiques pour l’obtention de votre prêt immobilier ! Je ne suis en aucun expert ou banquier. L’objectif est simplement de vous partager notre expérience.

## Contexte
Lors du premier confinement avec ma compagne nous avons décidé de commencer à rechercher une maison pour acquérir notre résidence principale. Nous avions à ce moment 21 et 22 ans. Ma compagne venait d’obtenir un CDD en tant qu’aide soignante (contrat d’1 mois renouvelable) et pour ma situation j’entamais la troisième année de ma micro-entreprise.

Nos critères et le secteur dans lequel nous recherchions notre résidence principale étaient assez complexes : nous recherchions une maison de 100m carré minimum, avec un garage et/ou un sous-sol, avec du charme et un peu de terrain, dans un village précis.

Une fois les critères établis, nous avons commencé à nous documenter sur l’achat immobilier, que ce soit dans notre entourage mais aussi sur internet grâce aux vidéos, articles et podcasts sur le sujet.

C’est à ce stade que j’ai compris que ça serait compliqué d’obtenir un emprunt à deux avec une micro-entreprise d’à peine 3 ans d’activité et un CDD. Nous avons quand même voulu tenter le coup et pour cela nous avons essayé de mettre toutes les chances de notre côté.

## Conditions pour obtenir un prêt
Avant d’obtenir un prêt immobilier il faut comprendre comment les banques acceptent de donner un prêt. Un prêt immobilier, en fonction de votre projet, est un prêt financier assez important qui engage sur le long terme. Pour être concret, notre achat était de 190 000€ (sans les frais de notaires et de dossiers). Pour nos projets et notre style de vie, nous souhaitions emprunter sur le long terme, c'est-à-dire 25 ans.

Donc nous devions trouver une banque qui aurait confiance en notre capacité de remboursement pour nous prêter un certain montant sur 25 ans avec notre situation.

Le fait d’avoir un CDD et une micro-entreprise n’enchante pas les banques et les assurances car comparé au CDI, ces contrats et situations ne sont pas forcément stables.

En ayant connaissance de cette situation, il fallait donc qu’on gagne la confiance des banques en leur montrant qu’on avait une situation stable et qu’on serait capable de rembourser l’emprunt sans problèmes.

## Préparation du projet
Pour commencer les banques regardent les comptes courants afin de voir l’argent que vous gagnez et ce que vous dépensez. Avec ma compagne nous avons toujours fait attention à avoir un train de vie qui corresponde à nos revenus. Nous n’avons jamais eu de découverts et n’avons jamais fait des crédits ou d’emprunts.

Ensuite, en sachant que les banques aurez peu confiance en notre capacité de remboursement et en notre situation, nous avons épargné le plus possible. Cela permet de démontrer au banque que malgré votre contrat ou votre micro-entreprise, votre situation est pérenne et qu’en plus de vivre normalement, vous pouvez même mettre de l’argent de côté. Cet argent de côté nous a permis d’avoir un apport de 10% (en 2021) tout en gardant en plus une épargne. Ainsi les frais de notaires et de dossiers étaient réglés grâce à cet apport. C’est un point que les banques apprécient.

Enfin, nous avons préparé notre projet que nous allions présenter aux banques. Pour cela nous avons regroupé sous format numérique et papier tous les documents obligatoires pour une demande de prêt (fiches de paie, relevés de comptes bancaires, impôts sur le revenu, etc.). Tous ces documents étaient correctement nommés et rangés pour faciliter leur utilisation par les banquiers.

Étant micro-entrepreneur et développeur freelance, il était important que les banques comprennent un minimum mon activité. Pour cela j’ai préparé différents documents pour expliquer mon travail de développeur, comment j’obtenais mes clients, l’évolution et le suivi de mon activité en termes de finances, etc. Lorsque nous avons présenté notre projet à notre banquière, elle n’avait quasiment rien à préparer de plus (venant de notre part).

Je pense que les banques n’accordent pas forcément la même confiance à toutes les activités. Le développement web étant une activité recherchée, je pense que cela a joué favorablement en notre faveur.

Tous ces points ont montré notre sérieux et nous ont permis d’être crédible auprès des banques.

Ainsi, nous n'avons eu besoin que d’une seule banque pour obtenir le prêt que nous souhaitions avec un taux intéressant. Nous avons eu plusieurs échanges, notamment pour expliquer mon activité, mais tout s’est plutôt bien passé. Nous avons réussi à avoir le prêt à 22 et 23 ans, en étant en CDD & micro-entrepreneur.

## Résumé
Pour résumer, il faut que vous arriviez à démontrer votre stabilité financière et votre capacité d’emprunt auprès des banques.

Pour cela, voici ce que nous avons fait :
- avoir un train de vie en adéquation avec nos revenus : ne jamais être à découvert
- nous n’avions pas d’emprunt en cours
- nous avons constitué une épargne (10% du montant de l’emprunt et plus)
- nous avons préparé à l’avance tous les documents nécessaires pour la demande de prêt, avec en plus une présentation de mon activité de freelance

J’espère que cet article vous aidera à obtenir votre prêt si vous êtes dans cette situation, n’hésitez pas à le partager. Si vous avez d’autres conseils ou des remarques, n’hésitez pas à me les envoyer pour que je puisse alimenter cet article.


Comment obtenir un prêt lorsqu'on est freelance, micro-entrepreneur ou en CDD ? Je vous partage mon expérience en tant que freelance lors de l'achat de ma résidence principale.

Retrouvez tous les articles

Inversion de dépendances en front-endPopulaire 🚀️

Architecture hexagonale en front-endPopulaire 🚀️

Clean code, écrire du code de qualité - Partie 2

Clean code, écrire du code de qualité - Partie 1

Obtenir un prêt en tant que freelance