Lire du code que vous n'avez pas écrit
La frontière entre « testeur automatisation » et « SDET » dans la plupart des entretiens : savez-vous vous repérer dans une base de code que personne ne vous explique.
Les points d'entrée d'abord
Avant de lire la moindre logique, répondez à une question : comment ça démarre ? La commande de lancement du README, les scripts de package.json, les fichiers main/index/server. Chaque base de code est un arbre ; trouvez le tronc avant les branches.
Puis suivez un flux
Choisissez un comportement que vous pouvez voir — un libellé de bouton, une URL, un message d'erreur — et faites un grep sur son texte. Cette chaîne est une corde : tirez-la et avancez vers l'intérieur une couche à la fois, en notant le chemin du fichier au fur et à mesure.
git grep -n "Place order" # where the visible thing lives
git grep -n "placeOrder" # the function behind it
git log -p --follow -- src/checkout.js # how it got this wayGrep, débogueur, ou demander ?
- Grep répond au *où* — gratuit, instantané, sans setup.
- Un débogueur ou un print répond au *ce qui se passe réellement* — quand lire ne suffit pas.
- Un humain — après 30 minutes concentrées, avec ce que vous avez essayé : « j'ai tracé X jusqu'à Y, je m'attendais à Z » vous obtient un mentor ; « comment ça marche ? » vous obtient un lien vers le README.
Basé sur la façon dont les ingénieurs naviguent réellement dans des repos inconnus