
Dependency inversion and dependency injection are fundamental concepts in software development that enhance the modularity, maintainability, and testability of applications. While often associated with back-end projects, these principles hold significant importance in the context of front-end projects as well.

In this article, we will explore what dependency inversion and dependency injection are, and how to effectively apply them in your front-end projects using TypeScript, React.js, and Next.js.

If you're interested in delving deeper into these concepts, you can read the article I've written about Hexagonal Architecture in the front-end (also known as clean architecture) by clicking on this link: [Read the article on Hexagonal Architecture in Front-End](/blog/hexagonal-architecture-front-end).

## Understanding dependency inversion

Dependency inversion is a key principle of software development that involves reversing the flow of control within an application. Instead of a structure where low-level modules depend on high-level modules, dependency inversion advocates that low-level modules are independent and dependencies are provided externally.

In the front-end context, this means that components should not directly depend on external services, but rather depend on interfaces (or types) that we define as needed. This improves application flexibility and facilitates testing by allowing real dependencies to be easily substituted with simulated dependencies during testing.

## The benefits of dependency inversion
1. **Increased modularity:** Modules become more independent and can be reused in different contexts.
2. **Ease of testing:** Business code no longer depends on external dependencies, we can quickly and easily simulate these dependencies.
3. **Ease of maintenance:** Changes in an addiction are confined to one place, reducing the chances of domino effects.
4. **Reduced coupling:** Dependencies are not directly integrated into the code, which reduces the coupling between the different parts of the application.

## Apply dependency inversion with TypeScript, React.js and Next.js
Now that we have seen the theoretical part of front-end dependency inversion and injection, we will see how to apply it in a front-end project using TypeScript, React.js and Next.js.

TypeScript offers strong typing which can be used to define clear and precise interfaces for dependencies. You can use interfaces or types. Defining interfaces for dependencies makes it easier to substitute real dependencies with simulated dependencies during testing.

For the example project, we will develop a feature that allows you to connect.

### Example without dependency inversion
In order to understand why dependency inversion is important on the front-end, here is an example of code that you can find in most projects:
```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
```

In this example, the HTTP request to the API that allows the user to log in is directly in a React component. The problem with this practice is that we cannot easily test this component. Indeed, we cannot simulate the HTTP request to test the behavior of the component in different scenarios (for example, if the request fails).

Likewise, our React component, i.e. our user interface, is directly tied to the API request. If we want to change the API to connect, we need to modify our React component. This can be problematic if we have multiple components that depend on this API.

There is also another problem, if we want to add a new feature which requires login, we have to rewrite the login code in each component. This can quickly become problematic if we have several components that require connection.

Finally, our UI (the React components) contains business logic, which is not a good practice. This is because our React component should only focus on the UI and should not contain business logic. This makes our component harder to maintain and test.

### Example with dependency inversion
To avoid all these problems, we can implement dependency inversion. To start, we'll create an interface for the authentication service:
```typescript
export type AuthService = {
  login(email: string, password: string): Promise<User>
  logout(): Promise<void>
}
```

Then we can implement this interface to make our API call:
```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
    })
  }
}
```

So, to make the API call, just use the interface in your code. This prevents your components from depending on external libraries or services. Here is an example of a React component that uses the interface defined above for dependency inversion:
```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
```

To simplify your code, you can create a type that groups all the interfaces:
```typescript
import { AuthService } from "../auth.service.ts"

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

Then, depending on the context of your code (if you are in the client part, in the server part or in the tests, etc.) you can create an object that groups all the implementations of your interfaces:
```typescript
import { Dependencies } from "../dependencies.ts"
import { AuthApi } from "../auth.api.ts"

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

Thus, all you have to do is call your dependencies using this object in the context you want. As part of a front-end React project, you have several possible solutions:

### Call your dependencies implementations directly in your code, for example in a React component
```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
```

### Create a context and a provider to allow all components to access dependencies
1. React context creation
```tsx
// dependencies.context.ts
import React, { createContext, useContext } from 'react'
import { AuthService } from "../auth.service.ts"

// Create the dependency context
const DependenciesContext = createContext<Dependencies | null>(null)

// Create a hook to use dependencies in your components
export const useDependencies = () => {
  const context = useContext(DependencyContext)
  if (!context) {
    throw new Error('useDependencies must be used within a DependencyContextProvider');
  }
  return context
}

// Provider component to wrap your application with dependencies
export const DependenciesContextProvider: React.FC<Dependencies> = ({ children, ...dependencies }) => {
  return <DependencyContext.Provider value={dependencies}>{children}</DependencyContext.Provider>
}
```

