(Et comment ne pas être un gourou dont les conseils cessent de travailler après la mise à jour)
“Les applications ne peuvent utiliser que des API publiques et doivent fonctionner sur le système d’exploitation actuellement expédié.” Lignes directrices sur la revue des applications Apple
Si vous avez déjà commencé à travailler avec un nouveau cadre et que vous vous êtes surpris à penser: “Maintenant, je comprendrai tout, la documentation est pour les alésages” – vous n’êtes certainement pas seul. De nombreux développeurs ont un instinct naturel: d’abord, et seulement alors – lisez. C’est bien.
Mais c’est à ce stade que vous pouvez facilement désactiver la bonne voie et vous retrouver dans une situation où le code fonctionne … mais seulement aujourd’hui, et seulement “j’ai”.
Pourquoi est-il facile de «le comprendre» – n’est-ce pas suffisant?
Freimvorki, en particulier fermé et propriétaire, est complexe et multi-réparties. Ils ont beaucoup de fonctionnalités de logique, d’optimisation et de mise en œuvre cachées, qui:
* Non documenté;
* non garanti;
* peut changer à tout moment;
* sont un secret commercial et peuvent être protégés par des brevets
* Contient des bugs, des défauts connues uniquement des développeurs du cadre.
Lorsque vous agissez “sur une intuition”, vous pouvez facilement construire une architecture dans des observations aléatoires, au lieu du support sur les règles clairement décrites. Cela conduit au fait que le code devient vulnérable aux mises à jour et aux cas de bord.
La documentation n’est pas une restriction, mais le support
Les développeurs de cadres créent des manuels pour une raison – il s’agit d’un accord entre vous et eux. Pendant que vous agissez dans le cadre de la documentation, ils promettent:
* stabilité;
* soutien;
* Comportement prévisible.
Si vous allez au-delà de ce cadre – tout ce qui se passe ensuite devient exclusivement votre responsabilité.
Expériences? Certainement. Mais dans le cadre des règles.
La curiosité est la super-via du développeur. Explorez, essayez les limites de test non standard – tout cela est nécessaire. Mais il y a un “mais” important:
Vous devez expérimenter dans le cadre de la documentation et des meilleures pratiques.
La documentation n’est pas une prison, mais une carte. Elle montre quelles opportunités sont vraiment planifiées et soutenues. Ce sont de telles expériences qui sont non seulement utiles, mais aussi sûres.
ATTENTION: Guru
Parfois, vous pouvez rencontrer de vrais “experts”:
* Ils organisent des cours
* Percer aux conférences,
* Écrivez des livres et des blogs,
* a partagé “leur approche” du cadre.
Mais même s’ils semblent convaincants, il est important de se rappeler:
Si leurs approches sont contraires à la documentation, elles sont instables.
Ces «modèles empiriques» peuvent:
* Travaillez uniquement sur une version spécifique du cadre;
* être vulnérable aux mises à jour;
* Break dans des situations imprévisibles.
Le gourou est cool lorsqu’ils respectent les manuels. Sinon, leurs conseils doivent être filtrés grâce à la documentation officielle.
un peu solide
Trois idées de principes solides sont particulièrement pertinents ici:
* Principe ouvert / fermé: élargir le comportement via une API publique, n’entrez pas à l’intérieur.
* Principe de la substance Liskov: ne comptez pas sur la mise en œuvre, comptez sur le contrat. Troubles – Tout va se casser lors du remplacement de la mise en œuvre.
* Inversion de dépendance: les modules de niveau élevé ne doivent pas dépendre de modules de niveau bas. Les deux types devraient dépendre d’abstractions. L’abstraction ne devrait pas dépendre des détails. Les détails devraient dépendre d’abstractions.
Qu’est-ce que cela signifie dans la pratique? Si vous utilisez un cadre et directement lié à ses détails internes – vous violez ce principe.
Au lieu de cela, vous devez renforcer la dépendance à l’égard des interfaces publiques, des protocoles et des contrats que le cadre soutient officiellement. Cela donne:
* La meilleure isolement de votre code à partir des modifications du cadre;
* La capacité de tester et de remplacer facilement les dépendances;
* Comportement prévisible et stabilité de l’architecture.
Lorsque votre code dépend des détails et non des abstractions, vous vous intégrez littéralement dans une implémentation spécifique qui peut disparaître ou changer à tout moment.
et si le bug?
Parfois, il arrive que vous ayez tout fait correctement, mais cela fonctionne mal. Cela se produit – les cadres ne sont pas parfaits. Dans ce cas:
* Rassemblez un exemple minimum reproduit.
* Assurez-vous d’utiliser uniquement l’API documentée.
* Envoyer un bug-port-ils vous comprendront certainement et, très probablement, vous aideront.
Si l’exemple est construit sur des hacks ou des contournements, les développeurs ne sont pas tenus de le soutenir, et très probablement votre cas manquera simplement.
comment serrer le maximum du cadre
* Lisez la documentation. Sérieusement.
* Suivez les guides et recommandations des auteurs.
* Expérience – mais dans le décrit.
* Vérifiez les conseils (même les haut-parleurs les plus célèbres!) À travers le manuel.
* Pliez des insectes avec un minimum de cas et du respect du contrat.
Conclusion
Freimvorki ne sont pas des boîtes noires, mais des outils qui ont les règles d’utilisation. Les ignorer signifie écrire le code “au hasard”. Mais nous voulons que notre code vive pendant longtemps, ravit les utilisateurs et ne se détache pas de la mise à jour mineure.
Donc: faites confiance, mais vérifiez. Et oui, lisez les manuels. Ils sont votre superpuissance.
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
