Article original : How to Know When You've Learned Everything You Can From a Programming Problem

Par Amy Haddad

La réponse peut sembler évidente : vous avez terminé un problème une fois que vous l'avez résolu.

C'est ainsi que j'abordais la résolution de problèmes lorsque j'ai commencé à apprendre à coder. J'étais sur un tapis roulant de résolution de problèmes : résoudre autant de problèmes que possible le plus rapidement possible.

Et pourquoi pas ? Il n'y a pas de pénurie de problèmes à résoudre. De plus, ne devenez-vous pas meilleur en résolvant plus de problèmes ? Plus précisément : que pouvez-vous faire d'autre une fois que vous avez la réponse ? Comme il s'avère, beaucoup de choses. Le sophisme de mon approche a rapidement fait surface.

Bien que j'aie résolu le problème, je n'ai pas beaucoup appris de celui-ci. C'est parce que quelques jours ou semaines plus tard, lorsque j'ai essayé de résoudre à nouveau le problème ou lorsque je suis tombé sur un problème similaire, je me suis vraiment bloqué. Des erreurs ont été commises. Les concepts étaient confus. Le progrès était au point mort.

Je réalise maintenant que l'obtention de la solution n'est qu'une partie du processus de résolution de problèmes. Ensuite, comme le dit le mathématicien George Pólya, il est temps de "regarder en arrière".

Regarder en arrière

Pólya écrit sur le processus de résolution de problèmes dans son livre, Comment le résoudre, à travers le prisme de la résolution de problèmes mathématiques. Mais ses idées sont applicables à la programmation. Ce qui m'intéresse particulièrement, ce sont ses idées sur la quatrième phase : regarder en arrière.

"En regardant en arrière la solution terminée, en reconsidérant et en réexaminant le résultat et le chemin qui y a conduit, [les étudiants] pourraient consolider leurs connaissances et développer leur capacité à résoudre des problèmes", écrit Pólya.

À certains égards, résoudre un problème est comme créer une œuvre d'art. Il y a toujours quelque chose de plus que nous pourrions faire. "Nous pourrions améliorer toute solution, et, dans tous les cas, nous pouvons toujours améliorer notre compréhension de la solution", explique Pólya.

Pour moi, "regarder en arrière" est une pratique d'auto-amélioration et d'apprentissage. Le but est de :

  • Apprendre de mes succès : comprendre ce que vous avez écrit et pourquoi.
  • Consolider mon apprentissage de nouveaux concepts.
  • Voir des motifs et comprendre le contexte pour utiliser une structure de données ou un algorithme particulier.

Prenons l'exemple d'un joueur de basketball qui tire 1 000 fois chaque jour. Cela semble admirable. Mais à mesure qu'il se précipite pour atteindre les 1 000 tirs, sa forme devient négligée. Il utilise la mauvaise technique.

Il bénéficierait davantage de tirer quelques centaines de fois, puis d'évaluer sa performance : regarder un enregistrement vidéo de sa forme, voir les défauts et les corriger. Ensuite, il retournerait sur le terrain.

Maintenant, il sera plus informé, puisqu'il a regardé en arrière et évalué sa performance. Il pratiquera mieux.

Il en va de même pour la résolution de problèmes. L'idée n'est pas de cocher une case pour pouvoir prétendre avoir résolu "x" nombre de problèmes. Au lieu de cela, il s'agit de faire de votre mieux à chaque fois et d'apprendre autant que possible en cours de route.

Il y a trois raisons pour lesquelles regarder en arrière est important.

Raison #1 : Voir les motifs et comprendre le contexte

Vous verrez des motifs similaires encore et encore dans les problèmes que vous résolvez.

Comprenez comment utiliser un algorithme particulier, comme la recherche binaire. Entraînez votre œil pour savoir quand et comment l'appliquer. Ainsi, lorsque vous rencontrerez un problème similaire à l'avenir, vous serez prêt. Cela vous fera gagner du temps (et de la frustration) à long terme.

Raison #2 : Consolider votre apprentissage

Supposons que vous avez utilisé quelque chose de nouveau pour résoudre un problème, comme une pile ou une file d'attente.

Savez-vous vraiment comment l'utiliser à nouveau ? Vous sentez-vous à l'aise d'utiliser une pile dans un problème similaire ? Prenez le temps de comprendre tout ce que vous avez utilisé de nouveau afin de pouvoir l'utiliser à nouveau à l'avenir.

Raison #3 : Apprendre de vos succès

Le mathématicien Richard Hamming va droit au but avec cette citation de son livre, The Art of Doing Science and Engineering.

"Je considère l'étude des succès comme étant fondamentalement plus importante que l'étude des échecs... il y a tant de façons d'avoir tort et si peu d'avoir raison, étudier les succès est plus efficace."

En tant que programmeurs, nous avons notre part d'erreurs. Et puis (de nombreuses tentatives plus tard), nous exécutons le programme et il fonctionne. Maintenant est un excellent moment pour mettre en pratique les mots de Hamming et étudier votre succès.

Comprenez-vous comment votre programme fonctionne ? Comprenez-vous ce que vous avez écrit et pourquoi vous l'avez écrit ?

En regardant en arrière—quand l'information est encore fraîche dans votre esprit—vous préparez votre futur vous. Cela vous aidera à combler votre compréhension et à consolider vos modèles mentaux. Cela vous aidera à vous améliorer et à éviter de répéter les mêmes erreurs. En bref, cela vous aidera à devenir meilleur.

Quatre façons de regarder en arrière

Il y a quelques façons dont je "regarde en arrière" les problèmes. Essayez-les.

