Un bon exemple de ce que j'essaie de demander serait la nouvelle fonctionnalité Timeline de Facebook. Au début, seuls quelques privilégiés étaient autorisés à accéder à la chronologie. Au fur et à mesure que la fonctionnalité se solidifiait dans son fonctionnement et que des bogues y étaient corrigés, des utilisateurs supplémentaires étaient autorisés à accéder à la fonctionnalité. À une date ultérieure, un grand groupe d'utilisateurs ont été autorisés à accéder à la fonctionnalité et maintenant, c'est une fonctionnalité générale pour tous les utilisateurs. Comment une équipe de développement gère-t-elle ce type de fonctionnalité?
J'ai joué avec l'idée d'utiliser des paramètres de configuration pour contrôler sélectivement l'accès si quelque chose est en test ou en production via un fichier de configuration et des instructions if conditionnelles dans le code. Maintenant, bien que cela soit acceptable pour des fonctionnalités simples, je pense que si nous essayions de l'implémenter dans un ensemble de fonctionnalités plus large, cela deviendrait ingérable.
Quelle serait la meilleure façon de gérer les déploiements de fonctionnalités de cette manière?
Réponses:
Il est facile de deviner qu'un système comme Facebook est largement alimenté par des bases de données. Toutes les données utilisateur sont évidemment stockées dans des bases de données, et cela inclut probablement des informations sur la façon de rendre les données de l'utilisateur. Il est impossible de savoir exactement comment la base de données de Facebook est configurée, mais il doit être le cas qu'une fonctionnalité comme Timeline soit déployée progressivement aux utilisateurs en sélectionnant périodiquement des utilisateurs dans la base de données, en fonction de certains critères, et en modifiant la valeur ( s) de certains domaines.
Par exemple, peut - être ils ont un champ dans la table utilisateur comme
timeline_statusqui a des valeurs telles quenot offered,offered,previewetpublic. Sur cette base, le système de Facebook pourrait décider de la façon de rendre la page d'informations de l'utilisateur. L'équipe FB pourrait ensuite essayer la fonctionnalité Chronologie en sélectionnant un groupe d'utilisateurs et en modifiant la valeur de ce champ.En pratique, je suis sûr que c'est un peu plus compliqué que cela, mais l'idée centrale est qu'un compte d'utilisateur n'est que des données, et certaines de ces données peuvent déterminer les fonctionnalités disponibles. Déployer une nouvelle fonctionnalité n'est alors qu'une question de mise à jour des enregistrements utilisateur dans la base de données.
la source
Ouais, c'est la mauvaise façon de le faire. Quelle que soit la fonctionnalité X, si elle est configurable, elle doit étendre ou remplacer quelque chose. Faites-le dans le code. Par exemple, la chose FB pourrait avoir quelque chose comme ceci:
Ensuite, vous créez une fabrique qui crée des objets UserPageView lors de la visite d'une page utilisateur en fonction de la configuration. Vous activez cette vue. Pas de branches idiotes.
Vous voulez le faire de cette façon parce que si quelqu'un vous demande de le changer une fois, il le demandera à nouveau. De plus, ils demanderont de changer autre chose. Énigmez votre architecture avec des cas spéciaux et si c'est partout et vous aurez un bol géant de spaghettis moisis non durables plutôt qu'un produit riche en fonctionnalités et mature.
la source
Pensez à la fonctionnalité de la même manière que vous penseriez à une fonctionnalité d'administration sur un site Web.
Lorsqu'une page est en cours de chargement, vérifiez si l'utilisateur a les bons privilèges pour la fonctionnalité, le cas échéant, chargez-la.
Facebook semble utiliser une approche basée sur la localisation lors du déploiement de nouvelles fonctionnalités. Cela peut être aussi simple que de regarder l'adresse IP des utilisateurs pour trouver leur emplacement.
la source