Je suis développeur web freelance et propose des formations à Symfony2 ! Contactez-moi pour en discuter.

J’ai récemment eu l’occasion de coacher des développeurs débutants. Ça a été l’occasion pour moi de faire le point sur des notions de base mal comprises, et peut-être l’occasion pour vous d’apprendre de choses !

Ma présence touchait à sa fin, et l’éventail des sujets qu’il restait à aborder est trop grand pour une formation. J’ai donc suggéré l’achat de quelques livres, que vous trouverez reproduite et étendue ici. En effet, dans une boite précédente, nous avions accès à une petite bibliothèque technique, grâce à laquelle j’ai appris plein de choses. J’ai profité de mon passage freelance pour garder l’habitude de m’acheter environ un livre technique tous les 1/2 mois. Si vous ne pouvez/souhaitez pas les acheter vous-même (certains coutent un bras), peut-être pourrez vous également demander à votre boss de faire l’achat de quelques titres ? Cela profitera à toute l’équipe.

Il n’y a pas que le travail dans la vie ! Souvent, les développeurs sont des passionnés. C’est pourquoi j’ai profité de cet article pour conseiller quelques titres qui m’ont bien amusé.

Vous trouverez donc des suggestions sur:

Bosser sur des applications web complexes

Designing Data Intensive Applications, Martin Kleppmann
https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321/

Si vous ne devez acheter qu’un bouquin pro, prenez celui-la (cette liste commence fort) !

Vous allez apprendre les grandes idées derrière les architectures web complexes solides et maintenables. On ne parle pas du comment configurer une BDD MySQL, mais d’à quelles problématiques on va faire face lorsque ça se complexifie: montées en charge, plus de serveurs, etc… et bien sûr comment les résoudre. Même si on est familier avec les notions de loadbalancing, de message queue, de cdn, que vous avez une vague idée de ce que veut dire NoSQL… vous apprendrez plein de choses sur le fonctionnement de vos outils (les structures de données utilisées dans les bases de données par ex) et allez structurer vos connaissances concernant les systèmes distribués (réplication, partitionnement de cluster, problématiques de consensus, etc).

Attention, vous n’aurez probablement pas besoin de tout ça au quotidien, au moins pour démarrer un projet et pendant un long moment ! Faire simple vous rendra de très grands services.

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

Livrer des applications en continu, c’est un élément clé de la qualité logicielle: la mettre en oeuvre va permettre de livrer plus souvent, d’avoir des retours plus fréquents des utilisateurs, et de détecter plus finement l’introduction de défauts dans l’application.
En contrepartie, cela demande pas mal d’ingénierie pour le faire de manière sereine sur des gros projets: il faut monitorer le statut de l’application, pouvoir identifier rapidement l’apparition de défauts, avoir des tests automatisés avec parfois plusieurs niveaux de granularité, valider la qualité du code qui va être déployé, avoir un système de build du projet, plusieurs environnemens sur lesquels déployer… pas mal d’étapes qui sont souvent manuelles, ou bien où l’on trouve des frictions.

Ce bouquin, c’est un bon moyen de comprendre comment s’articulent tous ces éléments. Il aborde tous les grands principes de l’intégration continue, de la gestion de projets aux outils de déploiements en passant par la gestion de configuration. Le but, c’est d’avoir toutes les cartes en main pour pouvoir mettre en place une stratégie de déploiement continu, en automatisant correctement tout ce qui doit l’être, et en sachant pourquoi on le fait.

Bosser sur du code legacy

Quand on arrive sur un vieux projet (souvent mal écrit), il y a deux grands problèmes:

  • se repérer, comprendre comment ça fonctionne
  • corriger les défauts fonctionnels tout en améliorant la qualité du code, et en s’assurant que l’on n’introduit pas de régressions

On a tous, à un moment donné, du faire ce genre de choses: corriger un vieux projet pourri. Autour de moi, j’ai souvent constaté une approche très primitive de ce genre de choses. Souvent, après avoir mal compris le bout de code à problèmes (souvent inscrit dans des objets/méthodes/domaines trop complexe pour être compris dans leur ensemble), on ajoute un peu de code autour du défaut pour le corriger, et s’il y a des régressions on espère que ce sera pour le suivant. Il y a pourtant des méthodes qui permettent d’appréhender les problèmes ci-dessus avec un peu plus de sérennité. Je vous conseille les deux livres suivants :

