Partie II de III. Lire la partie I.
Mieux documenter et mieux coder
Quel sujet amusant. Heureusement, Garrett Dimon a agrémenté cette section d’humour et de quelques leçons durement apprises.
Évidemment, personne n’a envie de rédiger de la documentation, mais il faut le faire. À l’inverse, documenter pour le simple plaisir de documenter n’est pas une bonne chose non plus : cela peut souvent vous enfermer dans une façon de penser ou de fonctionner qui n’est peut-être même pas la bonne.
Essentiellement, la documentation doit communiquer quelque chose d’utile, peu importe le nombre de pages qu’elle occupe. Concevez pour les gens, pas pour des listes à puces.
Sinon, vous risquez « la paralysie par l’analyse » – Getting Real
Pour ce qui est du code en particulier, Dimon recommande de travailler le plus vite possible pour mettre la main à la pâte, puisque vous allez faire des erreurs de toute façon.
Il a néanmoins insisté sur la nécessité de remanier votre code après l’avoir écrit. Il appelle cela la « dette de code » : quand vous écrivez du code bâclé, vous allez en payer les intérêts tout au long du projet. Mieux vaut rembourser le capital et aller de l’avant.
Éviter la spécialisation
C’est une philosophie que j’aime, et elle correspond assez bien à la façon de travailler de Raincity. Nous avons nos forces, mais au besoin, nous pouvons changer de chapeau et faire ce qui doit être fait.
Quand vous demandez à des spécialistes de Javascript de résoudre un problème, ils risquent d’utiliser Javascript même si ce n’est peut-être pas le bon outil. C’est vrai pour toute spécialité, que vous travailliez côté client ou côté serveur.
Évitez l’optimisation prématurée : on investit beaucoup de temps dans quelque chose qui n’est même pas encore un problème. Voyez la situation dans son ensemble avant d’envoyer un spécialiste optimiser. Voyez plus loin que votre petit monde.
Pour appuyer ce point, Dimon a cité Windows Vista et ses multiples façons d’éteindre le système d’exploitation, alors qu’une seule aurait suffi. C’est le reflet évident d’un design conçu par comité. Chaque façon d’éteindre Vista était probablement justifiée, mais on aurait pu tout ramener à une seule méthode si chaque spécialiste avait pu renoncer à sa position pour le bien commun.
Couper des fonctions
Éliminez le superflu. Les fonctions importantes ressortent et les moins importantes disparaissent.
« L’innovation vient du fait de dire non à 1000 choses pour s’assurer de ne pas faire fausse route… » – Steve Jobs
Dimon a parlé de nombreux clients qui veulent ce que leurs concurrents ont. Pourquoi voudriez-vous ce que vos concurrents ont, alors que vous voulez faire mieux qu’eux? Plutôt que de donner aux clients ce qu’ils disent vouloir, essayez de leur donner ce qu’ils veulent vraiment.
« Éliminez l’inutile pour que l’essentiel puisse parler » – Hans Hoffman
Fin de la partie II. Lire la partie I. Les notes de Garrett
À suivre.