Author: 
Didier Delforge

Contexte

InboxZero est une application de gestion d’emails avancée, présente - entre autre - sur 4 médiums de la marque Apple: iPhone, iPad, Mac et Apple Watch.
C’est dans le cadre de ce projet, que je me suis frotté à quelques frustrations. Grâce à ce projet, j’ai acquis une plus grande expérience et un approche des chose différente.
Il est évident que rendre InboxZero, ou tout autre app compatible uniquement iPhone ou rendre cette app compatible avec plusieurs supports engendrera une différence de coût. Cet écart de coût n’est pas que financier, il représente également un coût supplémentaire au niveau de la réflexion de la part du développeur, lorsqu’il va concevoir l’application.

Réflexion ?

Dans le cadre de nouveaux projets, analyser la future application est fondamental. Du point de vue du développeur, il y a deux grandes parties.
Premièrement l’analyse fonctionnelle. Il est important de liste absolument toutes les fonctionnalités présente dans l’app. En effet, estimer au plus juste le temps requis pour réaliser chacune de fonctionnalité permettra d’arriver à une estimation finale plus réaliste.
En second plan, l’analyse technique. Avant de coder, se poser la question “Comment est-ce que je vais mettre en place cela?”, vous évitera de tomber dans des pièges classiques. Cela vous permettra également d’anticiper/prévoir des adaptations futures.

Vous avez dit fainéant ?

Un bon développeur est avant tout un développeur fainéant.
En effet, lors de la création d’une app, il est important d’optimiser son temps.

  • Eviter le ‘copier/coller’ du code. Tout code dupliqué est exposé au risque de maintenance. En effet, changer la logique à 3 endroits sera plus gourmand en temps que de changer la logique à un endroit unique.
  • Externaliser la logique business. Lorsque vous créez une application compatible iOS / macOS, il est important de réutiliser un maximum la logique business. En effet, le langage utilisé étant identique (Swift ou Objective-C), si le développement a été conçu dans une optique de code partagé, cela sera converti en un gain de temps considérable.
  • Rendre son code lisible. Lorsqu’un collègue entre dans votre code, il est important pour lui de comprendre avec un minimum d’effort, ce que fait tel ou tel bout de code.

Pour résumer tous ces points disons simplement qu’il faut rendre son code réutilisable un maximum. C’est ce qu’on appelle communément le ‘code reuse’. Après tout, il parait que “Less is more” :-)

Conclusion

Pour conclure, coder de manière réfléchie et fainéante, demande un certain effort. Cet effort n’est pas vain, car au fur et à mesure, il se transformera en réflexe. Ce réflexe, finira par vous faire gagner du temps, beaucoup de temps!

 

Newsletter