/ Team iOS

Migration Swift @ PagesJaunes

Lors de la WWDC 2014, Apple présente Swift, son nouveau langage de programmation maison. En 2015 la marque à la pomme le rend open-source. Un langage plus moderne et très différent d'Objective-C. Sur le papier ceci est beau et très excitant 🤗 🤞... Mais en pratique, qu'en est-il ?

Le challenge

Dans le cas d'une appli de dizaines de milliers de lignes d'Objective-C et sur laquelle travaillent des équipes hétérogènes de développeurs, comment réaliser cette migration, sans la refaire from scratch tout en continuant à shipper de nouvelles fonctionnalités ?

Cet article est un retour d'expérience de l'équipe iOS PagesJaunes quant à cette migration...

histo

Ce qu'il y avait au départ

Au commencement était le Verbe...

Un code

En juin 2016, notre application fait plus de 75 000 lignes de code Objective-C et certaines grosses parties de ce code datent de mi-2013 (date de la dernière refonte from scratch). De plus, Swift est un langage jeune dont la syntaxe évolue au fil de ses versions et demande de fait quelques conséquentes retouches (Swift 3 👻).

Une équipe

La Team iOS se compose à ce moment là — les choses ayant quelques peu évoluées depuis — d'une dizaine de développeurs d'un niveau technique hétérogène en Swift. Cependant, quel que soit ce niveau, l'envie et le besoin d'apprendre ce nouveau langage ainsi que ses concepts modernes (POP, Generics, etc.) se fait sentir depuis de nombreux mois à tel point que l'obligation de freiner l'excitation de certains à vouloir “s'amuser avec la prod” se fait sentir 😉. Cette temporisation devant être faite tout en veillant à stimuler l'envie d'avancer, de défricher, bref de prendre du plaisir en travaillant. Conditions sine qua non d'une pérennisation de l'équipe et de sa motivation.

Une entreprise

Travaillant au sein d'une entreprise côtée en bourse, sur une application accueillant chaque jour plusieurs centaines de milliers de visiteurs, nous avions certaines obligations : maintenir un taux de crash au plus bas [1], délivrer toutes les 6 semaines et continuer à embarquer du nouveau fonctionnel.

Comment, tout en tenant compte des contraintes présentées ci-dessus (code existant, obligations commerciales, niveau de l'équipe de devs, envie de tester les nouvelles possibilités s'offrant à nous), avons-nous réussi à migrer sans encombre, progressivement et sereinement notre application d'Objective-C vers Swift ? La réponse se trouve dans la stratégie mise en place : la stratégie des petits pas...

courbe

La stratégie des petits pas

Et le Verbe s’est fait chair, et il a habité parmi nous

Commencer doucement

