Programmation on CTOMultiplier

Guide pour un développement robuste avec l'IA : Cursor et Github Copilot

Wed, 14 May 2025 15:48:12 +0000

Les assistants de code IA se sont récemment répandus grâce à la puissance qu’ils offrent pour accélérer le développement logiciel. Cependant, apprendre à les utiliser n’est pas aussi simple qu’écrire un simple prompt. La courbe d’apprentissage pour exploiter pleinement ce qu’ils offrent n’est pas aussi faible qu’on pourrait le penser. Si nous la sous-estimons, nous risquons a) de produire du code de mauvaise qualité avec des erreurs et des failles de sécurité ou b) de faire un usage limité des capacités et d’obtenir moins de bénéfices que ceux disponibles.

Savez-vous ce qu'est le DPE ?

Wed, 27 Sep 2023 07:23:39 +0000

DPE signifie Developer Productivity Engineering et c’est le nom d’une nouvelle discipline qui vise \u00e0 am\u00e9liorer la productivit\u00e9 des d\u00e9veloppeurs \u00e0 travers l’automatisation, l’observabilit\u00e9 et l’am\u00e9lioration des outils.

Le travail d’un d\u00e9veloppeur lorsqu’il programme comporte trois phases : code -> build -> test. Le d\u00e9veloppeur r\u00e9p\u00e8te cette s\u00e9quence des dizaines voire des centaines de fois par jour. Et dans de nombreux cas, les phases de build et de test peuvent prendre de l’ordre de plusieurs minutes. Par exemple : si le build d’une application prend 5 minutes et que le d\u00e9veloppeur effectue 10 builds par jour, cela fait 50 minutes d’attente par jour pour le d\u00e9veloppeur. De m\u00eame, la phase de test peut augmenter le temps d’attente du d\u00e9veloppeur. Multipliez cela par le nombre de d\u00e9veloppeurs dans une entreprise et le co\u00fbt est significatif.

Guide pour faire des revues de code dans votre équipe

Tue, 25 Jul 2023 15:42:32 +0000

Les revues de code sont une pratique qui s’est généralisée ces dernières années, où un ou plusieurs développeurs examinent le nouveau code implémenté par un autre collègue, dans le but de détecter des problèmes de qualité du code, des bugs, des vulnérabilités, de mauvaises pratiques, etc. Cela permet de raccourcir les boucles de rétroaction, ce qui est très bénéfique car plus un problème est découvert tard, plus le coût de sa correction est élevé et plus l’impact potentiel sur l’activité est important.

Quand les abstractions fuient

Thu, 15 Jun 2023 18:47:25 +0000

Dans le monde du logiciel, nous utilisons constamment des abstractions pour faciliter notre travail, car elles nous abstraient d’autres domaines et réduisent considérablement la complexité à laquelle nous devons faire face. Un exemple d’abstraction est les ORM. Un ORM nous permet d’abstraire l’application de la base de données utilisée. Au lieu de devoir écrire des requêtes (spécifiques au moteur de base de données) pour accéder aux données, l’ORM nous permet d’utiliser le langage de programmation que nous utilisons pour coder l’application, également pour accéder aux données. Quiconque a utilisé des ORM sait que dans de nombreux cas, l’abstraction fonctionne bien et apporte beaucoup de valeur, mais lorsque l’application nous oblige à récupérer plusieurs entités liées, entre autres exemples, c’est là que nous commençons à voir les limitations. Dans ces cas, il est courant que les ORM ne génèrent pas toujours les requêtes optimales, ou qu’ils nous obligent à écrire un code excessivement complexe, si bien que parfois nous finissons par écrire des requêtes directement dans le langage de la base de données sous-jacente. Cela signifie mettre de côté l’abstraction pour ces cas.