Carnet de notes

Catégorie : Développement informatique

  • Usure mentale de la non-qualité

    Usure mentale de la non-qualité

    Vous pouvez argu­men­ter à propos du retour sur inves­tis­se­ment de haus­ser un peu le niveau de qualité – je l’ai fait aussi – mais il faut avouer que sauf à connaitre le futur, ces chiffres auront la même fiabi­lité et la même préci­sion que l’ho­ro­scope de l’an­née dernière.

    Tout au plus peut-on tracer une ligne en dessous de laquelle le manque de qualité rend vrai­ment le travail diffi­cile, mais en réalité nous cher­chons tous à mettre la barre bien plus haut.

    Le coût de non-qualité est en fait bien plus basique. Il se cache dans la fatigue mentale, l’épui­se­ment, mais aussi la baisse d’en­vie, de moti­va­tion, de résis­tance à la frus­tra­tion ou de celle aux petits accrocs trop fréquents du quoti­diens…

    Le terme anglais est burn-out, et c’est bien plus une ques­tion de qualité et de bien-être que de temps de travail ou de pres­sion.

    C’est Nico­las qui le forma­lise le mieux :

    Ces petites erreurs aux grandes consé­quences font de plus en plus mal. Autant sur les personnes (le moral, l’es­time de soi, la frus­tra­tion) que sur le busi­ness (image, etc.). […] Je crois que ces galères de coûts de non-qualité et l’usure sur nos corps et nos esprits sont trop souvent sous-esti­mées.

    La ques­tion est : Où avez-vous envie de travailler ? Où vos colla­bo­ra­teurs ont-ils envie de travailler ? Combien de temps tien­dront-ils avant d’être usés et rési­gnés, sans moti­va­tion ni initia­tive ? Qui voulez-vous atti­rer ?

    Cet aspect est trop souvent oublié dans la logique produc­ti­viste du retour sur inves­tis­se­ment, pour­tant ce sont les ques­tions essen­tielles : À côté de l’im­por­tance du dyna­misme de l’équipe, tout gain de produc­ti­vité lié à une baisse des exigences revient à travailler à la bougie pour écono­mi­ser l’élec­tri­cité.

    Photo d’en­tête sous licence CC BY par Intan­gi­bleArts

  • Tomber en marche

    Celle ci je ne peux me rete­nir de la copier car elle est magni­fique :

    $override = null;