La première initiative a été d'organiser la montée en compétence de l'équipe de développeurs : abonnement à Ray Wenderlich (les vidéos et leurs exercices sont très bien faits, je recommande vivement l'achat d'une licence à toute personne ayant en charge une équipe de devs iOS), livres (ex : l'excellent Advanced Swift de Chris Eidhof et Ole Begemann) et relectures entre des développeurs issus d'équipes différentes (à 2 ou 3 devs devant le même écran).

Ensuite (ou plutôt en parallèle), nous avons testé son intégration dans le code existant : interactions Swift / Objective-C, coexistence de nouvelles classes Swift avec notre code legacy, temps d'exécution, de lancement de l'app, compatibilité des nouveaux concepts introduits, etc...
Après ces tests concluants, nous avons identifié et développé de petites features non structurantes, puis vérifié que tout allait bien en production.
Durant toute cette phase, cette stratégie a été adaptée et affinée en fonction de la vélocité des différentes équipes en Swift et des contraintes liées à la roadmap. Tous les développeurs n'ont donc pas été autorisés à “jouer” avec Swift sur l'appli de prod. Ils doivent être capables d'accepter de continuer à développer en Objective-C pendant quelque temps même si cela reste — on est bien d'accord — moins “sympa”.

Stimuler l'équipe de développeurs en aménageant un temps consacré à la découverte pratique et à la discussion de quelque chose de nouveau et d'évolutif, crée une émulation extrêmement bénéfique aussi bien pour eux que pour l'entreprise qui les emploie.

lr_sante

Accélérer

Après avoir validé les points identifiés précédemment (qualité de l'appli, vélocité de l'équipe, intérêt du langage, coexistence entre Swift et Objective-C, etc.), nous sommes passés à l'étape suivante : la première grosse fonctionnalité, indépendante [2], 100 % développée en Swift.
Dans notre cas, nous avons choisi de développer un nouveau module (challenge), quelque peu stratégique pour l'entreprise (visibilité & stimulation), qui nous permet de gérer différents parcours transactionnels et en particulier celui de la santé. En deux mots, l'utilisateur peut prendre rendez-vous rapidement avec des milliers de médecins, ophtalmos ou tout autre professionnel de ce type [3]. Durant le développement de cette belle première feature 100 % made in Swift, je constatai une vraie responsabilisation des développeurs impliqués, ce qui — je ne vous le cache pas — me fit extrêmement plaisir 👍.

Au cours de ces développements, les devs sont incités à faire plus de relectures à 4 mains (voire à 6 car c'est toujours plus sympa à plusieurs). Les plus compétents en Swift aidant patiemment les autres avec pédagogie et bienveillance...

Reservation medecin

Pérenniser

Passée la montée en compétence de l'équipe, les tests de compatiblité du langage avec le code existant et la première fonctionnalité conséquente développée et mise en production, le dernier acte de cette migration consistait à péréniser et systématiser ce langage dans nos développements quotidiens :

  • Toutes les nouvelles fonctionnalités sont systématiquement développées en Swift.
  • Si une nouvelle feature modifie de manière non négligeable un code Objective-C legacy, on refait from scratch en Swift toute cette partie.
  • Tous les développeurs de la Team iOS sont en capacité de le faire.
  • L'ancien code est feature-flippé et supprimé 2 versions après la mise en production de son remplaçant[4], permettant de roll-backer en cas de besoin.

histo2

Quelle conclusion ?

Tous nous avons eu part à sa plénitude

Au bout du compte, que peut-on tirer comme enseignements de cette migration ?

Du point de vue développeurs

Les devs sont plutôt heureux et sereins de développer en Swift bien que l'autocomplétion de Xcode ainsi que les montées de versions de Swift ont été quelques peu pénibles... Aujourd'hui les chiffres montrent une meilleure vélocité (gain en temps de développement) qui tient à ce nouveau langage mais aussi au fait que les refontes from scratch des parties en Swift sont bien plus “propres” que les lignes d'Objective-C datant de plus de 4 ans... Ce code est moins verbeux, donc souvent plus lisible et nous produisons moins de bugs 😁, sans que l'on puisse savoir si cela provient d'un nouveau langage moins permissif et plus fortement typé, des parties du code refaites à neuf, de la qualité des développeurs ou plus sûrement d'un peu de tout cela...

Du point de vue humain

La migration vers Swift a été très positive en ce qu'elle a permis une vraie émulation de l'équipe (les nouveaux concepts introduits par le langage étant d'excellents stimulants intellectuels), rendant propice la discussion, les échanges, les interactions entre chacun des développeurs et permettant non seulement leur progression dans leur techno mais également de construire une cohésion d'équipe bienvenue en ces temps de volatilité[5] de ces profils recherchés.
Ajoutons à cela, un sentiment de participer à l'émergence d'une communauté d'explorateurs, défrichant, testant de nouvelles choses et commettant forcément des erreurs parfois, mais s'appliquant toujours à tirer le meilleur d'un langage jeune et prometteur. Pour eux et pour les projets auxquels ils participent.

Du point de vue entreprise

Il faut se rendre à l'évidence et accepter le fait que le développement mobile évolue très rapidement et vous devrez inévitablement migrer, cela ne sert à rien de lutter contre. Soit vous choisissez de subir, chaque développeur faisant ce qu'il veut dans son coin, mettant en péril la cohérence du code de votre application. Soit, vous organisez cette évolution de manière réfléchie, sans freiner l'élan de ceux qui sont au-dessus et qui in fine vous feront gagner du temps, tout en fixant des limites claires à l'expérience. Si petit à petit votre vieux code est remplacé par un code plus moderne, tout en veillant à refaire les fondations des parties impactées, alors non seulement votre application sera plus moderne et de meilleure qualité, mais vous renforcerez également le niveau de votre équipe de développeurs, sa vélocité ainsi que sa pérénité !

Home Page


  1. En septembre 2017, le taux de crash moyen de l'application iOS PagesJaunes est systématiquement inférieur à 0,5 % ↩︎

  2. Cette fonctionnalité ne devant absolument pas être reliée partout dans l'appli (le plat de spaghettis n'étant, de toute façon, pas recommandé bien que régulièrement mis en place dans les projets) ↩︎

  3. Aujourd'hui nous avons étendu ce transactionnel à d'autres verticales comme celles de la beauté (salons de massage, esthéticiennes, coiffeurs, etc.) ↩︎

  4. Ce feature-flipping se fait à la compilation via Tweaks (ironie du sort cette librairie est en Objective-C) ↩︎

  5. En informatique, la volatilité est le fait de perdre les informations lors de l'arrêt de l'alimentation en électricité de la machine (source Wikipedia) ↩︎