Working effectively with legacy code, Michael Feathers

Une belle boite à outils pour apprendre à travailler dans des vieux projets, avec beaucoup de code, souvent de mauvaise qualité, s’y repérer et arriver à changer des choses sans tout casser.

Refactoring, Martin Fowler

Le refactoring, c’est un procédé que tous les dévelopeurs mettent en oeuvre à mesure que leur compréhension du domaine évolue, ou bien que le projet grandit. On en parle déja chez Feathers, mais pour Fowler, c’est une idée clé de l’agilité: améliorer ou corriger du code mal fichu, de manière itérative, permet aussi bien de corriger du vieux code que d’améliorer rapidement du code nouveau. Une nouvelle édition est prévue pour fin 2018, avec des exemples en Javascript.

Apprendre à écrire du bon code

Quelques questions à se poser, avant de chercher à y répondre plus rigoureusement : c’est quoi du code de bonne qualité, qu’est ce qui le caractérise, et comment écrire de manière consistante du code qui respecte ces règles ?

J’ai du mal à vous conseiller des lectures papier. Vous avez peut-être déjà vu les titres qui suivent car ils sont populaires, mais pourtant leurs lectures ne m’ont pas satisfaites:

  • Code Complete propose plein de bons conseils, mais… un peu trop. Avec 750 pages je ne vois pas du tout comment faire un lecture efficace de ce livre. Si vous le lisez en entier vous n’en retiendrez rien. Si vous le lisez occasionnellement, penserez vous à lire un chapitre de temps en temps et à mettre en oeuvre ses conseils ? Ça n’a pas été mon cas.
  • The Clean Coder, c’est l’inverse. 250 pages, mais une fois la table des matières lue, vous n’apprendrez plus grand chose. C’est pourtant un des livres fondateur du mouvement des artisans développeurs (software craftsmanship). Il se concentre plus sur l’état d’esprit du « bon » développeur (avec, par ailleurs, des idées très arrêtées et parfois très discutables, par exemple sur le temps que vous devriez consacrer à votre veille) que sur le code en lui même.

Un bouquin qui m’a aidé à comprendre les idées derrière les implémentations de plusieurs framework web, c’est Patterns of Enterprise Application Architecture, de Martin Fowler. Une sorte de dictionnaire du développement d’entreprise, pour apprendre les structures qu’on trouve un peu partout, et surtout les différences entre des idées proches (ex: data mapper chez Doctrine, active record chez Eloquent). Une version basique du catalogue est diponible en ligne.

A part ça, n’hésitez pas à regarder de temps à autre comment sont structurées les librairies que vous utilisez fréquemment, et à vous tenir au courant des conventions récentes dans votre langage. Pour PHP, PHP : the right way en fait la synthèse par exemple.

Quelques bouquins pour étoffer votre culture technique

The Pragmatic Bookshelf a deux séries de livres que j’ai adoré. Bruce Tate a écrit Seven Languages in Seven Weeks puis, suite au succès de ce premier livre, il a écrit une suite, Seven More Languages in Seven Weeks.

Dans ces deux livres, il présente au total 14 langages de programmation. Il y a des points communs, mais chacun a des particularités ou s’articule autour d’un paradigme. Le premier se lance dans des langages connus, mais je suis certain que vous n’avez pas écrit du code dans tous ces langages :

  • Ruby
  • Io
  • Prolog
  • Scala
  • Erlang
  • Clojure
  • Haskell

L’idée c’est quand même de parler des concepts (paradigmes) derrière tous ces langages, plus que vous rendre opérationnel en quelques pages (mais les exercices vont vous apprendre à devenir autonomes, par ex en allant chercher des infos dans la documentation).

Le second livre s’aventure sur des langages moins connus, et continue à les utiliser pour parler de différents paradigmes (fonctionnels, prototypal, gestion d’échec, calcul scientifique, programmation logique, théorie des types):

  • Lua
  • Factor
  • Elm
  • Elixir
  • Julia
  • miniKanren
  • Idris

Seven Databases In Seven Weeks reprend cette logique d’explorer plusieurs technos pour en expliquer les idées clé, mais côté base de données. Je pensais m’ennuyer sur celles que je connaissais, mais le chapitre d’intro sur PostgreSQL (que j’ai utilisé dans plusieurs projet.) allait déjà au dela de mes connaissances. Au programme, du SQL, du NoSQL, des time series, des bases de données orienté graphe, des stores clé/valeur…:

  • PostgreSQL
  • Riak
  • HBase
  • MongoDB
  • CouchDB
  • Neo4J
  • Redis

