## ReactJS, un besoin d'organisation

Contrairement à d'autres libraries frontend comme **Angular**, **React** donne beaucoup de liberté aux développeurs pour organiser le code. Mais il est difficile de s'y retrouver si plusieurs personnes travaille avec des méthodologies différentes. **Redux** a apporté une façon d'organiser le code via des événements nommés et connus d'avance. Cependant le code à mettre en place avant de pouvoir le faire est assez dense. Et son utilisation au quotidien peut s'avérer problématique tant il est compliqué d'ajouter de nouveaux événements ou namespaces au fonctionnement existant.

### Comment s'organise le code avec Redux

Depuis que les développeurs frontend se sont mis à **React**, nombreux ont été les tentatives d'organisation du code autour d'un flow qui permet de gérer les états et les changements d'états. 

Dans tout cela, Redux a sorti son épingle du jeu en proposant une approche basé sur des stores de données qui écoutent des événements précis afin de changer d'état. Cependant, sa mise en place n'est pas des plus simple. Cela demande une organisation des fichiers sources, la création de chacun des états et la gestion de chacun des événements. 

Sans compter le fait que les composants qui utilisent ce store doivent être wrappé dans une fonction qui permettra de déclencher un re-render au moment d'un événement. Et que chaque composant doit être attaché au store pour pouvoir utiliser un état de ce dernier. Bref une mise en place qui une fois qu'on s'est habitué n'est pas si compliqué, mais qui demeure complexe à mettre en place et à organiser.

Chaque nouvel événement implique la création de ce dernier et se doit de spécifier comment va réagir le store de donnée en fonction des événements. Toute cette organisation demande surtout énormément de temps, que finalement on en passera pas à créer des features, mais plutôt à organiser notre code et essayer au maximum de gérer side-effects des événements cross-stores... 

