Business : Simplifier l’entretien technique du produit pour les PM non techniques.

À ce stade, nous avons une conception de fonctionnement de base qui peut être utilisée par quelques personnes. Il ne personnalise pas non plus la réponse, ni ne pourrait gérer la charge si trop de développeurs commencent à chercher en même temps.

Que devons-nous aborder ensuite? Oui, la stabilité et l’évolutivité aspect! Jusqu’à présent, nous avions utilisé des termes techniques très limités. C’était purement conceptuel. Voyons si nous pouvons continuer ainsi jusqu’à la fin.

Oubliez ce que j’ai dessiné ci-dessus. Ne vous y référez que lorsque nous parlons.

D’accord, jusqu’à présent, nous travaillions avec un seul développeur. Que se passe-t-il si toute l’organisation pour laquelle nous l’avons construit prévoit de commencer à chercher? Pire, que se passe-t-il s’ils aiment le service et le réfèrent à d’autres organisations et qu’ils commencent à chercher aussi? Un serveur pourra-t-il gérer la charge? Probablement pas.

Alors ajoutez-en un peu plus. Mais attendez. Pouvons-nous simplement ajouter quelques nouveaux serveurs? Le but était de gérer la charge, non? Comment fait-on cela? Peut-être existe-t-il une technologie qui peut distribuer par programme les demandes entrantes aux serveurs qui sont gratuits ou ont une charge comparativement moins importante? Alors ajoutons-le.

Vous pouvez marquer des points complets (et même plus) dans une interview si vous expliquez simplement le besoin et la mise en œuvre d’une technologie conceptuellement que de nommer la technologie elle-même.

D’accord, maintenant nous avons réussi à équilibrer la charge entrante. Mais nous l’avons fait uniquement pour le serveur. Et les ressources internes? Ne seraient-ils pas affectés par la même charge? Ouais! Essayons donc d’en ajouter plusieurs copies également.

Jusqu’à présent, nous avons pris en charge l’évolutivité.

Maintenant, réfléchissons à la latence. Qu’est-ce que la latence en termes d’utilisateurs? C’est quand il faut trop de temps pour voir quelque chose apparaître sur la page Web.

Pourquoi cela arrive-t-il? Eh bien, plusieurs raisons. Principalement lorsque la réponse pour chaque demande doit être traitée indépendamment et extraite de la base de données.

Alors que dans certains cas, il est nécessaire de tout traiter, dans la majorité des situations, nous n’en avons pas besoin.

Imaginez Twitter. Vous tweetez et il est visible par vos abonnés. Ainsi, chaque fois que votre abonné ouvre sa page d’accueil, le système récupère chaque tweet qui doit être affiché et les affiche.

Regardez comment redondant c’est? Plus important encore, voyez comment à forte intensité de processus c’est? Pourquoi refaire la même tâche encore et encore alors que rien ne va changer? Les abonnés voient-ils différentes versions du même tweet? Non! Dans notre cas, attendons-nous que différents développeurs voient différentes versions du même code s’ils ont les mêmes critères de recherche? Non!

Ajoutons donc un mécanisme par lequel, au lieu que le serveur doive parcourir tout le processus à chaque fois, il peut simplement obtenir les résultats directement et plus rapidement chaque fois qu’il voit la même demande.

Comment fait-on cela? Eh bien, mettons-le dans la mémoire à accès aléatoire! Fondements informatiques (et vous devez au moins le savoir). La récupération d’informations à partir de la mémoire vive ou de la RAM est souvent 100 fois (ou plus) plus rapide que celle des disques durs. Naturellement, vous pouvez lire et écrire des choses plus rapidement à partir d’une RAM que d’un disque dur.

Cette idée de base fonctionne derrière la mise en cache. Il y a des avantages et des inconvénients, mais nous n’y irons pas maintenant. Mettez toutes les données «statiques» réutilisables sur la RAM afin que la prochaine fois qu’elles les recherchent, elles les obtiennent à une vitesse ultra-rapide.

Vous auriez probablement déjà effacé votre navigateur et le cache de votre téléphone au moins une fois pour les rendre plus rapides. Même concept. Les navigateurs mettent de nombreux éléments en mémoire afin de pouvoir les récupérer facilement. À mesure que la mémoire se remplit, le navigateur ne peut plus ajouter d’éléments, ce qui ralentit l’ensemble du système. Ensuite, soit vous le nettoyez manuellement, soit le système a une automatisation en place pour décider ce qui doit rester et ce qui doit disparaître de la mémoire.

D’accord, nous ajoutons donc un cache à notre système pour le rendre plus rapide.

Qu’en est-il des bases de données?

Lors de la conception de la base de données, il est important de noter que non seulement les développeurs chercheraient un code, le le système doit d’abord trouver ces codes et les stocker. Ce sera une conception de composant distincte qui sera essentiellement connectée au système sur lequel nous travaillons actuellement. Mais reconnaissant son existence et demander à l’intervieweur s’ils veulent que vous passiez en revue cette partie est important.

Maintenant, avec notre système, qu’est-ce qui est plus important? Lire ou écrire? Que font les développeurs? Ils «recherchent» un code. La recherche consiste essentiellement à lire à partir de la base de données. Alors, que devrions-nous faire? Nous pouvons conserver une ou deux bases de données pour servir à la fois de lecture et d’écriture, mais est-ce efficace?

Imaginez-vous le même code écrit et recherché le même nombre de fois? Probablement pas. Le but est de écrire une fois et réutiliser. Mais l’autre composant du système qui trouve et stocke les codes fonctionnerait simultanément. Alors, pourquoi ne pas les séparer? Conservez un ensemble de bases de données qui accepte les demandes d’écriture uniquement en temps réel et un autre (plus grand) ensemble de bases de données qui sont uniquement lues.

Quel est le problème en faisant cela? Comment les bases de données lues obtiendront-elles les nouveaux codes stockés dans les bases de données d’écriture?

Eh bien, nous pouvons y arriver par programme lorsque les bases de données en lecture seule ont des charges plus faibles, peut-être pendant les heures creuses. Une chose importante à considérer est de savoir si les codes qui sont recherchés et stockés par le service parallèle doivent être montrés aux développeurs qui recherchent le code immédiatement ou non. Sinon, cette méthode «asynchrone» fonctionnerait. Sinon, nous pourrions avoir besoin d’utiliser la même base de données pour les deux fonctions (ou trouver des alternatives).

Jusqu’à présent, nous avons pris le problème ambigu, décomposé en composants, et avons mis au point un système fiable et évolutif. Nous pouvons continuer et essayer de décoder comment le moteur de personnalisation fonctionnerait, à quoi ressemblerait le service de récupération de méthode, quel algorithme il utiliserait, comment tenons-nous compte des développeurs qui parlent différentes langues, etc. Vous pouvez continuer à rendre cela aussi complexe comme tu veux tant que tu comprends CE QUE L’UTILISATEUR VEUT!

La chose importante à garder à l’esprit est qu’en tant que chef de produit, vous n’êtes pas censé concevoir le système. Il y a des ingénieurs talentueux pour le faire. Le but de l’entretien est de voir dans quelle mesure vous seriez à l’aise de discuter de ces aspects avec des ingénieurs et, plus important encore, à quel point êtes-vous empathique envers les utilisateurs.

Courtoisie d’image: Google