Enseignez-vous à vous-même

Une façon fantastique d'aider à consolider vos modèles mentaux est de vous enseigner à vous-même. Après avoir terminé un programme ou un problème, passez en revue votre code et expliquez-le ligne par ligne. C'est l'une des meilleures façons de "regarder en arrière" lorsque vous apprenez quelque chose de nouveau.

J'ai trouvé ce processus inestimable lors de l'apprentissage du développement web. Après avoir terminé un projet, je copie mon code dans un Google Doc. En commençant par le haut, je fais des commentaires tout au long pour m'enseigner des concepts importants.

Voici un exemple de code et de certains des commentaires que j'ai écrits.

export default function ManageTeamMembersPage(props) {

    const [teammate, setTeammate] = useState({
       name:"",
       email: "",
       role: "",
   })

   ...
  • Utilisez les props pour accéder aux données transmises par le composant parent.
  • Ajoutez un hook d'état. Le hook prend une valeur par défaut, qui est un objet contenant tout ce dont j'ai besoin pour le formulaire : nom, email, rôle.

Cette méthode de "regarder en arrière" consiste à comprendre. Dans cet exemple, j'apprenais l'état, les props et les formulaires dans React.

Écrire des commentaires pour expliquer votre code vous aidera à consolider les concepts dans votre esprit. Si vous ne pouvez pas taper une courte explication sur le moment, alors revisitez le sujet.

Cette méthode est tout aussi utile pour les problèmes et projets futurs. Je consulte régulièrement d'anciens problèmes et programmes que j'ai annotés. Je les utilise comme référence lors de l'écriture de programmes similaires ou de la résolution de problèmes similaires. Cela renforce les idées clés, et comme le souligne Hamming, cela m'aide à me souvenir de mes succès : ce qu'il faut continuer à faire.

Étudiez les solutions de grands programmeurs

Il est non seulement utile d'étudier votre propre code, mais aussi le code des autres qui ont résolu le même problème. Il y a beaucoup de grands programmeurs et nous pouvons apprendre d'eux.

Après avoir résolu un problème, j'applique une technique d'apprentissage que Ben Franklin utilisait pour devenir un meilleur écrivain. Son processus impliquait d'essayer de reproduire un article d'une publication qu'il admirait après avoir oublié les détails de celui-ci.

Je suis un processus similaire pour devenir un meilleur programmeur.

Voici comment cela fonctionne :

  • Résolvez un problème.
  • Trouvez un programmeur qui est meilleur que vous et qui a résolu le même problème.
  • Étudiez leur solution : lisez chaque ligne de code et tapez un commentaire dans votre éditeur pour l'expliquer.
  • Re-résolvez le programme après que quelque temps se soit écoulé. Utilisez les commentaires que vous avez tapés comme indices pour vous guider tout au long du processus.
  • Comparez votre programme à celui que vous avez étudié.

Pour être clair, cette pratique ne consiste pas à mémoriser ou à copier le code de quelqu'un d'autre—loin de là. Il s'agit plutôt d'apprendre : pratiquer la lecture de code ; voir une autre façon de résoudre le même problème ; expérimenter de nouvelles parties d'un langage ; et pratiquer l'enseignement à vous-même. Il s'agit également d'appliquer ce que vous avez appris en l'intégrant à votre propre style.

Ajoutez une contrainte

Voyez comment différentes techniques s'appliquent au même problème lorsque vous ajoutez une contrainte. Par exemple, vous avez résolu le problème en utilisant une table de hachage. Essayez maintenant de le résoudre en utilisant un tableau.

L'idée est de gagner une autre perspective, et ajouter une contrainte peut faire exactement cela. Cela vous sortira de votre zone de confort, vous forçant à penser de manière créative.

En conséquence, vous pourriez trouver une approche plus élégante et réduire la longueur de votre programme de moitié. Ou vous pourriez réaliser quelle structure de données ne pas utiliser, ce qui est tout aussi important.

Voici le point : vous aurez une autre approche à votre disposition lorsque vous serez confronté à un problème similaire à l'avenir.

Résolvez un problème similaire

Le site de programmation LeetCode est formidable pour de nombreuses raisons. L'une d'elles est de fournir des questions similaires pour les problèmes que vous résolvez.

Dans un problème sur LeetCode, vous recevez un tableau d'entiers et un nombre cible. Le but est de trouver deux nombres qui s'additionnent pour atteindre la cible et de retourner leurs indices.

Vous résolvez le problème.

Maintenant, résolvez un problème similaire, que LeetCode fournit. Cette fois, vous recevez un tableau d'entiers trié par ordre croissant, ainsi que quelques contraintes supplémentaires pour différencier ce problème du précédent.

Résoudre un problème similaire est un excellent moyen de pratiquer l'utilisation d'une technique, d'une structure de données ou d'un algorithme similaire dans un contexte différent.

Regarder en arrière se concentre sur le processus, plutôt que sur le résultat final. Et revisiter le processus est important. C'est sortir de sa zone de confort, essayer quelque chose de nouveau, qu'il s'agisse d'une structure de données ou d'un algorithme. C'est réaliser qu'il existe différentes façons de résoudre le même problème. C'est comprendre comment écrire un meilleur code. C'est apprendre.

Oui, cela prend du temps de regarder en arrière. Mais c'est du temps bien dépensé : c'est ainsi que nous nous améliorons.

Je parle des compétences en programmation que vous devez maîtriser et des concepts que vous devez apprendre, ainsi que des meilleures façons de les apprendre (amymhaddad.com).