Si vous aimez le style, il y a eu d’autres titres dans le même genre chez cet éditeur que je n’ai pas lus, comme Seven Concurrency Models in Seven Weeks ou Seven Web Frameworks in Seven Weeks.

Quelques bouquins pour le fun

Mazes for Programmers

J’ai su que j’allais lire ce livre après en avoir lu la quatrième de couverture: « Remember when programming was fun? »

Ici, rien de compliqué, pas d’objectif, on prend ce qu’on souhaite au milieu d’une multitude d’algorithmes pour la génération et le rendu de labyrinthes en 2 et 3 dimensions. Je n’ai pas réécrit tous les algorithmes, mais:

  • quand je l’ai fait et que le labyrinthe s’affiche correctement pour la première fois, on est vraiment, pleinement satisfait
  • simplement comprendre un algorithme qui parait complexe procure une grande satisfaction en soi.

Nature of code

Plein de techniques vaguement inspirées de la nature: moteur physique, fractales, systèmes de particules, etc. Très chouette.

Ce livre est disponible gratuitement en ligne (et honnêtement, j’ai pris la version papier pour soutenir l’auteur, mais la version web est plus pratique à lire. Elle contient d’ailleurs des animations qui ne rendent pas bien sur papier)

Raytracing in a Weekend

Peter Shirley a écrit 3 livres sur le raytracing, une technique de rendu graphique qui sert (en gros ! pas taper !) pour le rendu des images d’effets spéciaux et dans les films d’animation.

  • Raytracing in One Weekend
  • Raytracing: The Next Weekend
  • Raytracing: The Rest Of Your Life

Comme leurs noms l’indiquent, le but est d’apprendre progressivement, mais rapidement au début, à concevoir son propre moteur de rendu. C’est très ludique, ça se lit vit, on apprenl pleir de choses sur la 3D quand on est pas dans le domaine, et c’est un super projet pour apprendre en même temps un nouveau langage.

Shirley a récemment rendu open source son livre et les code des projets, vous pourrez les trouver sur Github ou sur Real-Time Rendering

Dans le même esprit, mais qui va beaucoup plus loin (j’ai vite été largué faute d’assiduité), le fantastique Physically-Based Rendering est également disponible en version web. Il peut vous occuper quelques années.

Je n’ai pas encore lu, mais on m’a vivement conseillé le titre de Fabien Sanglard Game Engine Black Book : Wolfenstein 3D. Au départ, Fabien a publié sur son site de longues revues de code de projets connus: Quake, Prince Of Persia, Doom 3, git et la liste continue. C’était déja hyper intéressant et on apprend plein de choses sur la structure et les astuces de projets qui ont marqué l’histoire, jetez-y un oeil ! Après plusieurs années de travail, il a publié le premier titre d’une série papier encore plus détaillée sur les moteurs 3D, en commençant par Wolfenstein 3D.

Quelques histoires de non fiction

Les titres qui suivent racontent des histoires réelles

  • Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon. Une enquête autour du ver Stuxnet, qui a servi a casser les centrifugeuses d’uranium Iranien afin de ralentir leur accès à l’arme nucléaire. C’est raconté autour de deux axes: le contenu absolument ahurissant du virus (qui contient des trésors d’ingéniosité et de complexité), et ce qui se passe « dans le monde réel » autour du développement du nucléaire irannien. On se croirait dans un polar !
  • Ghost in The Wires. Autre histoire dingue, la bio de la période hacker du célèbre Kevin Mitnick, avant qu’il ne se fasse arrêter pour de bon. On a du mal à tout croire (après tout, son expertise, c’est le mensonge), mais on se laisse quand même porter. Certaines techniques d’ingénierie sociale qu’il met en oeuvre pour ses hacks sont encore utilisées aujourd’hui.
  • Masters of Doom, l’histoire derrière le développement de Doom par Carmack et son équipe au début des années 90. Creativity, Inc raconte la même chose chez Pixar.

Il y aurait encore plein de titres à citer… mais voici de quoi vous occuper quelques temps. N’hésitez pas à me conseiller les votres !

Répondre

Unable to load the Are You a Human PlayThru™. Please contact the site owner to report the problem.