Aujourd’hui, je vais vous présenter un des livres les plus intéressant que j’ai lu :
Libérez-vous de votre smartphone: Et reprenez votre vie en main
Il a été écrit par korben, du site du même nom. Le titre de ce livre m’a interpellé, même si il ne fait que 84 pages, son contenu est très pertinent. Il liste toutes les bonnes pratiques à suivre pour se libérer peu à peu de l’emprise de son téléphone portable.
Il est possible, pour chaque lecteur, de rajouter des éléments dans le livre, lié à sa propre expérience avec les téléphones portables. Il serai même intéressant de partager toutes ces expériences, pour voir les solutions qui pourraient en ressortir.
Petit livre issue de la collection La petite Bédéthèque des Savoirs, il traite de sujet donc on parle fréquemment en ce moment : fake news, rumeurs, etc…
Gérald Bronner nous explique dans ce livre plusieurs concepts expliquant pourquoi les fake news pullulent sur internet.
C’est une petite bande dessiné de 72 pages. Les personnages sont 2 adolescents, discutant des théories du complot et de pourquoi ils fonctionnent. C’est un livre intéressant à lire, même pour les adolescents.
Aujourd’hui, je voudrais présenter un petit livre assez simple, écrit par Mason Currey. Il s’intitule : Tics et tocs des grands génies : 100 rituels secrets à l’origine des plus belles créations.
Ce livre nous présente, en moins de 300 pages, les habitudes et les manies d’une centaine de célébrités (écrivains, scientifiques, compositeurs, …).
Ces célébrités ont tous des emplois du temps différents, mais ils font en sorte de rester routiniers. Si vous lisez facilement l’anglais, il est possible de lire des exemples de routines sur le blog Daily Routines.
Avez-vous déjà entendu cette expression ou quelque chose dans le genre ? Bien sûr que oui ! Chaque développeur et étudiant a déjà probablement entendu de tels commentaires. Pourquoi ? Et pourquoi réinventer la roue est-il si mal vu ?
Parce que, le plus souvent, le code existant est un code fonctionnel. Il a déjà été soumis à une sorte de contrôle de la qualité et à des tests rigoureux, et est utilisé avec succès. De plus, le temps et les efforts investis dans la réinvention sont peu susceptibles de porter leurs fruits, de même que l’utilisation d’un produit ou d’une base de code existante. Si vous avez la peine de réinventer la roue ? Pourquoi ? Quand ?
Peut-être avez-vous déjà vu des publications sur les modèles de développement de logiciels ou des livres sur la conception de logiciels. Ces livres peuvent être endormant, quelle que soit la qualité de l’information qu’ils contiennent. De la même manière que regarder un film sur la voile est très différent de naviguer, utiliser le code existant, c’est aussi concevoir son propre logiciel à partir de zéro, le tester, le casser, le réparer et l’améliorer en cours de route.
Réinventer la roue n’est pas simplement un exercice pour placer des constructions de code: il s’agit de savoir acquérir une connaissance intime du fonctionnement interne de divers composants existants. Savez-vous comment fonctionnent les gestionnaires de mémoire? Les pagination virtuelle ? Pourriez-vous les mettre en œuvre vous-même ? Qu’en est-il des listes à double liaison ? Les Classes de tableau dynamique ? Les clients ODBC ?
Pourriez-vous écrire une interface utilisateur graphique qui fonctionne comme une interface populaire que vous connaissez et aimez ? Pouvez-vous créer vos propres widgets de navigateur Web ? Savez-vous quand écrire un système multiplexé par rapport à un système multi-thread ? Comment choisir entre une base de données ou une base de données en mémoire ?
La plupart des développeurs n’ont simplement jamais créé ces types d’implémentations logicielles principales et ne possèdent donc pas une connaissance intime de leur fonctionnement. La conséquence est que tous ces types de logiciels sont considérés comme de mystérieuses boîtes noires qui fonctionnent.
Comprendre uniquement la surface de l’eau ne suffit pas pour révéler les dangers cachés. Ne pas en savoir plus sur le développement de logiciels limitera votre capacité à créer un travail stellaire.
Réinventer la roue et se tromper est plus utile que de la clouer du premier coup. Il y a des leçons tirées d’essais et d’erreurs qui ont une composante émotionnelle, ce que la lecture d’un livre technique ne peut à elle-seule livrer !
Il est essentiel d’apprendre des faits et de maîtriser les livres, mais pour devenir un bon programmeur, il faut autant acquérir de l’expérience que recueillir des faits. Réinventer la roue est aussi important pour l’éducation du développeur que pour l’haltérophilie, pour le body-builder.
Voici une nouvelle règle que je vous propose, tiré du livre 97 Things every programmer should know. Aujourd’hui, c’est Yuriy Zubarev qui nous parle de la maintenance du code.
Vous pouvez demander à 97 personnes ce que chaque programmeur doit savoir et faire et vous pouvez obtenir 97 réponses distinctes. Cela pourrait être à la fois accablant et intimidant. Tous les conseils sont bons, tous les principes sont fondés et toutes les histoires sont convaincantes, mais par où commencer ? Plus important encore, une fois que vous avez commencé, comment suivez-vous toutes les meilleures pratiques que vous avez apprises et comment en faites-vous une partie intégrante de votre pratique de programmation ?
Je pense que la réponse réside dans votre état d’esprit ou, plus clairement, dans votre attitude. Si vous ne vous souciez pas de vos collègues développeurs, des testeurs, des responsables des ventes et du marketing et des utilisateurs finaux, vous ne serez pas amené à employer un développement piloté par les tests ou à écrire des commentaires clairs dans votre code, par exemple.
Je pense qu’il existe un moyen simple d’ajuster votre attitude et d’être toujours motivé pour fournir des produits de la meilleure qualité: écrivez un code comme si vous deviez le supporter pour le reste de votre vie.
C’est tout. Si vous acceptez cette notion, il se passera beaucoup de choses merveilleuses. Si vous deviez accepter que l’un de vos employeurs précédents ou actuels ait le droit de vous appeler au milieu de la nuit pour vous demander d’expliquer les choix que vous avez faits lors de l’écriture de la méthode fooBar, vous deviendriez progressivement un programmeur expert. Vous voudriez naturellement proposer de meilleurs noms de variables et de méthodes. Vous éviteriez des blocs de code comprenant des centaines de lignes. Vous feriez de la veille, à chercher, apprendre et utiliser des modèles de conception.
Vous pouvez écrire des commentaires, tester votre code et refactoriser continuellement. Soutenir tout le code que vous avez écrit pour le reste de votre vie devrait également être une entreprise évolutive. Vous n’auriez donc d’autre choix que de devenir meilleur, plus intelligent et plus efficace.
Si vous y réfléchissez, le code que vous avez écrit il y a de nombreuses années influence toujours votre carrière, que cela vous plaise ou non. Vous laissez une trace de vos connaissances, de votre attitude, de votre ténacité, de votre professionnalisme, de votre engagement et de votre plaisir avec chaque méthode, classe et module que vous concevez et écrivez. Les gens vont se faire une opinion sur vous en fonction du code qu’ils voient. Si ces opinions sont constamment négatives, votre carrière vous rapportera moins que vous ne l’espériez. Prenez soin de votre carrière, de vos clients et de vos utilisateurs avec chaque ligne de code. Écrivez du code comme si vous deviez le prendre en charge pour le reste de votre vie.