![redux-flow ><](https://bo.dev-freelance.fr/uploads/redux_1_drawio_94d90142bc.png)

**Le temps passé à mettre en place l'architecture redux vous coûte cher à l'échelle d'un projet complexe.**

### La mauvaise méthode pour remplacer Redux

La solution à l'ancienne pour impacter un child sans utiliser redux était de créer un state à haut niveau sur un parent element, et passer les getter/setter en props à chaque composants. Ce pattern s'appelle le **props-drill pattern**.

En revanche, vous imaginez bien les limites de ce modèle, il s'agit de passer toujours de plus en plus de props à chaque composants intermédiaire et ses composants imbriqués. 

Pour vous donner une idée : 

![react-props-drill-pattern ><](https://bo.dev-freelance.fr/uploads/redux_2_drawio_579ef0919e.png)

Et en implémentation simplifiée cela donnerait quelque chose comme ça : 


```tsx
import * as React from 'react'

type User = {
  name: string
  age: number
}

type ParentContainerProps = {
  children: React.ReactNode
}

// Mock data fetch
const ConnectUser = (cb: (u: User) => void) => {
  cb({
    name: 'John Doe',
    age: 30
  })
}

// parent-container.tsx
const ParentContainer = ({children}: ParentContainerProps) => {
  const [user, setUser] = React.useState<User | null>(null)
  return (
    <div>
      <UserContainer user={user} setUser={setUser} />
      {children}
    </div>
  )
}

// user-container.tsx
const UserContainer = ({ user, setUser }: { 
  user: User|null, 
  setUser: (u: User) => void 
}) => {
  // Fetch data
  React.useEffect(() => {
    ConnectUser((connectedUser: User) => setUser(connectedUser))
  }, [])
  return user ? (
    <div>
      {user.name} - {user.age} ans
    </div>
  ) : null
}

export default ParentContainer
```

On constate que chaque composant doit avoir les props qui permettent de manipuler un user et se doivent de le passer à chaque child qui en a aussi besoin. Ce pattern est d'autant plus problématique qu'en Typescript, s'il s'agit d'une donnée que l'on récupère de manière asynchrone, cela implique qu'il risque d'être null ou changer d'état.

### Une meilleure approche pour remplacer Redux

Depuis que l'on utilise majoritairement des functional components et des hooks, la manière de faire a changé. Désormais, on emploie le **Provider/Context pattern**. 

La mise en place de ce pattern consiste à wrapper le code dans un Provider. Et comme ses enfants viendront consommer son context, il pourra ainsi gérer le re-render des composants si besoin. 

Pour rendre mon code réutilisable, je passe par les hooks pour isoler les getters, setters. Ainsi seuls les hooks viendront consommer les contexts (aucune lecture en direct) et les composants consommeront les hooks.

![react-provider-context-pattern ><](https://bo.dev-freelance.fr/uploads/redux_3_drawio_b8cda10bc0.png)


```tsx
import * as React from 'react'

type User = {
  id: number 
  username: string
  age: number
  email: string
}

// /context/user-context.tsx
type UserContextValues = {
  connected: boolean
  setConnected: (c: boolean) => void
  userInfos: User
  setUserInfos: (u: User) => void
}

export const UserContext = React.createContext<UserContextValues>({
  connected: false,
  setConnected: () => void,
  userInfos: {
    id: null,
    username: '',
    age: '',
    email: '',
  },
  setUserInfos: () => null,
})

export const UserProvider = ({ children }: { children: React.ReactNode }) => {
  const [connected, setConnected] = React.useState(false)
  const [userInfos, setUserInfos] = React.useState<User>({
    id: null,
    username: '',
    age: '',
    email: '',
  })

  // Get our user
  React.useEffect(() => {
    if (!connected) {
      fetch('/my/user/api/endpoint')
        .then(res => res.json())
        .then(user => {
          setUserInfos(user)
          setConnected(true)
        })
        .catch(err => console.log(err))
    }
  }, [connected])

  return (
    <UserContext.Provider
      value={{
        connected,
        setConnected,
        userInfos,
        setUserInfos,
      }}
    >
      {children}
    </UserContext.Provider>
  )
}

// /hook/use-get-user.tsx
export const useGetUser = () => {
  const { userInfos } = React.useContext(UserContext)
  return userInfos
}

// /components/user-card.tsx
export const UserCard = () => {
  const user = useGetUser()

  return user ? (
    <div className="card">
      <h3>{user.username}</h3>
      <p>{user.age} ans<p>
    </div> 
  ) : null
}

// app.tsx
// ...
return (
  <UserProvider>
    <App />
  </UserProvider>
)
```

Comme on peut le voir, la deuxième méthode est beaucoup plus propre et malgré un plus grand nombre de fichiers à créer, cela reste une approche simple pour accéder à des données centralisées à la manière d'un redux.

lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

large_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

medium_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

small_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

thumbnail_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

React a changé notre vision du développement applicatif. Depuis sa sortie, cette librairie a connu plusieurs modifications, que ce soit le langage ES5, puis ES6, puis Typescript, etc... Redux avait apporté un brun d'organisation dans toute cette tambouille mais, avec un niveau de complexité non négligeable.  Voici une méthode pour y voir plus clair.

Pourquoi je préfère me passer de Redux 

## Quelques astuces pour bien progresser en tant que développeur web

Pour faire suite [au précédent article sur le développement](https://dev-freelance.fr/dev/mes-conseils-de-developpeur-partie-1), voici encore quelques conseils pour vous améliorer en développement.

### 1 - Tester son code

Cela demande du temps de tester en permanence les itérations de votre code source. Mais cette étape est très importante ! Elle assure le bon fonctionnement - parcours prévu, résultat attendu - de votre code.

Il y a plusieurs façon de tester son code : les TU (tests unitaires) souvent réalisé par les développeurs eux-mêmes.  

Il s'agit d'isoler une petite partie du code et tester son fonctionnement. On le fait généralement avec les fonctions que l'on peut tester directement via ses I/O (entrées, sorties). En gros on l'appelle avec des paramètres et on vérifie que la réponse est cohérente et qu'il s'agit bien du résultat attendu, ou comportement attendu s'il s'agit d'un void (fonction sans retour).

Pendant longtemps, les boîtes ont encouragé les développeurs à avoir un fort niveau de coverage, c'est à dire plus de teste sur une plus grande partie du code. Plus le coverage est élevé plus l'entièreté du code est testé. Or, d'expérience, c'est parfois contre-productif de le faire. Je dirais qu'il faut tester essentiellement les logiques complexes et avoir environ 60 à 65% de coverage est déjà largement suffisant.

Au delà, on passe surtout énormément de temps à maintenir les tests, moins à développer des features, en sachant que des langages comme Typescript (mon petit chouchou), règle déjà énormément de problèmes en amont.

Les TU restent cependant terriblement efficaces, a tel point qu'on en a fait une méthodologie de travail : le TDD (test-driven development). Ce qui signifie que l'on va commencer par implémenter les tests avant même de faire le code. 

Par exemple,  je dois faire une fonction qui doit multiplier un entier passé en argument par 2. 
Cette fonction s'appelle multPer2. 
Je commence par faire un test qui vérifie que le résultat est bien égal au double de mon entrée.
Avec les libs de tests assez connu tel que Jest, ça donnerait cela :

```js
describe('test libs', () => {
    it('Should multiply per 2', () => {
        var result = multPer2(2)
        expect(result).toEqual(4)
    })
})
```

Dans ce test, on vérifie que le résultat est égal à 4. Dans le cas contraire, le test renverra une erreur.
Maintenant une fois que les tests sont prêts, je peux commencer à coder ma fonction, le but du jeu est de faire tourner les tests (automatiquement si possible) jusqu'à ce que tout soit ok.

```js
function multPer2(inp) {
    return 2 * inp
}
```

Pour tester le front (des composants react par exemple) ce n'est pas si simple. En général, on utilisera des outils qui permettront de générer un fake DOM et de simuler des timers, pour les lifecycle de render (comme jest, react-testing-library, etc...). Mais ils ne sont pas simple à prendre en main, et si votre composant connait énormément de mutation d'état pour X ou Y raison, cela risque d'être difficile à tester. Mais rassurez-vous il y a des outils spécifiques pour ça : les tests E2E.

Les tests E2E (end-to-end) sont généralement implémentés (code ou no code) par les QA testeurs, donc des profils dédiés à ce type de tests. Mais dans certaines équipe il n'est pas rare que ce soit les développeurs eux-mêmes qui implémentent les E2E. Aujourd'hui, le marché propose de nombreux outils intéressants comme : Cypress ou Playwright et il y a de quoi faire !

Ou au moins testez à la main ce que vous faites, c'est un minimum. De même, si vous relisez la PR d'un collègue, prenez le temps de réellement tester les choses et ne validez pas uniquement en ayant lu sur GIT à moins que ce soit du code très simple CSS, etc... Prenez le temps de le faire.

### 2 - Anticiper le comportement du code

Lorsque vous prenez de l'expérience, vous serez en mesure d'anticiper plus facilement sur la complexité de ce que vous allez implémenter. 
Instinctivement, vous saurez d'avance : 

- quand est-ce qu'une implémentation risque de vous donner du fil à retordre
- quand est-ce qu'une valeur en entrée risque de changer
- pourquoi le code risque de ne pas s'exécuter
- pourquoi une partie de votre code est exécuté avant ou après telle ou telle action
- pourquoi le résultat obtenu risque de ne pas être correct

Maintenant, utilisez votre expérience pour prévenir ce genre de problèmes. Puisque vous savez que cela peut arriver, et que vous êtes en mesure de comprendre pourquoi. Il est possible de mettre en place des gardes-fous.

**Votre expérience ne doit pas vous servir uniquement à coder plus vite, mais surtout à coder mieux.**

J'ai des règles d'organisation et d'anticipation qui globalement fonctionnent très bien et me permet de dormir sur mes deux oreilles.

Voici ma méthodologie :

**La base :**

- J'organise toujours mon code de manière à savoir exactement où est positionné telle ou telle brique. Il faut que je n'ai pas à réfléchir pour retrouver un composant, une lib, une page, les configs, etc...
- Je n'inclus jamais les clés API, tokens et les endpoints au code source, car le code n'est pas hébergé sur ma propre machine. Dans un data center qui sait ce qui peut arriver ? Les sociétés comme Github, Bitbucket et autre ne sont pas à l'abris d'un hack de la couche 0... (l'humain, les employés eux même !). J'utilise l'environnement sans versionner le fichier .env

**Plus technique :**

- Je pars du principe que tout ce qui est externe a mon code n'est pas fiable, donc je redouble d'effort sur les vérifications de ces données. Par exemple une API peut ne pas répondre, changer de format de réponse, etc..., donc, je prends les devant et je vérifie que je dispose des éléments qui me permette de continuer à processer, dans le cas contraire, je m'arrête avant de générer des erreurs ou faire crasher mon programme.
- Lorsque je code du frontend, je réduis au maximum le nombre de composants qui font des calculs ou manipulent des données. En général, je crée le maximum de dumb components, destinés uniquement à faire de l'affichage. Et j'effectue des appels API et des opérations uniquement dans certains fichiers ciblés. Cela me permet en cas de dysfonctionnement de savoir exactement où effectuer une action.
- Je factorise au maximum les utilisation commune ou les schéma commun dans mon code, cela me permet de réduire mes efforts en cas de modification car plusieurs éléments seraient modifiés simultannément.
- Je dissocie la partie API (récupération de données) de la partie exploitation de ces données, afin de ne pas avoir de comportement trop spécifique sur ma brique la plus commune. Par exemple, je traite la réponse d'API et affiche des toasters etc... à l'endroit ou j'appelle ma librairie d'API et pas directement dans la lib.
- Sur les gros projets, je distingue fortement le traitement synchrone du traitement asynchrone. C'est à dire que je préfère garder sur mon API ce qui est vital pour que l'utilisateur puisse avoir le maximum de confort (temps de réponse courts, données essentielles, etc...). Et toute la partie traitement (stats, compteurs, cache, etc...) je le fais via d'autres threads que j'appelle les Workers.  
- Je privilégie toujours la lisibilité plutôt que la sur-optimisation. Biensûr dans certains cas, je préfère optimiser afin de ne pas trop multiplier les instructions et ralentir le code. Mais si cela rend le code plus lisible pour mes collègues, je prends le temps de montrer certaines opérations de manière plus explicite afin d'être plus clair et plus facile à appréhender.

### 3 - Surmonter ses peurs en programmation

A chaque fois qu'un sujet technique vous angoisse, car il vous parait complexe, soyez sûr que si vous le maîtrisez vous apprendrez quelque chose. 

Les outils à disposition des développeurs n'existent pas par hasard. Très souvent, ils sont le fruit de recherches et de travaux destinés à simplifier la vie du développeur.

Par exemple, combien de condition "if" vous faut-il pour remplacer une seule et unique RegExp ? 

Combien d'indentation vous faut-il utiliser dans une série de Promise, au lieu d'utiliser l'async/await ?

Une chose est sûr, cela m'a toujours été bénéfique d'apprendre de nouvelles choses. Et cela devrait être un sujet excitant et pas repoussant. 

Prenez le temps d'appréhender et de tester les nouveaux outils et les nouvelles méthodos. Si les gens en parlent, c'est qu'il y a forcément un intérêt qui a été décelé par développeurs.

Le plus simple est d'intégrer cet apprentissage à votre routine de veille technique. Une partie de votre temps doit impérativement être destiné à la veille technique et doit vous permettre de tester ces outils.

Même si, vous ne comptez pas vous en servir à terme, il est intéressant de savoir dans quelle situation, cela pourrait vous servir. De même, je vous recommande d'utiliser un outil de note, et de toujours noter une description, un exemple et tagger la note afin de la retrouver plus tard. 

**Votre apprentissage doit vous servir à quelque chose, car si vous ne faites que lire sur le sujet, votre lecture ne vous aura servi à rien si vous n'en avez pas tiré une information.**

### 4 - Intéressez vous aux patterns

Il y a des méthodologie partout et sur tout. Nous cherchons sans cesse le moyen de nous organiser, de faciliter la collaboration, c'est pourquoi, des chercheurs créent chaque jour de nouveau outils, des patterns afin de rendre cela possible.

Qu'est-ce qu'un pattern ?

**Un pattern est une méthode de travail qui va organiser comment implémenter notre code afin de répondre à une ou des problématiques (découpage des tâches, compatibilité, communication, etc...)**

Par exemple un Pattern d'organisation de projet MVC (Model, Vue, Contrôleur) cherche à isoler la complexité de chaque ensemble d'éléments (utilisateurs, produits, ventes, paiements, etc...), en le découpant en 3 axes. Si nous voulons utiliser le pattern MVC pour gérer des utilisateurs, nous ferons : 

- le model qui décrit de quoi est composé un utilisateur, ses champs (nom, prénom, age, etc...)
- la vue, c'est à dire comment on va afficher un ou des utilisateurs
- le contrôleur qui fera le lien entre le modèle, donc l'objet utilisateur au sens code et la base de données. En général le model décrira les actions qui manipulent un modèle utilisateur (créer un utilisateur, mettre à jour un utilisateur, etc...)

Ce pattern a plusieurs avantages, son découpage permet non seulement de réduire la complexité, mais de séparer le travail en plusieurs tâches réalisables par plusieurs collaborateurs. 

Dans notre cas, un intégrateur peut se charger de toutes les vues et un développeur peut se charger des Modèles et Contrôleurs...

Et il existe des milliers de patterns intéressants à connaitre qui permettent de régler beaucoup de problèmes. Certains patterns sont mêmes propre à des langages spécifiques, tel que l'Event-Driven Pattern que l'on peut faire essentiellement en JS, C# ou Java. 

Bien sûr il y a souvent des adaptations de certains pattern dans différents langages mais parfois certains langages s'y pretent mal de par leur conception.

Ainsi, je vous recommande d'en savoir plus sur les patterns afin de toujours faire le choix le plus éclairé dans une situation donnée.

### Conclusion

Globalement, le fait de répéter les mêmes choses chaque jour et de s'intéresser au développement vous aidera naturellement à progresser. 

Ce que je vous recommande pour mettre en place quelque chose de concret est de se donner 1 heure par jour de travail approfondi sur un sujet. Que ce soit une nouvelle techno, un pattern, une librairie etc... Se donner 1 heure même en deux session de 30 minutes (matin et soir) c'est une différence énorme sur une année (plus de 200h). En sachant qu'à chaque heure que vous passez à tester, ou réaliser quelque chose, vous devenez meilleur. 

A vos claviers ! 😃

fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

large_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

medium_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

small_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

thumbnail_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

Suite au précédent article où je vous parle de comment je me suis amélioré en tant que développeur. Je vous propose de continuer notre progression ensemble en parlant de ce que l'on peut faire pour devenir meilleur.

Mes conseils de développeur partie 2

## Comment s'améliorer en programmation ?

Ce post reprend un précédent podcast que j'avais fait au sujet de s'améliorer en tant que développeur. 
Retrouvez le [podcast audio sur comment s'améliorer en tant que développeur](https://dev-freelance.fr/media/xp2dev---episode-2---comment-devenir-un-meilleur-developpeur). Je tiens à préciser que cet article est un complément du podcast et ne reprend pas tout ce qui s'est dit précédemment, c'est pourquoi je vous recommande de l'écouter avant ou après cette lecture.

La programmation est une compétence qui demande du temps et de la répétition. A la manière d'un instrument de musique, ou d'une activité sportive, en pratiquant vous allez travailler vos réflexes musculaires, votre endurance, votre intelligence dans ce domaine, en revanche, il ne s'agit pas vraiment de travailler vos muscles, mais vous musclerez votre cerveau à le faire. 

Il est indéniable que vous y développerez des automatismes et comme une boule de neige qui devient de plus en plus grosse en roulant, plus vous coderez, plus vous deviendrez meilleur.

Dans le sport, en musique, ou autre domaine de compétence, il y a cependant des exercices que l'on vous conseille de faire afin de travailler votre compétence. J'ai personnellement passé des années à faire et refaire les mêmes choses jusqu'à atteindre un niveau qui me satisfait et qui me permet de satisfaire toute demande. Pour vous donner un exemple, en 2016, je codais 10 heures par jour (en moyenne 260h par mois, soit plus de 3000h cette année là, Noël compris, jour de l'an compris et jours fériés inclus).

Cette année là, j'ai appris plus de choses qu'en 5 ans dans toute ma carrière...

**Après avoir passé des années à coder voici ce que je vous recommande de faire pour exploser vos résultats et votre niveau en développement.**

### 1 - Recoder des petites librairies que l'on utilise au quotidien

Le gestionnaires de paquet npm, composer et autre voire même les repo git sont remplis de projets et de librairies qui répondent à tous les besoins. Très souvent la mise en place de nouveau projet consiste dans les premiers jours à piocher lesquelles de ces librairies nous allons choisir afin de réaliser notre objectif.

**Les librairies comme _lodash_, _uuid_ etc, sont à la portée de n'importe qui !**

On dit souvent qu'il ne faut pas réinventer la roue, mais ce n'est pas tout à fait vrai. Si ça vous prend 2 minutes pour faire quelque chose, faîte-le et commencez à réfléchir lorsque la chose en question vous prend au moins une journée. 

Mon constat après avoir travaillé dans une dizaine d'équipes différentes : les gens savent de moins en moins comment faire les choses et c'est affolant ! Trop de développeurs sont persuadés que si une librairie existe alors elle répond forcément à notre problématique, sans tenir compte du besoin réel, sans se demander s'il n'y a pas de façon plus optimisée de faire quelque chose.

Il y a plusieurs raisons saines pour lesquels il est intéressant de recoder une librairie :

- Comprendre réellement comment les choses fonctionnes (et croyez-moi, cela règle d'avance tous les problèmes que vous rencontrerez ensuite, bugs et autre)
- Entraîner votre logique
- Créer et utiliser uniquement ce dont vous avez besoin, parfois vous utilisez uniquement 5% d'une lib entière, pourquoi alourdir inutilement vos projets ?
- Etre propriétaire du code source (pas uniquement pour faire joli, mais vous maîtrisez réellement votre repo ou votre package et cela évite les hacks et garantie la propriété intellectuel du reste de votre produit)

### 2 - Continuer à coder

Le fait de ne jamais arrêter de coder est un tremplin pour vos compétences. 

**Faites des projets en permanence**

Il y a plusieurs raisons pour lesquels faire vos propres projets :

- Vous faire plaisir sur un sujet qui vous passionne
- Solutionner un problème du quotidien qui vous tient à coeur
- Tester une nouvelle technologie (un langage, un framework) ou une nouvelle méthodologie (une organisation, un outil)

Lorsque vous travaillez sur un sujet qui vous intéresse réellement, vous décuplerez votre énergie. Vous attaquerez chaque session de dev avec une pêche comme jamais auparavant. 

De même, vous serez forcément confronté à des bugs, ou des problématiques et le fait de trouver la solution vous fera progresser. 

**Si augmenter les poids sur une barre vous fait vous muscler davantage, régler des bugs musclera vos compétences de développeur.**

Mon observation du marché du travail depuis des années est la suivante. Lorsqu'une technologie sort, rare sont les sociétés qui adoptent cette dernière directement dans leur projet. Cela a été le cas pour Node.js (tout le monde restait sur du PHP), pour React (tout le monde restait sur du jQuery), etc...

Cela vous laisse le temps, à la sortie d'une technologie qui vous intéresse, de vous familiariser avec cette dernière. Et là ou les recrutements sont parfois un peu vicieux, lors des entretiens 3 ans après la sortie d'une techno, les RH vous demanderont de justifier d'un maximum de temps d'expérience sur cette compétence, en sachant que le marché l'a adopté bien après... la belle blague. En attendant, si vous l'avez utilisé même dans un cadre personnel, vous sortirez votre épingle du jeu !

En regardant de plus près, quel est le plus gros risque d'une société lorsqu'elle décide d'adopter une nouvelle technologie ? 
La réponse c'est la perte de maîtrise. La société a peur de ne plus rien maîtriser en terrain inconnu, c'est pourquoi beaucoup restent sur leurs acquis et préfèrent tabler sur quelque chose de maîtrise. 

Mais qu'est-ce que la maîtrise en définitive ?
La maîtrise c'est avoir déjà échoué, et savoir comment sortir des problématiques (l'expérience !).

Plus vous passerez à l'action en créant, en vous trompant et en recommençant, vous développerez les skills de toute une vie.

### 3 - Faire de la relecture de code

Relire du code vous permet de voir différentes approches pour répondre à une problématique. Les chemins pour arriver à un résultat sont presque infinis. C'est une gymnastique intéressante de se mettre dans la peau d'un autre et de regarder son cheminement logique. A moins que la logique utilisée soit trop complexe ou tordu, ne jugez pas les autres sur leur implémentation. 

Chacun est différent, chacun pense différemment, c'est pourquoi nous devons portez un regard bienveillant sur ce qui a été fait, et surtout veiller à ce que l'objectif soit atteint. 

Ce processus vous permettra d'apprendre des autres, d'observer les choses sous un autre angle et vous permettra de continuer à développer votre compréhension de la programmation car je le redis, tout est affaire de compréhension. 

**La compréhension règle chaque bug, vous permet d'anticiper sur des problèmes et enlève toutes les barrières mentales que vous pouvez rencontrer en codant.**

### 4 - Faire de la veille technique

**Y a t-il quelqu'un sur youtube, sur git ou twitter qui maîtrise un sujet que vous souhaitez maîtriser ?**

Cette personne pourrait être votre mentor, suivez cette personne, écoutez attentivement ce qu'elle a à dire. Lisez attentivement ses posts. Très souvent les développeurs partagent le fruit de leur recherches et leur observations. Si vous souhaitez apprendre également, rapprochez vous au maximum de ces gens là. 

Combien d'entre-nous ont appris le développement en imitant du code que nous avons vu ? Cela ne retire en rien la compréhension de ce code. A partir du moment où tout ce qui est fait est clair à vos yeux, réutilisez ces informations que votre cerveau détient déjà ! L'avantage avec cette technique, c'est que plus vous le faite, plus vous le faites vites car vous développez des automatismes. 

**Par exemple, regardez combien de temps vous a pris la déclaration de votre première classe en orienté objet, comparé au temps que cela met au bout de la 1000e fois que vous le faîtes.**

Le mimétisme est un excellent moyen d'apprendre et de progresser vite. Et plus la personne que vous mimez est doué, plus vous allez devenir vous-même talentueux. 

De nouveau langages, de nouvelles librairies apparaissent chaque jour. Tous avec un seul et même but : répondre à un problème de développeurs ! 

Prenez le temps de tester ces outils, prenez des notes, créez des repo ou des gist, cela vous aidera probablement un jour ! Ou du moins, vous permettra de savoir à quoi sert cet outil et quelle problématique cela règle.

Lorsque vous devez mettre en place une solution, votre choix sera toujours de meilleurs qualité si vous êtes conscient des différents outils à votre disposition pour y arriver, car vous saurez pourquoi passer par tel chemin et pas l'autre.

### 5 - La magie des todo list

J'imagine que tout le monde aujourd'hui sait ce qu'est une todo list, maintenant comment le faire efficacement ?

**Chacun des objectifs de votre todolist doit être réalisable en un jour.**

C'est pourquoi, il faut toujours découper votre objectif en séquences. 
Et cela fait totalement sens, de la même manière que pour construire la muraille de Chine, on n'aurait jamais fait une tâche :

- Construire la muraille

...mais plutôt un objectif découpé en centaines de mètres au quotidien.

De même pour faire décoller un avion, on ne ferait jamais : 

- Entrer dans l'avion
- Faire décoller l'avion

Cela demande réellement un travail qui relève de la conception, que de savoir observer chacune des étapes nécessaires pour réaliser un objectif. Et s’entraîner à faire cela, vous fera progresser sur les points suivants : 

- La conception (avoir la vision du chemin vers l'objectif)
- Pouvoir estimer plus facilement le temps moyen pour réaliser une solution (calculer la distance vers l'objectif)
- Etre motivé (car chaque jour, on voit la progression et l'objectif se rapproche)
- Savoir expliquer (car on sait où l'on se positionne par rapport à l'objectif)

Nous continuerons cette exercice dans un prochain article où l'on parlera des tests unitaires et d'autres techniques pour améliorer notre compétence.

large_james-harrison-vpOeXr5wmR4-unsplash.jpg

medium_james-harrison-vpOeXr5wmR4-unsplash.jpg

small_james-harrison-vpOeXr5wmR4-unsplash.jpg

thumbnail_james-harrison-vpOeXr5wmR4-unsplash.jpg

james-harrison-vpOeXr5wmR4-unsplash.jpg

Comment devenir un meilleur développeur ? J'ai consacré beaucoup de temps dans ma vie à mon apprentissage. J'y toujours passe le plus clair de mon temps et voici ce que j'ai appris...

Mes conseils de développeur partie 1

## Une meilleure association Strapi Next.js

Lorsque vous rédigez vos articles avec Strapi, un input de type RichText se contentera de générer du texte au format **Markdown**. Pour pouvoir l'afficher avec la mise en forme, côté Next.js, nous allons utiliser un composant **React** : **React-Markdown**.

### A quoi sert cette librairie ? 

Elle remplace le Markdown généré par Strapi en composants HTML plus traditionnel. Des <H1>, <H2>, <H3>, etc. pour les titres, des <A> pour les liens, des <UL> pour les listes...

Cette librairie est personnalisable à souhait. On peut remplacer pour chaque élément HTML rendu par un composant custom et [la documentation](https://remarkjs.github.io/react-markdown/) nous montre comment nous y prendre : 

```tsx
import React from 'react'
import ReactDOM from 'react-dom'
import ReactMarkdown from 'react-markdown'
import MyFancyRule from './components/my-fancy-rule.js'

ReactDOM.render(
  <ReactMarkdown
    components={{
      // Use h2s instead of h1s
      h1: 'h2',
      // Use a component instead of hrs
      hr: ({node, ...props}) => <MyFancyRule {...props} />
    }}
  >
    # Your markdown here
  </ReactMarkdown>,
  document.querySelector('#content')
)
```

En **JSX** cela ne pose aucun problème, mais en **TSX** c'est une autre pair de manches...

### Comment se fait la surcharge de React-Markdown

On passe un objet à la propriété components, et chaque clé de cet objet représente un composant.
Le problème, c'est que le renderer est une fonction et cela pose pas mal de problème pour pouvoir typer ces éléments.

Voici comment j'ai procédé :

Je commence par créer mon composant **MarkdownLink** qui retourne un **JSX.Element** basique : 

```tsx
import * as React from 'react'

type MarkdownLinkProps = {
  href: string
  children: React.ReactNode
}

const MarkdownLink = ({ href, children }: MarkdownLinkProps) => {
  return (
    <a href={href} target="_blank" rel="noreferrer">
      {children}
    </a>
  )
}

export default MarkdownLink
```

Puis au moment du render de **React-Markdown** :

```jsx
<ReactMarkdown
    components={{
        a: ({ node, children }) => {
           return (
               <MarkdownLink href={(node.properties?.href as string) ?? ''}>
                  {children[0]}
               </MarkdownLink>
            )
        },
    }}
   >
   {post.attributes.content}
</ReactMarkdown>
```

Et voilà, notre composant remplace désormais la balise <a></a> standard généré par React-Markdown. 😉

large_sigmund-59yRYIHWtzY-unsplash.jpg

medium_sigmund-59yRYIHWtzY-unsplash.jpg

small_sigmund-59yRYIHWtzY-unsplash.jpg

thumbnail_sigmund-59yRYIHWtzY-unsplash.jpg

sigmund-59yRYIHWtzY-unsplash.jpg

React-Markdown est une librairie d'interprétation de contenu markdown qui permet de générer automatiquement le code HTML. Cependant, il génère des balises standards, sans classes et les affiche. Si vous voulez personnaliser tout ça, il faudra créer votre CSS en fonction de l'élément parent.
Nous allons voir comment créer nos propres renderer pour les composants HTML avec react-markdown en typescript.

Personnalisation de React-Markdown en Typescript

## Optimiser son référencement Strapi

La SEO est un incontournable pour obtenir de la visibilité sur internet. Les CMS tels que Wordpress, Joomla etc sont reconnus pour être très efficace pour leur compatibilité avec les moteurs de recherches.

**Cependant, si l'on devait partir de 0 et tout faire, comment vous y prendriez vous ?**

Vaste question à laquelle il y a plusieurs réponses possibles.

### Générer un sitemap.xml dynamiquement avec Next.js

[La documentation de Next.js](https://nextjs.org/learn/seo/introduction-to-seo) nous donne beaucoup d'informations sur le sujet et même [des exemples](https://nextjs.org/learn/seo/crawling-and-indexing/xml-sitemaps).

Un des fichiers clé de la SEO, le fichier **sitemap.xml** doit impérativement être accessible pour donner aux robots la liste des liens disponibles sur votre site, autrement dit, une sorte d'état des lieux...

Dans leur exemple, Next.js propose de générer dynamiquement ce fichier en créant une page **sitemap.xml.js**

```jsx
//pages/sitemap.xml.js
const EXTERNAL_DATA_URL = 'https://jsonplaceholder.typicode.com/posts';

function generateSiteMap(posts) {
  return `<?xml version="1.0" encoding="UTF-8"?>
   <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
     
     <url>
       <loc>https://jsonplaceholder.typicode.com</loc>
     </url>
     <url>
       <loc>https://jsonplaceholder.typicode.com/guide</loc>
     </url>
     ${posts
       .map(({ id }) => {
         return `
       <url>
           <loc>${`${EXTERNAL_DATA_URL}/${id}`}</loc>
       </url>
     `;
       })
       .join('')}
   </urlset>
 `;
}

function SiteMap() {
  // getServerSideProps will do the heavy lifting
}

export async function getServerSideProps({ res }) {
  // We make an API call to gather the URLs for our site
  const request = await fetch(EXTERNAL_DATA_URL);
  const posts = await request.json();

  // We generate the XML sitemap with the posts data
  const sitemap = generateSiteMap(posts);

  res.setHeader('Content-Type', 'text/xml');
  // we send the XML to the browser
  res.write(sitemap);
  res.end();

  return {
    props: {},
  };
}

export default SiteMap;
```

Avec le temps, en fonction du nombre d'articles sur votre site, cette approche pourrait être problématique à cause des délais de réponse pour générer dynamiquement cette page.

### Générer un sitemap.xml static avec Strapi

J'ai opté pour une approche de pré-construction de ce fichier qui sera rendu dans le dossier **/public/**

![seo-optimisation-strapi-sitemap ><](https://bo.dev-freelance.fr/uploads/sitemap_job_drawio_b5c960abad.png)

Afin de générer ce fichier, j'ai créé un worker qui fait ce travail de génération en amont, pour réduire au maximum les temps d'accès à cette url. Ce même worker pourra me servir dans le futur pour d'autres tâches, donc la solution est évolutive.

Le worker va lire les clés **WORKER:<jobName>** dans Redis, créés via lifecycle hook côté Strapi.

Vous remarquerez que je n'ai pas opté pour un pub/sub Redis, mais c'est un choix, cela aurait très bien pu se faire. Je l'ai déployé sur une solution en 2019 chez Webedia et c'est quelque chose de relativement stable, bien que pour du pub/sub, je préfère me tourner vers des outils comme RabbitMQ qui est beaucoup plus fiable. Dans mon cas, il s'agit d'une solution assez petite, c'est pourquoi j'ai préféré faire simple.

large_solen-feyissa-UWVJaDvXW_c-unsplash.jpg

medium_solen-feyissa-UWVJaDvXW_c-unsplash.jpg

small_solen-feyissa-UWVJaDvXW_c-unsplash.jpg

thumbnail_solen-feyissa-UWVJaDvXW_c-unsplash.jpg

solen-feyissa-UWVJaDvXW_c-unsplash.jpg

Après avoir conçu mon blog en Next.js et Strapi, j'ai du travailler sur la partie SEO afin de donner un peu de visibilité à mon site. Je vous explique comment je m'y suis pris.

Comment j'ai géré la SEO avec Next et Strapi

## Utiliser les lifecycle de Strapi.js 

Dernièrement je vous disais j'ai migré le blog depuis un projet custom **Node.js** **Express** & **Handlebars** vers un **Next.js** + **Strapi TS-beta**, et je ne regrette pas du tout. Cela m'a permis d'accélérer le processus développement au maximum. Au lieu de partir de 0 et devoir créer chaque brique, je suis parti de Strapi qui faisait tout le travaille de persistence et les routes API pour moi. J'estime que j'ai gagné 40% à 50% du temps de développement en procédant de la sorte.

### Mise en place du caching avec Strapi

J'ai continué à améliorer cet outil avec une gestion de cache Redis qui permet de charger les données beaucoup plus rapidement du back au front. 

Pour vous rafraîchir la mémoire je vous mets le lien de ma vidéo sur le caching [ici](https://youtu.be/RLzHGZXl2C0).

J'ai mis en place des clés de caches en me basant sur les endpoints. En n'oubliant pas d'ajouter un pattern commun afin de pouvoir effectuer des actions groupés sur les clés de cache.

Lors de chaque Lecture, je vérifie d'abord l'existence des données dans le cache, et si Redis n'a pas de données, on va écrire le cache sans TTL. Etant donné que nous accédons à une seule et unique base dont le seul accès en écriture est Strapi, on respecte la règle qui nous permet de contrôler notre cycle de vie du cache. 

En lecture : 
![redis-cache-optimisation-strapi ><](https://bo.dev-freelance.fr/uploads/cache_drawio_37eca56d42.png)

On récupère les données depuis le cache ou on écrit le cache sans limite de durée.

En écriture : 
![redis-cache-flow-strapi ><](https://bo.dev-freelance.fr/uploads/cache_write_drawio_34863e3ee8.png)

On en profite pour flusher totalement le cache via un pattern afin de récupérer de nouveau les données à jour. Autrement dit, je suis en mesure de garder le cache jusqu'à ce qu'un article soit modifié, supprimé ou qu'un nouvel article soit créé.

Cette simple optimisation me permet de charger mon contenu très rapidement, et éviter de flooder mon serveur Strapi en cas de requête répétée. 

large_luan-gjokaj-y4_xZ3cs96w-unsplash.jpg

medium_luan-gjokaj-y4_xZ3cs96w-unsplash.jpg

small_luan-gjokaj-y4_xZ3cs96w-unsplash.jpg

thumbnail_luan-gjokaj-y4_xZ3cs96w-unsplash.jpg

luan-gjokaj-y4_xZ3cs96w-unsplash.jpg

J'ai accéléré mon site avec du cache Redis, en me servant de strapi comme CMS Headless. Je vous explique tout ici.

Comment j'ai optimisé Strapi pour mon blog

## Programmer à deux : le Peer-Programming

Vous est -il déjà arrivé d'être complètement bloqué sur quelque chose, de passer des heures, voire des jours pour débloquer la situation alors que cela aurait très bien pu se faire en une vingtaine de minutes si vous aviez une information clé ?

Cela arrive à tout le monde, et nous réagissons très différemment face à cette situation. Certains se renferment sur eux même et cherchent la solution jusqu'à la trouver. D'autres n'hésitent pas à faire des signes lorsqu'ils sont bloqués. 

Cela demande parfois un peu de courage de dire que l'on n'arrive pas à comprendre ou à faire quelque chose, or, le Peer Coding ou encore le Peer Programming peut nous permettre d'avancer beaucoup plus vite.

### La résolution de problèmes, c'est notre quotidien

On le sait tous, le développement est un outil, il sert à matérialiser une idée, à répondre à un problème, à répondre à un besoin. Or, il est prouvé que la résolution de problème occupe au minimum 20% à 30% de notre temps de développement.

Avec le temps, les outils tels que les Tests Unitaires (TU) ou encore les langages fortement typés servent à réduire ce temps d'intervention. 

Il est tout de même bien mieux de faire du préventif, c'est à dire anticiper en amont les dysfonctionnements, que faire du curatif, c'est à dire faire le pompier et éteindre le feu, une fois que ça brûle déjà.

La résolution, où l'anticipation de problème devient de ce fait obligatoirement présent dans nos journées types de développeur. Parfois même, lorsque l'organisation est très mauvaise, elle occupe plus de la moitié du temps passé à travailler.

J'espère que vous réalisez que plus de 50% de votre temps, passé à fixer des bugs et gérer des problèmes non anticipés, c'est un signal d'alarme grave. Il faut revoir les méthodologies, les outils, l'organisation du projet pour faire plus de "prédictions" sur les scénarios... 

Bien que la résolution de problème est un passage obligatoire de notre journée voire nos semaines de développement. Je constate que le Peer Coding dans ces moments là est un outil adapté à ces situations.

### Qu'est-ce que le Peer Coding

Le Peer Coding, signifie travailler en équipe avec un collègue. Et contrairement à ce que l'on peut penser, cela ne retire pas une capacité de production du projet, car comme expliqué plus haut, la résolution de problème occupe déjà du temps quoique l'on fasse. Tout projet connait forcément des bugs, il s'agit alors de s'organiser pour les anticiper, ou les résoudre plus rapidement.

**Le Peer Programming, c'est un accélérateur de résolution de problèmes**

Cela permet plusieurs choses : 

- Réfléchir selon différentes perspectives (et très souvent cela permet une observation jusqu'alors mise de côté par le développeur)

- 2 cerveaux valent mieux qu'un, donc cela double presque le nombre de solutions ou propositions envisageables

- Cela permet de renforcer le travail d'équipe, c'est à dire, partager sur un point précis les conventions sur lesquels on s'est mis d'accord pour collaborer

- Monter en compétence, si un des développeur est plus expérimenté

Il est important de gagner en expérience collectivement. Cela signifie que chacun des membres de l'équipe, face à une même problématique connait désormais le chemin pour le résoudre. Aussi, cela permet de lisser le niveau moyen de l'équipe et de pouvoir plus facilement absorber le turnover.

**Retour à l'essentiel**

Lorsque l'on résout des problèmes, ce n'est pas par envie, par passion ou parce que c'est fun, mais surtout parce que c'est vital pour le projet. On le fait parce qu'on doit le faire. Cependant, il faut tout de même reconnaître que cela apporte, en définitive, moins de valeur pour le projet final, même s'il permet d'augmenter les connaissances techniques de l'équipe.

Il convient donc d'user de tous les moyens à notre portée pour mettre un terme au problème rencontré. Le Peer Coding qui est un outil permettant d'accélérer la résolution de problèmes, ne vas peut être pas réduire le nombre de problèmes rencontrés pendant le temps de travail, mais accélérer la résolution afin de pouvoir se remettre à faire du code productif, soit l'implémentation de nouvelles features.

### Quand le Peer Programming sert à boucler des tâches pointues

Lorsque l'on travaille sur des features techniques très complexes, il est préférable de réfléchir à plusieurs afin de ne rien laisser au hasard. La conception se fait alors en équipe, et il n'est pas rare que les premières implémentations aussi. 

Créer un nouveau module en équipe se fait couramment, d'autant plus que cela permet de partager le même niveau d'information avec tout le monde. 

Ce procédé accélère même souvent la sortie de ce nouveau module car il est stimulé par une poussée collective.

### Les outils de Peer Programming

**Pour faire du Peer Programming, faut aussi des outils.**

Contrairement aux outils de versionning tel que git etc qui permettent déjà de travailler en collaboration, le Peer Coding, c'est le fait de travailler simultanément sur une tâche avec un collègue. Et pour le faire efficacement, il faut impérativement des outils.

Lorsque l'on travaille en présentiel, cela peut très bien se faire dans un bureau avec un crayon et une feuille de papier. Mais depuis le COVID et la standardisation du télétravail, pour faire du Peer Coding, il faut des outils de communication performants.

Pour ma part, j'ai choisi d'utiliser [Discord](https://discord.com/) car il permet de faire tout ce dont on a besoin :

- La communication vocale

- La communication vidéo (Webcam ou Partage d'écran)

- Un chat écrit pour s'échanger du code source

J'ajoute à cela d'autres outils qui permettent de faire des dessins et schéma : 

- [Excalidraw](https://excalidraw.com/) pour dessiner

- [Draw.io](https://app.diagrams.net/) pour faire des schéma

**Parfois un schéma vaut 15 minutes d'explications**

Il est beaucoup plus simple de pouvoir visualiser un schéma notamment pour traiter les états d'un programme, les parcours possibles, les embranchements, que de lister uniquement les cas envisageables. 

En conclusion, le Peer Coding est un outil super pour faire progresser ses équipes. Il est bien loin le temps où on te disait "Surtout ne copiez pas sur votre voisin", lorsque l'on est une équpe de développeurs, rien n'est plus faux. 

Faire du Peer Programming vous aidera à résoudre plus rapidement les problèmes et partagera immédiatement l'information entre les développeurs. 

Cependant, pour pouvoir le faire efficacement, il faut des outils adaptés. J'ai essayé pendant longtemps avec Slack, mais comparé à Discord, les appels vidéos font parties de la formule payante. Pour Microsoft Teams, il fait quasiment tout, si ce n'est qu'il n'y a qu'un présentateur à la fois, alors que sur Discord, on partage tous nos écrans simultanément et cela permet un retour d'informations immédiat de la part de chacun.


large_628a3afa2808c86687728726_be727063db.jpeg

medium_628a3afa2808c86687728726_be727063db.jpeg

small_628a3afa2808c86687728726_be727063db.jpeg

thumbnail_628a3afa2808c86687728726_be727063db.jpeg

628a3afa2808c86687728726_be727063db.jpeg

Comment utiliser le Peer Programming comme un levier lors de la résolution de problèmes ? Si une équipe s'en sert efficacement, elle peut améliorer considérablement ses rendements.

Les bénéfices du peer-coding

## De Javascript à Typescript

On m'en avait parlé à l'époque et j'avais beau l'avoir testé, j'étais sceptique. Mais je le confirme, typescript change la vie !

Enfin... Pas Typescript seul, mais Typescript couplé à plusieurs autres choses comme un linter et un prettier etc... là, ça change tout, mais pourquoi ?

**Typescript seul, ne fait pas de miracles**

Pensez à mettre en place un linter (pour ma part, eslint fait largement le café ☕️) et au moins une extension Prettier configuré.

### Un code uniforme

Il est difficile de travailler en équipe sans mettre en place des règles. Dans le code, cela peut être frustrant de voir 3 implémentations différentes de la même logique, etc. 

Mais on n'y peut rien, tout le monde ne pense pas de la même façon. Pour régler en partie ce problème les linters sont des outils assez pratiques. Mais au delà de la mise en forme, l'indentation, l'utilisation des double ou simples quote, les accolades, etc, il est difficile de vraiment travailler de manière très homogène en équipe. 

Typescript, ne fera, certes, pas de miracles ici, mais il a le mérite de rendre les choses tellement lisible que de mettre en place des règles d'implémentations et autres conventions peut être plus simple qu'avec du pur JS.

La codebase servant d'exemple pour comment faire les choses, permettra à tout nouveau développeur de se greffer et suivre les pratiques mises en place par l'équipe. 

### La vérification en amont

En général la mise en place de tests unitaires demande non seulement, de maintenir ce code en fonction de l'évolution des implémentations, mais en plus de penser à le lancer (ou l'automatiser). Le plus souvent ça se fait avant les commit si vous utilisez un outil comme husky, mais si vous avez des collègues un peu flemmards, les TU peuvent servir aussi de décoration...

Littéralement, j'ai déjà travaillé avec des gens qui ne les lançaient jamais, et c'est très désagréable car il faut vraiment mettre tous les tests à jour par lot de plusieurs features, tout en sachant que cela ne durera pas.

Avec Typescript, on n'est pas libre de ne plus faire de test, mais au moins, on peut faire une stratégie de test basé sur des features un peu critiques. En revanche, la compilation fera déjà un travail de vérification pour voir si le code est cohérent avec les déclarations. Cette vérification automatique élimine, la majorité des bugs qui nous passent sous le nez en temps normal. En tout cas je constate que le travail que je livre est beaucoup plus robuste qu'avant. Il est même pas rare qu'un bug qui paraisse venir de notre partie du code viennent d'une API ou d'un scénario non planifié.

Il y a désormais, une complémentarité avec les TUs. Les TUs permettent de vérifier des scénarios utilisateurs (à condition que ceux-ci soient connus), en dehors dans l'utilisation au quotidien de vos librairies etc, il arrive parfois, lors des appels, de ne pas passer les bons paramètres.

Et c'est à ce moment que Typescript peut cadrer un peu l'utilisation de ces librairies car le typage va même jusqu'à prévoir le fait que les variables peuvent être absentes lors de l'exécution, et vous permettre d'anticiper (fallbacks, conditions, etc...).

**Typescript est complémentaire à vos tests unitaires, les utiliser ensemble c'est vous assurer un code solide et fiable**

### La productivité est-elle impactée ?

Au début, il faut l'avouer, ça demande un petit temps d'adaptation, pas forcément un an, mais bien quelques semaines, afin de pouvoir régler tous les problèmes communs, apprendre quelques subtilités comme le typage directement via les clés d'un objet (keyof typeof...), etc.

Le but est de vraiment jouer le jeu et non pas mettre des "any" partout pour aller plus vite. Honnêtement si vous passez à typescript pour utiliser "any", autant rester sur du JS 😕

Parfois, on est obligé de s'en servir, mais tant que l'on peut, il faut prendre le temps de déclarer des types. Le réel avantage de Typescript, c'est que lors des suggestions pour l'autocomplétion dans l'IDE, on voit directement ce qui est mandatory ou pas, le type de donnée attendu, et là, vous êtes bien content d'avoir pris du temps à la déclaration.

![typescript ><](https://bo.dev-freelance.fr/uploads/62782b89d4908592dedbefca_29b219d85d.gif)

### En conclusion

Typescript c'est vraiment une transformation du développement JS. Car il instaure une robustesse jusqu'alors difficile d'atteindre. De plus avec un peu de pratique, on va même plus vite qu'en pur JS grâce à l'autocomplétion détaillée et le typage attendu.

A titre d'exemple, j'ai refait from scratch, un composant React d'auto table qui m'avait mis 2 jours à l'époque en JS, après 6 mois de TS, sans m'inspirer du code existant (vraiment de 0), je l'ai refait en 2 heures.

Certes, les outils ont évolués aujourd'hui, avec les hooks, les providers/context, mais je le dis honnêtement, je pense passer pas moins d'une journée à le refaire si c'était du JS car je me serai forcément gouré quelque part dans l'implémentation, sans le savoir jusqu'à l'exécution.

large_6274ff94d4908592dedbefb6_5cd3218615.png

medium_6274ff94d4908592dedbefb6_5cd3218615.png

small_6274ff94d4908592dedbefb6_5cd3218615.png

thumbnail_6274ff94d4908592dedbefb6_5cd3218615.png

6274ff94d4908592dedbefb6_5cd3218615.png

Typescript permet de faire du code plus beau, plus lisible, plus robuste, et ce n'est pas forcément plus lent à produire !

Typescript change la vie

## Les bases de données évoluent chaque jour

**Historique**

Inventés dans les années 1960, les bases de données ne datent pas d'hier.

Initialement, l'informations était séparée en deux niveaux hiérarchique : les informations identiques sur plusieurs enregistrements et un niveau étendu pour une hiérarchie en arbre.

Au tout début, nous avons commencé le stockage d'informations sous forme de fichiers pour tendre vers un model relationnel. Cela s'explique par la densité des informations à relier entre elles, le modèle sql qui permettait l'indexation et l'optimisation de performance, mais surtout appuyé par le fait que la vitesse de transfert disque -> mémoire était plafonné à des débits assez lent.

**Quid d'une base documents aujourd'hui**

L'avènement des SSD, permettant des débit d'entrée/sortie énormes, la baisse des coûts de mémoire RAM et l'augmentation des débits de BUS mémoire permet aisément de repasser sur des modèles documents sans avoir de perte significative de performances jusqu'à un certain volume de donnée.

**Une technologie controversée**

Les frustrés des bases documents sont souvent des gens qui l'ont connu il y a très longtemps et sont facinés par le passage au SQL qui a été une évolution majeure à cette époque. Soit, il s'agit d'un public qui a fait le choix d'une base document pour de mauvaises raisons. Mais dans tous les cas, il n'y a aucune base mieux que l'autre dans l'absolu ! Tout dépend de ce que vous souhaitez faire.

### Pourquoi faire le choix d'une base documents ?

Depuis que l'information vaut son pesant d'or, il convient de stocker tout ce qui pourrait de près ou de loin se monnayer. C'est une triste réalité contre laquelle la CNIL mène un combat sans relache pour protéger les consommateurs. Cependant, imaginez un instant travailler avec une base sql, lorsque chaque information peu devenir importante dans le futur, il convient de stocker tout ce que l'on peut, à partir du moment ou nous avons connaissance de ce besoin. C'est le principe même du big data, c'est à dire tout stocker afin d'avoir une base de connaissance dans laquelle piocher à tout moment.

Par exemple, les réseaux sociaux n'existaient pas il y a 20 ans, aujourd'hui, c'est une information importante pour cibler un consommateur. Nous pouvons donc stocker l'email associé à chaque réseau social dans notre base de données. Mais à la vitesse à laquelle les réseaux se développent, il y aura toujours un nouveau réseau inconnu dans un an. Entre les facebook, puis instagram, puis snapchat, puis tiktok... on le voit bien, c'est sans fin !

Si l'on travaillait en base SQL, il faudra à chaque fois, faire une migration de structure et ajouter la colonne... En base document, niet ! On ajoute ce qu'on veut ajouter à la volée, et c'est parti.

MongoDB pour ne citer que lui, est un parfait exemple de base qui peut grossir à la fois par le nombre d'items sauvegardé mais aussi par item en lui même. Et cela nous donne énormément de souplesse pour faire évoluer les modèles de données.

**SQL a dû s'adapter**

Face aux transformations du besoin de stockage d'information, SQL a dû aussi s'adapter au format document en intégrant la gestion du JSON (format de donnée imbriqué). Ainsi, il est possible d'ajouter la souplesse du modèle document dans une base SQL. Mais vous imaginez bien que cela n'est pas sans contrepartie. En atteignant une taille critique en volume Octet, vous atteindrez un niveau de ralentissement dû à la quantité des informations à parser (car le champs JSON est aussi indexé pour la recherche).

**Mongo aussi évolue**

Le bémol pour les bases fichiers c'est qu'au départ le stockage d'items ne permettait pas de modèle relationnel. Le lien entre deux éléments se faisait :

- Soit, en imbriquant directement l'intégralité d'un élément dans un autre (limité à 100 niveau d'imbrications). Ce qui gonfle la taille de l'item, qui reste limité à 16mo (BSON) par défaut sur une base MongoDB, donc limite les possibilités.

- Soit en stockant dans un tableau l'ID unique du document à imbriquer, mais impose l'exécution successive de requêtes afin de récupérer chaque élément.

Aujourd'hui, après plusieurs optimisations, Mongo a accéléré les recherches avec aggregation. Cela permet de processer les résultats côté base de données, afin d'affiner la recherche, pour retirer la charge du serveur de traitement (API, Framework, etc...).

A quel moment passer de l'un à l'autre ?
Une base document, que ce soit Mongo, Neo ou encore DynamoDB, est utile lorsque l'on souhaite stocker de la donnée brute à exploiter si besoin. Si on me demandait de faire un wikipédia, je ferai un mix de base document et moteur de recherche (Elaticsearch) car, sur chaque item, on pourra ajouter des clés spécifiques à l'item :

Par exemple :

- pour les animaux et les plantes : l'appellation latine
- pour les plats : un tableau d'ingrédients
- pour la mode (vêtement, chaussures, parfum) : un tableau des dates d'édition, ré-édition


Chaque élément ayant ses spécificités différentes d'un autre élément qui n'est pas de la même "famille".

Je me vois mal faire cela en SQL car on sera rapidement limité par la structure qui se veut commune entre les éléments.

Selon moi, SQL est un choix idéal pour une base qui peut être utilisé pour du calcul ou un maillage relationnel complexe entre les éléments, par exemple :

- des lignes comptables
- un historique d'achat
- un réseau social


Lorsque nous voulons récupérer les amis des amis de mes contacts pour les mettres en suggestion (même si cela est précalculé via une tâche autonome...) SQL est idéal pour le faire. Idem pour faire un calcul côté base de données, des dépenses entre deux périodes sur une table de transaction.

### Un système de stockage de données idéal

Comme on peut le voir, les deux modèles ont leur forces et leur faiblesses. Je pense qu'idéalement, il faudrait mixer les deux afin de tirer le meilleur de chacun. Je reste persuadé qu'il y a toujours un cas ou l'un est meilleur que l'autre.

**Une base document** : pour stocker le plus d'information possible

**Une base SQL** : pour du calcul ou des relations complexes

Aujourd'hui, nous sommes malheureusement confrontés à d'autres problématiques au niveau de l'infrastructure. Faire le choix de plusieurs technologies, c'est aussi, maintenir les deux, les faire évoluer pour éviter les exploits et toujours maintenir une cohérences entre les échanges inter-bases. Cela est très complexe et demande un minimum de personnes pour y parvenir. Je pense que, dès qu'une équipe est suffisamment grosse pour gérer les deux, il ne faut pas hésiter à le faire. En revanche, à taille humaine, le travail est colossal et promet une lourde charge quotidienne rien qu'au maintient de l'infrastructure.


medium_606ebcca7cbf7acafb056205_7de4588bcd.png

small_606ebcca7cbf7acafb056205_7de4588bcd.png

thumbnail_606ebcca7cbf7acafb056205_7de4588bcd.png

606ebcca7cbf7acafb056205_7de4588bcd.png

Lorsque l'on commence un projet, il convient de faire les bons choix quant au stockage des données. Pour cela, nous avons des outils adaptés à chaque besoin. Utiliseriez vous une base relationnelle ou une base documents ? Réponse dans cet article...

Découvrez tous nos articles de la catégorie Dev - page 3 sur 3