if ($notify_admin and $conf['browser_language'])
{
  if (!get_browser_language($override['language']))
  {
    $override=null;
  }
}

    À première vue, le code ne fait rien. À la seconde lecture non plus, je vous rassure.

    Après expli­ca­tion, la méthode get_browser_language utilise un passage par réfé­rence (oui, avec ce nom là…), c’est à dire que la variable qui est passée en argu­ment pourra voir sa valeur modi­fiée.

    Eureka! En sortie de code on pour­rait bien avoir une variable $override qui contient quelque chose. On a au passage fait une créa­tion de tableau impli­cite en utili­sant la syntaxe avec crochets sur une valeur nulle (conseil : ne jamais faire ça si vous souhai­tez rester lisible).

    La seconde affec­ta­tion $override=null sert si jamais get_browser_language a bien modi­fié $override['language'] mais a renvoyé une valeur évaluée à false.

    Mais pourquoi cette seconde affec­ta­tion à null ? Et bien il se trouve que la fonc­tion get_browser_language renvoie false si elle ne modi­fie pas la variable passée par réfé­rence. Dans ce cas le code d’ap­pel aurait quand même créé un tableau dans $override à cause de override['language'], il faut donc reve­nir en arrière et écra­ser ce tableau créé impli­ci­te­ment.

    À rete­nir :

    1. Ne jamais créer de tableau implic­te­ment avec l’opé­ra­teur crochet sur une valeur null.
    2. Ne jamais attendre un retour par réfé­rence sur une fonc­tion qui s’ap­pelle « get_* »
    3. Globa­le­ment, ne quasi­ment jamais utili­ser le passage par réfé­rence pour récu­pé­rer une simple valeur.

    Ici en plus vu qu’on utilise déjà l’éva­lua­tion à true ou false du retour de get_browser_language, autant lui faire retour­ner direc­te­ment la langue, ou null si aucune n’est trou­vée.

  • Dead­line

    Dead­line

    La plupart du temps la dead­line est une manif d’une fausse urgence créée par une absence de déci­sion
    — Raphaël

    Je ne saurais mieux dire. Esti­mer puis mesu­rer le niveau d’ef­fort est impor­tant pour pilo­ter la déci­sion. Parfois la date de livrai­son est un élément néces­saire, mais le plus souvent il ne s’agit que d’un élément arti­fi­ciel qui se veut moti­vant et qui ne vient que d’une inca­pa­cité à pilo­ter l’ef­fort en continu, à s’adap­ter aux situa­tions qui se présentent.

    Qu’im­porte quelle était l’es­ti­ma­tion précé­dente, la date qu’on a pu maladroi­te­ment en déduire. L’im­por­tant est quelle est la déci­sion la plus perti­nente à prendre aujourd’­hui, en fonc­tion de la valeur produite, et du niveau d’ef­fort encore à four­nir pour ce qu’on envi­sage.

    Le reste est simple­ment hors sujet, y compris savoir si on est « en avance »,  « en retard » ou même « parfai­te­ment dans le plan­ning » par rapport à la date prévue en direc­tion. Le pilo­tage par la date est juste une inca­pa­cité à prendre ce recul et à s’adap­ter au présent plutôt qu’aux plans passés. Tout envi­sa­ger en un bloc et sous forme de retard ou d’avance est juste telle­ment plus rassu­rant, plus simple… Ça n’ap­porte malheu­reu­se­ment aucune valeur.

    Photo d’en­tête sous licence CC BY-NC-SA par João Almeida

  • Auto­pre­fixer

    Je note ici autant pour ceux qui ne connaissent pas que pour mon moi de plus tard : Auto­pre­fixer, qui prend une CSS clas­sique et qui ajoute les versions préfixées utiles pour les diffé­rents navi­ga­teurs.

    Ça ne le fait pas bête­ment, genre pour flex­box ça sait gérer les diffé­rences de syntaxes. Bref : utile.

  • The empe­ror’s new clothes were built with Node.js

    Atten­tion ça va réagir :)

    I want to address one-by-one all of the strange and misgui­ded argu­ments for Node.js in one place.

    C’est chez Eric Jiang, et si c’est plein d’opi­nion, d’iro­nie et de cari­ca­ture, c’est quand même vrai sur le fond.

  • Code Reviews: Just Do It

    After parti­ci­pa­ting in code reviews for a while here at Vertigo, I believe that peer code reviews are the single biggest thing you can do to improve your code. If you’re not doing code reviews right now with another deve­lo­per, you’re missing a lot of bugs in your code and chea­ting your­self out of some key profes­sio­nal deve­lop­ment oppor­tu­ni­ties. As far as I’m concer­ned, my code isn’t done until I’ve gone over it with a fellow deve­lo­per.
    — Code Reviews: Just Do It

    Des Pull-Request systé­ma­tiques ont été instau­rées à TEA, et je m’en féli­cite sans aucune ombre de doute. Cette revue de code forcée améliore bien évidem­ment la qualité, mais elle permet de faire circu­ler l’in­for­ma­tion, de diffu­ser la connais­sance, de parta­ger les expé­riences, et d’aug­men­ter la valeur de tous.

    Certes, au niveau temps c’est proba­ble­ment comp­ta­ble­ment une erreur. Main­te­nant si on prend en compte l’aug­men­ta­tion de valeur que l’en­semble de l’équipe en retire, l’équa­tion est toute autre. Une fois qu’on impute ce temps aussi aux cases forma­tion, culture interne, diffu­sion des pratiques, redon­dance des connais­sances, le coût n’est fran­che­ment plus énorme.

    Merci à Anne Sophie et Olivier d’avoir parlé de nos pratiques au Mix-IT d’il y a deux semaines. C’est proba­ble­ment ces PR systé­ma­tiques qui ont généré le plus de surprises. Ce n’est visi­ble­ment pas encore fréquent ailleurs.

    Tentez pendant un mois et reve­nez en parler avec nous un soir autour de verre.

  • One Product Team

    One Product Team: We are not a sepa­rate group of desi­gners, gang of deve­lo­pers, bunch of testers, with a king product owner, who only meet each other when it is needed.

    We sit toge­ther as a team. We talk and play every­day. And we all love what we are buil­ding.

    — User expe­rience and design in BBC Play­lis­ter: how to be David Fincher

    La sépa­ra­tion stricte des rôles, avec un process, un enchaî­ne­ment, une hiérar­chie, des bureaux distincts… comment avons-nous pu construire de telles habi­tudes ?

  • The Expert (Short Comedy Sketch)

    J’hé­site toujours avant de parta­ger des vidéos, et encore plus quand il s’agit juste de renfor­cer les poncifs et stéréo­types. Celle là est cari­ca­tu­rale, mais elle repré­sente telle­ment ce que j’ai vu tout au long de ma carrière que je la mets ici, pour pouvoir la citer en réfé­rence, et vous permettre de faire de même.

  • Sur-Javas­cript

    J’avais regardé CoffeeS­cript il y a long­temps, mais sans être convaincu. Si j’ai besoin de faire du Javas­cript, je fais du Javas­cript. Coffee apporte bien des amélio­ra­tions sur la syntaxe, mais le langage n’est lui-même pas parfait et je doute que le rapport béné­fice/coût soit très élevé.

    J’en ai à peu près autant au service de Dart même si, sans réel­le­ment percer pourquoi, j’ai l’im­pres­sion qu’ils ont réussi à mieux se déta­cher de Javas­cript, et donc avoir un vrai langage distinct qui « compile » du Javas­cript (c’est bien l’es­prit de Coffee aussi, mais je n’ai pas eu ce ressenti).

    Je suis proba­ble­ment plus ouvert à TypeS­cript ou Traceur, qui sont plus proches du langage d’ori­gine et dont les objec­tifs et syntaxes sont presque « le prochain Javas­cript ». On a plutôt une couche de compa­ti­bi­lité arrière, et c’est un bon système.

    L’im­pres­sion que ça donne est tout de même qu’ils ont fait leurs propres exten­sions qui n’ap­par­tiennent qu’à eux.

    Est-ce qu’on a quelque part un projet simi­laire, qui implé­mente un maxi­mum de nouveau­tés des futurs EcmaS­cript mais qui évite d’ajou­ter trop de syntaxes diver­gentes au cœur du langage ?

    Quelles sont vos expé­riences avec l’un ou l’autre de ces systèmes ?

  • Flysys­tem – accès aux systèmes de fichier au PHP

    Petite décou­verte récente et sympa : Flysys­tem. Une biblio­thèque de code PHP qui présente une abstrac­tion assez simple et sympa autour des systèmes de fichier locaux, S3, drop­box, FTP, …