2. Context implementation in the 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. Using context in your components to access dependencies
```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
```

### If you are using redux in your React project, you can use middlewares like redux thunk to inject your dependencies

With redux toolkit and redux thunk, you have to use the getDefaultMiddleware function and use the extraArgument key of the thunk object to pass the dependencies to the thunks:
```typescript
// store.ts
import { dependencies } from '../dependencies.ts'

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

Thus, you can access the injected dependencies from your 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
Inversion and dependency injection are practices that bring many benefits to development projects. Applying these principles using TypeScript, React.js, and Next.js in front-end projects allows you to build applications that are modular, easily testable, and scalable.

By reducing coupling with external libraries and services, these approaches improve code quality and facilitate long-term maintenance. These practices are also at the heart of French architecture (clean architecture). If you want to know more about it, I invite you to read the article I wrote about it by clicking on this link: [see the article on the front-end hexagonal architecture](/blog/hexagonal-architecture-front-end).


What are dependency inversion and dependency injection, and why use them in front-end? Explained with a concrete example in React.js and Next.js

Dependency inversion in front-end


In this article we will discover the hexagonal architecture and understand why it is interesting to use it as a front-end. This article uses a project I created in React & Next.js to provide you with a concrete example. The project is available on Github, the link is at the end of the article. A version of this article with Redux will be available soon.

The hexagonal architecture is based on the concept of dependency inversion. If you are not familiar with this concept, I invite you to read the article I wrote about it before reading this one: [see the article on dependency inversion](/blog/dependency-inversion-front-end).

![Hexagonal architecture presentation](/blog/hexagonal-architecture-front-end/diagramme-architecture-hexagonale.png)

## What is hexagonal architecture?

### 1. Definition
It is a code architecture based on the use of ports, adapters and dependency inversion. The goal is to have an application loosely coupled with external dependencies such as a database, an API, a framework or even a library.

To simplify these terms, the goal is to have an interface, i.e. a contract, which defines how an action will send and receive information to external services such as a database, an API, a library or other.

### 2. The different parts
#### a. Use case
A use case defines a user action. The objective is not to use libraries or frameworks here because the goal is not to couple the logic to these tools.

In front-end, a use case can be a function or a class. More specifically in a React project, redux can be an exception and considered the use cases. In this case, the actions are the use cases, the state is the model, and the selectors are used to map data between different models.

#### b. Primary Port
These are the contracts between the use cases and the primary adapters. They can be represented by interfaces. In general, the use case is also considered a primary port, so there is no need to create an interface for it.

#### c. Primary adapter
The primary adapter is the element that dialogues with the domain. Its role is to trigger use cases. For example in front, adapters can be React components that trigger redux actions or simple domain functions.

#### d. Secondary port
The secondary port is the interface that defines the contract between the use cases and the secondary adapters. This interface is used by use-cases to call external services implemented by secondary adapters. It is here that we mainly find the principle of dependency inversion.

To gain flexibility, you can also use dependency injection to avoid having to declare your implementation of this contract each time you use use-cases. For this, in front, middlewares like redux-thunk or redux-observable allow to do it via arguments passed to the configuration of your redux store. If you don't use redux, you can use InversifyJS.

#### e. Secondary adapter
The secondary adapter is the implementation of the secondary port. They are called indirectly by the use-cases. For example, on the front-end, they can be represented by classes or functions that make HTTP requests, access a client-side database, etc.

## Why use the hexagonal architecture in front-end?
### 1. No longer be dependent on libraries and frameworks
Thanks to the hexagonal architecture, the logic of your front-end project is no longer dependent on libraries and frameworks such as React, Vue or Next.js.

This implies that if one of these tools is no longer maintained or no longer suits you, you can change libraries or frameworks without having to redevelop the entire project. It will only be necessary to modify the visual part of the project.

### 2. Being able to easily and efficiently test a front-end project
Thanks to dependency inversion and the fact that your domain must be independent, you no longer need to render your components, "mock" your HTTP requests, etc.

You only need to use a mock implementation of your external service like API in your tests. Thus, your tests are divided into three main categories:
- **unit tests** : they are used to test your domain
- **integration tests** : they test your external implementations
- **end-to-end tests** : they are useful for testing your entire application at the same time

### 3. Have the same core for a mobile app and a web app
This point joins the first point explained above. Since your logic is independent of the frameworks and libraries used, you can have the same code for the logic of your applications.

### 4. Developing the front-end without the back-end
Thanks to the dependency inversion represented by the secondary port, you can develop the front-end of an application without the back-end.

To do this, just proceed in the same way as for the tests using a fake implementation.

This method is useful in case you want to develop a feature to test it with a few users. It is also useful in case the back-end developers have not yet been able to develop the API.

### 5. Developing the front-end without a network
This point joins the previous point, thanks to the inversion of dependencies you can use a false implementation which simulates the back-end or the access to external services. Thus, you do not need internet access to develop the front-end.

## Example of a front-end project with a hexagonal architecture in React & Next.js
At the beginning of this article, I presented you with a diagram to visualize the hexagonal architecture. I propose a new one but with terms related to the front-end.

![Hexagonal architecture in front-end](/blog/hexagonal-architecture-front-end/diagramme-architecture-hexagonale-front-end.png)

Now that we have seen what the hexagonal architecture is and what are the advantages of using it, we will see how to use it in a front-end project, in React and Next.js.

For this, I chose a simple and known subject: a todo list. The project is available on Github by clicking on this link: [see the project](https://github.com/dimitridumont/clean-architecture-front-end).

In this article, we will focus on a feature of the project: the recovery of the task list. We'll start by developing one of the primary adapters, which is a React component.

### 1. Creating the primary adapter
   ![Introducing a Front-end Hexagon Architecture Primary Adapter](/blog/hexagonal-architecture-front-end/todolist-component.png)

In this component, we simply retrieve a list of tasks via a _getTodos_ use case passing it the secondary port implementation _TodosOutput_. Once the to-do list is retrieved, we store it in our React state using a mapper to ensure that the retrieved object matches the template we are using in our component.

### 2. Création du use case
![Presentation of a use case of the hexagonal architecture in front-end](/blog/hexagonal-architecture-front-end/todolist-use-case.png)

The use case used to retrieve the task list is represented by a function. It takes the secondary port _TodosOutput_ as a parameter in order to use it to retrieve the to-do list. As you see, our use case (domain) has no knowledge of how it retrieves the data. It just uses the secondary port, which is an interface, to retrieve that data.

### 3. Creation of the secondary port
![Introducing a secondary port of the front-end Hexagon architecture](/blog/hexagonal-architecture-front-end/todolist-secondary-port.png)

Here we create our secondary port used by the use case. It is a Typescript interface that is used to establish a contract.

### 4. Creating the secondary adapter
![Introducing a secondary front-end Hexagon architecture adapter](/blog/hexagonal-architecture-front-end/todolist-secondary-adapter.png)

As you can see, the _TodosLocalStorage_ class represents the secondary adapter, which implements the _TodosOutput_ interface, the secondary port. Here we are using localStorage to store and retrieve data, we could also have used HTTP requests to access a client-side API or database.

All the interest of the hexagonal architecture is precisely to have several implementations or to change them according to the services used without needing to modify our core.

### 5. Example of two unit tests
![Presentation of unit tests with the hexagonal architecture in front-end](/blog/hexagonal-architecture-front-end/todolist-unit-tests.png)

Here is an example of some unit tests. As I explained at the beginning of this article, unit tests are intended to test the core of the application, the logic.

Thus, our test uses the _getTodos_ use case, this time passing it a different secondary adapter: _TodosInMemory_. This adapter is another implementation of the _TodosOutput_ secondary port. It is a class that implements the _TodosOutput_ interface.

The tests are pretty simple, they run and get the data returned from the _getTodos_ use case and compare it to some expected fake data.

### 6. Creating another secondary adapter for unit testing
![Introducing a secondary adapter used for testing with the front-end hex architecture](/blog/hexagonal-architecture-front-end/todolist-secondary-adapter-in-memory.png)

Here is the secondary adapter used for previous unit tests.

## Conclusion
To conclude, the hex architecture is a tool to organize your code in such a way that the logic of your project is independent of external tools.

It is just as important on the front-end in order to be independent of libraries and frameworks which evolve regularly and quickly. It allows you to correctly and easily test your application, in addition to being able to evolve the external services used quickly. You have to see this as plugins that must respect rules to be used by our application.

If this article helped you better understand Hexagon Architecture and how to use it front-end, please share it with your colleagues.

Project link on Github: [https://github.com/dimitridumont/clean-architecture-front-end](https://github.com/dimitridumont/clean-architecture-front-end)


What is the hexagonal architecture and why use it in front-end? Explanations and concrete example with front-end project in React.js and Next.js

Hexagonal architecture in 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](/blog/ecrire-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](/blog/ecrire-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](/blog/ecrire-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.

Find all the articles

Dependency inversion in front-endPopulaire 🚀️

Hexagonal architecture in 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