03/14/2007Critique de livre: The Tipping Point
En achetant ce livre, j'avais peur qu'il soit trop emprunt de culture Américaine pour que je puisse comprendre précisément ce que Malcom Gladwell décrit, et le retrouver dans un contexte culturel Européen. Finalement, mise à part quelques références américano-américaines, ce livre reste tout à fait limpide et se lit comme un livre de la bibliothèque verte ;). Le Tipping Point c'est ce moment particulier, quantique, qui fait basculer une mode, une façon de penser ou encore une idée, du quasi-anonymat vers un phénomène de société. Gladwell, dans un style journalistique très agréable décortique ce phénomène par le biais de nombreux exemples pour proposer un modèle basé sur l'épidémiologie. Ce livre s'addresse à toutes les personnes désireuses de mieux propager leurs idées, ou tout simplement curieuses de mieux comprendre pourquoi le badge revient à la mode ! Ce qu'il en ressort est une meilleure compréhension des phénomènes de masse, et, que vous soyez dans le marketing, le développement ou tout autre activité "informatisée" un meilleur usage de tous les outils actuels (web 2.0) axés sur le social tagging (flickr, digg, etc.). Les cinq lois de la programmation évolutiveEcrire des programmes qui fonctionnent est à la portée de chacun. Surtout en Python ;). La difficulté principale est de réussir à écrire des programmes qui évoluent dans le bon sens, et éviter l'effet spaghetti*. Les cinq lois énoncées ci-dessous synthétisent les bonnes pratiques à adopter pour favoriser une croissance contrôlée des programmes.
Les bon noms font les bons amisChoisissez avec soin le nom de vos variables, modules, fonctions, classes et méthodes. Chacun d'entre eux doit être explicite et indiquer clairement son objectif. Quelques pistes:
Soigne ta signatureLes arguments de chaque méthode ou fonction doivent également être précis. Eviter les signatures magiques avec *args et autres **kw, qui rendent les interdépendances floues. Quelques cas particuliers:
Ecourter les conversationsLorsqu'un élément (classe, module, etc.) est utilisé dans du code, si plusieurs appels successifs sont effectués pour l'utiliser (sans ou avec peu d'interactions), ses APIs doivent être modifiées pour écourter les échanges au maximum. Le module __init__ d'un paquet est un bon outil pour synthétiser son utilisation. Exemple de conversation trop bavarde: from Paquet import misfit from Paquet import cat params = misfit.makeParams() truc = cat.generateTruc(params) bidule = cat.pondBiduleAvecTruc(truc) Les apis du Paquet et de ses modules peuvent être améliorés pour obtenir: from Paquet import pondBidule bidule = pondBidule() Le module __init__ joue alors le rôle d'intérmédiaire entre cat et misfit Ne jamais radoterL'ennemi du code est le doublon. Dès que deux blocs présentent des similitudes, il est nécessaire de les réunir. Diviser pour mieux régnerune fonction ne devrait jamais dépasser un écran. Il est nécessaire de la subdiviser le cas écheant. Il en va de même pour les classes, modules, et paquets: il ne faut pas avoir peur de diviser son paquet en une multitudes de petits paquets. *spaghetticus effectus: transformation d'un programme en un bloc monolithique ou chaque élément ne peut plus évoluer indépendamment des autres. Porte aussi le nom de pieuvre à 6 têtes dans la mythologie geek.
|
A propos
|