(et comment créer des solutions qui continuent de fonctionner après les mises à jour)
“Les applications ne peuvent utiliser que des API publiques et doivent s’exécuter sur le système d’exploitation actuellement disponible.” Directives d’examen des applications Apple
Si vous avez déjà commencé à travailler avec un nouveau framework et que vous vous êtes dit : « Maintenant, je vais tout comprendre moi-même, lire la documentation est trop long », vous n’êtes certainement pas seul. Beaucoup d’entre nous ont un instinct naturel d’investigation : essayez d’abord, et ensuite seulement regardez les instructions. Et c’est tout à fait normal.
Cependant, à ce stade, il peut être facile de se laisser emporter et de se retrouver dans une situation où le code fonctionne très bien, mais repose peut-être sur des fonctionnalités non évidentes du système.
Pourquoi ne suffit-il parfois pas simplement de « le découvrir par soi-même » ?
Les frameworks, en particulier ceux fermés, sont des systèmes complexes et multicouches. Ils cachent souvent une logique interne et des optimisations qui :
* ne sont pas décrits dans la documentation publique ;
* ne garantissent pas que le comportement sera maintenu à l’avenir ;
* peut changer avec la sortie de nouvelles versions ;
* peut contenir des fonctionnalités connues des développeurs qui n’ont pas encore été corrigées.
Lorsque nous agissons intuitivement, nous risquons de construire une architecture sur des observations aléatoires plutôt que sur des règles documentées. Cela peut rendre le code plus sensible aux mises à jour.
La documentation n’est pas une limitation, mais un support fiable
Les développeurs de framework créent des manuels pour nous aider. En agissant dans la documentation, nous obtenons :
* stabilité ;
* soutien;
* comportement prévisible du système.
En dépassant ces limites, on prend des risques supplémentaires, et la maintenance d’un tel code devient plus difficile.
Des expériences ? Certainement. Mais avec une compréhension des limites.
La curiosité est une grande qualité à avoir chez un développeur. Explorer et essayer de nouvelles choses est absolument essentiel. Mais voici un petit souhait :
La manière la plus confortable d’expérimenter est de s’appuyer sur les meilleures pratiques.
La documentation est une carte qui montre quels chemins sont les plus sécurisés et pris en charge par les créateurs.
Un point de vue extérieur : conseils d’experts
Nous apprenons souvent de collègues expérimentés :
* ils dispensent des cours utiles,
* prendre la parole lors de conférences,
* écrire de merveilleux livres et blogs,
*partager leur vision unique.
Beaucoup d’entre eux partagent des expériences vraiment précieuses. Mais il convient de le rappeler : si les approches de l’auteur contredisent la documentation officielle, elles peuvent s’avérer fragiles.
De tels « modèles empiriques » :
* travailler uniquement sur une version spécifique du framework ;
* sensible aux mises à jour ;
* peut se comporter de manière imprévisible dans des situations inhabituelles.
Apprendre de la communauté est formidable et enrichissant. Mais tout conseil, même le plus fiable, doit toujours être soigneusement vérifié avec les manuels officiels.
Un peu de SOLID
Trois idées issues des principes SOLID complètent parfaitement cette approche :
* Principe ouvert/fermé : essayez d’étendre le comportement via des API publiques et, si possible, ne dépendez pas d’une implémentation cachée.
* Principe de substitution de Liskov : comptez sur le contrat et non sur la mise en œuvre spécifique. Sinon, des changements sous le capot peuvent entraîner des difficultés inattendues.
* Inversion des dépendances : créez des dépendances sur des abstractions, pas sur des détails.
En pratique, cela signifie que le fait d’être lié à des détails internes non documentés du cadre rend le système fragile.
Sur la base des interfaces et des contrats publics, nous obtenons :
* une meilleure isolation du code des modifications apportées au framework ;
* facilité de test ;
* prévisibilité et fiabilité de l’architecture.
Et s’il y a un bug ?
Il arrive aussi que tout soit fait selon les règles, mais que le résultat ne soit pas à la hauteur des attentes. Les cadres évoluent et ne sont pas toujours parfaits. Dans de tels cas :
* Construisez un exemple minimal qui reproduit le problème.
* Assurez-vous que seules les API documentées sont utilisées.
* Envoyez un rapport de bug – l’équipe de développement appréciera certainement votre travail et essaiera de vous aider.
Si l’exemple repose sur des solutions de contournement, il sera beaucoup plus difficile pour les développeurs de fournir une assistance.
Comment tirer le meilleur parti du framework
*Se référer à la documentation.
* Suivez les guides et recommandations des auteurs.
* Expérimentez dans le cadre de la fonctionnalité décrite.
* Vérifiez les conseils d’Internet auprès de sources officielles.
* Localiser les bugs en respectant les contrats-cadres.
Conclusion
Les frameworks sont des outils puissants avec leurs propres règles du jeu. En les oubliant, nous risquons de rendre notre code trop vulnérable. Mais nous voulons tous que les produits créés durent longtemps et ne nécessitent pas de corrections urgentes après chaque mise à jour mineure.
Les manuels et la documentation constituent un excellent support qui permet de créer des solutions véritablement fiables.
Sources
https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM
Leave a Reply