Etre ingénieur logiciel n’est pas coder non stop / Cheat sheet costing dev task

Comme je l’ai souvent dit, ce qui fait la différence entre un senior développeur et les autres réside dans un principe fondamental : Invent And Simplify.

Inventer et simplifier des architectures, des fonctionnalités, du code, fait de vous le meilleur de tous. Pas le fait d’écrire des algos plus vite que tout le monde.

10809479_795248990537120_2038686246_n

Un exemple d’invention et simplification pourrait être de créer une police de caractère au lieu d’un contrôle personnalisé.

Ou encore de ne pas implémenter une nouvelle fonctionnalité de réservation en ligne mais de tout simplement créer un formulaire de mail pour gérer tout manuellement. Tout dépend du trade-offs qu’on est prêt à accepter.

On se rend compte de tout ça surtout quand on énonce toutes les tâches à réaliser quand on souhaite mettre en production une nouvelle fonctionnalité/bug fix.

Tout est une question d’échelle, et chaque tâche peut s’avérer très longues sur des systèmes complexes comme AWS ou Windows.

 

Voici ma liste « cheat sheet » que j’utilise quand je dois estimer une tâche de dev. Je serai plus que ravi si vous me laisseriez un commentaire pour la compléter. Certaines tâches sont optionnelles.

 

Analyse / compréhension des besoins

Définir les besoins, comprendre la spécification, se lancer dans une partie métier qu’on ne comprend souvent pas.

Ecriture de documentations techniques

Ecriture d’une spécification technique, d’un document d’architecture, d’un plan de tests. Surtout sur des tâches complexes ou dans des environnements waterfall.

Architecture / comprendre comment s’intégrer au système

Où placer le code ? Comprendre le code existant et s’intégrer proprement. Ne pas réinventer la roue. Surtout sur des systèmes complexes comme Office ou votre fonction existe surement déjà quelque part.

Implémentation du code

Souvent moins de 10 a 20% du temps consacré à la tâche 🙂

Unit tests

Tests des cas qui doivent fonctionner, mais aussi tous les « edges cases ». Souvent entre 4 à 10 méthodes de tests par méthodes publiques. Très utile pour éviter les régressions (on les exécute aussi souvent à la compilation sur le serveur de build).

UI tests / Intégrations tests

Comme les tests unitaires, le but est d’éviter des régressions. Que ce soit des tests d’UI ou des tests d’un service, ceux sont tous des tests d’intégrations. Très utile à exécuter lors de déploiement continu quand un code passe d’un environnement beta à gamma puis prod.

Manual testing

Un test unitaire coûte peu cher à écrire et exécuter, un test d’intégration un peu plus. Mais le pire reste les tests manuels. Il faut le documenter tel un laborantin et l’exécuter à chaque déploiement. Il faut souvent prévoir un plan de tests.

Localisation

Mon expérience me démontre que peu importe le marché que vous ciblez, vous devez localiser votre logiciel. Le jour où vous souhaitez ajouter une langue la dette technique sera trop grande. Même si vous n’avez qu’une langue, avoir tout le texte à un seul endroit est très pratique. Surtout lors de la correction de typo / garder une cohérence.

Accessibilité / Cross browser / Cross platform

Je ne connais pas les normes européennes, mais l’accessibilité est obligatoire aux USA.

Légalité

Tout dépend du domaine sur lesquels vous travaillez. Compréhension des lois en terme de cloud (hébergement dans d’autres pays), problèmes géopolitiques (qui arrivent plus souvent qu’on ne le pense), écriture de documents pour les brevets…

Code review

Une revue de code peut prendre énormément de temps suivant le type d’ingénieur. Un junior prendra surement 500% de plus, un senior 10%.

Scalabilité et Performances

Comprendre où sont les limites du logiciel (load tests), comment gérer ses limites. Comprendre le nombre de bytes qui transitent entre votre service et client. Comme améliorer un algorithme avec du parallélisme etc…

Sécurité

Essayer de casser son propre bout de code. Faire éventuellement appel à une personne externe pour faire un audit. (Cf STRIDE threat model)

Tout type de reviews

Je viens de parler de la security review mais on peut souvent avoir besoin de principal review, design review…

Metrics et alarmes

Mettre des métriques et alarmes qui se déclenchent en cas de problèmes spécifiques. Pour savoir comment notre logiciel est utilisé. La télémétrie étant un point essentiel dans tout bon software.

Logging

Avoir des métriques et alarmes c’est bien. Mais comprendre ce qu’il se passe et ce que l’utilisateur a fait, c’est mieux. 🙂

Gestion des exceptions / comment le système recover

Intégrations avec des systèmes externes

Mon expérience me montre que ce point est souvent l’un des plus coûteux. Surtout quand les systèmes externes se construisent en même temps. Intégrer des systèmes externes est souvent un des plus gros pièges lors de l’estimation.

Choix et identification des dépendances

Déploiement / Installation / Regionalization

Gestion / création des credentials

Créer les mots de passes pour accéder à la base de donnes, à un service. Où stocker le certificat ? etc…

Versioning, authentication, throttling, timeouts, retries…

Merge / clean code / checkin / compilation

Sur des sources complexes comme Office, checkin un code peut prendre jusqu’à 15 jours. En effet, des milliers de développeurs travaillent parfois sur la même branche et les checkins rentrent souvent en collision. Ce qui a pour effet de « geler » la branche et de rejeter votre checkin.

J’ai déjà eu à attendre plusieurs semaines avant de pouvoir pousser mon code. Sans compter tous les merges à faire. La compilation aussi était un calvaire puisque la plus petite DLL à compiler nécessitait au moins 4h.

Maintenance / débogage

User expérience

Laboratoire/experiences, wireframes, personas…

Documentations

N’hésitez pas à envoyer ce lien à ceux qui pensent qu’être ingénieur logiciel c’est coder. Coder n’est que petite partie du travail à réaliser.

FacebookLinkedIn
  • Bassama

    Merci pour ce life-cycle détaillé !

    • C’est une liste en vrac, pas vraiment un cycle 🙂

  • Fabien

    Ce billet est intéressent, ça donne envie d’avoir chaque point plus développé ! (Je sais que tu en a aborde quelques un déjà)

    Pour ce qui est de l’accessibilité en France elle est normalement obligatoire pour les sites publique (Mairie, office de tourisme, etc) autant dire que c’est loin d’être le cas malheureusement…

    Je me demandais comment est integrer le travail du designer, c’est internet a l’equipe, externet et chaqu’un dans son coin… ?

  • Jai oublie de preciser network/infrastructure/regionalisation…

  • Eregrith

    Merci pour ce billet 🙂
    J’ai out de même une question qui me taraude : Penses-tu qu’il soit réellement indispensable de localiser un produit destiné à une population de fonctionnaires français qui ne s’étendra jamais + que ça ?
    Si oui, j’aimerai bien savoir pourquoi ^^ ?

    • Toute application doit être localisé. Pour deux raisons :
      -consistence des messages (tu as forcement du texte qu se répète)
      -éviter la casse. Si un mauvais developpeur commence a mettre des comparaison de strings dans le business logic au moins il le fera a travers le dictionnaire de ressources

      • Eregrith

        Ah oui, vu sous cet angle c’est mieux. J’avais oublié la consistence. Ca fait trop longtemps que je n’ai point travaillé avec de la loc’ ma foi XD.

  • Je rajoute pour les APIs, choses a penser absolument:
    -Backward compatibility,
    -Idempotency,
    -Pagination,
    -Unbounded operations,
    -Exception handling,
    -Batch operations,
    -Throttling
    -Versioning