Comment résoudre tout problème de programmation

Bonjour à tous!

Aujourd'hui, votre attention est invitée à traduire, à sa manière, un article irremplaçable qui vous aidera à aborder correctement même les savoirs traditionnels les plus insidieux et non triviaux, que vous ne comprenez pas à première vue. L'essentiel n'est pas d'abandonner et de formuler intelligemment des questions. M. Justin Fuller de Bank of America explique aimablement comment le faire correctement.



Bonne lecture!

Ce jour est donc venu. Peut-être que c'est votre premier jour ouvrable, ou peut-être que vous travaillez à cet endroit depuis dix ans - cela n'a pas d'importance. Cela arrive à tout le monde: vous tombez enfin sur une tâche que vous ne comprenez tout simplement pas.

Que faire? Il suffit de commencer et d'espérer que tout fonctionne par lui-même? Ou admettre au patron que vous ne pouvez pas faire ça, parce que vous ne comprenez pas?

Je pense que vous avez deviné que la bonne réponse n'est ni l'une ni l'autre!

J'ai remarqué qu'en programmation, comme dans toute autre profession, il est presque impossible de vivre une semaine de travail (et parfois une journée de travail) sans avoir à faire face à une tâche totalement incompréhensible.

Mais ne t'inquiète pas! Il y a de bonnes nouvelles. Non seulement vous pouvez résoudre ce problème, mais il peut également vous être bénéfique.

Après tout, ce faisant, vous devrez élargir vos connaissances et vos compétences par rapport à tout ce que vous avez fait et saviez auparavant.

Ensuite, je vais vous dire comment combler l'écart entre les exigences qui ont été définies pour vous et les connaissances dont vous avez besoin pour terminer la tâche.

À propos des "exigences"

Comme vous l'avez déjà remarqué, j'utilise le mot «exigences». Selon l'endroit où vous travaillez exactement, ce mot peut avoir certaines connotations.

D'après mon expérience, dans les grandes entreprises, ils aiment les exigences, et dans les petites entreprises, ils «ne proposent parfois pas d'exigences». Je pense que c'est de cela que nous devrions parler ici.

Le fait est qu'en fin de compte, tous les programmeurs font la même chose: ils résolvent les problèmes.
Vous pouvez obtenir un savoir-faire exhaustif d'une centaine de pages sur la façon de résoudre ce problème (j'ai déjà assisté à une réunion d'une heure sur le texte d'un bouton). Ou peut-être de cette façon: le PDG passe devant votre bureau et comme s'il vous demandait par inadvertance - "allez-vous faire face à cette tâche d'ici vendredi?"
Dans les deux cas - la tâche est définie pour vous et vous devez être sûr de bien la comprendre; la seule façon de l'approcher à droite!

À propos des étapes

Toutes les étapes répertoriées ci-dessous ne seront pas requises pour aucune tâche. Seules les tâches les plus complexes peuvent nécessiter une exécution minutieuse de toutes les étapes qui seront abordées dans cet article.

Il est possible que de nombreuses questions ne puissent être répondues sur la seule base d'exigences exprimées ou en raison de l'insuffisance de votre expérience personnelle.

Vous devrez peut-être consulter d'autres développeurs, chef d'équipe, propriétaire de produit, analyste commercial ou même grand-mère! Et peut-être avec chacun d'eux, avant que le problème puisse être résolu!

Mais c'est normal. Cela signifie que vous collecterez des connaissances disparates et les rassemblerez en un seul ensemble - et ainsi vous pourrez obtenir le meilleur résultat possible!

Enfin, dernier avertissement: n'en faites pas trop avec la formalisation! La chose la plus importante ici est de comprendre rapidement la tâche. Pas de barrières artificielles et de rubans rouges nécessaires! Tout ce qui est nécessaire est un plan systématique pour résoudre un problème que vous ne comprenez pas actuellement.

Première étape: analyser le problème

À ce stade, nous essayons de comprendre ce qu'on vous a demandé de faire. Jusqu'à ce que nous essayions de décider comment nous allons le faire!

Il est important de saisir cette différence. Il peut être dangereux de passer à une carrière sans en réaliser toutes les conséquences ou, pire encore, de ne pas bien comprendre exactement ce qu'on vous a demandé de faire.

Nous classons le problème

Classer une tâche signifie déterminer quel travail devra être fait pour la résoudre. Voici quelques exemples de types de tâches:

• Correction d'un bug
• Nouvelle fonctionnalité
• Nouvelle appli
• Mission de recherche
• Optimisation des performances

N'oubliez pas que cette liste d'options n'est pas limitée à.

Dans ce cas, nous devons décider quel type de travail vous attend. Ceci est important car cela affectera directement le type de travail que vous ferez.

Cette étape est particulièrement importante avec des exigences floues, par exemple: "Nous avons besoin d'un moyen de vider nos caches clients d'une manière ou d'une autre après la mise à jour du site."

Voici quelques interprétations possibles de cette exigence.

1. Vous devez rapidement implémenter un certain mécanisme pour vider le cache, de telle sorte que les clients reçoivent toujours les mises à jour les plus récentes.
2. Il est nécessaire d'étudier toutes les façons de stocker ces caches clients et de déterminer la ou les meilleures options pour se débarrasser de ces caches après chaque mise à jour du site.
3. Les caches clients devraient déjà avoir été effacés et vous devez rechercher et corriger un bogue qui empêche cela.

À ce stade, si vous n'êtes pas absolument sûr de la signification de l'interprétation, vous devez demander des éclaircissements et ensuite seulement continuer à travailler.

Formulez l'essence du problème sous la forme d'une ou deux déclarations simples.

Résumez l'exigence complexe, comme si vous répondiez à la question "sur quoi travaillez-vous aujourd'hui?" Ce n'est peut-être pas si simple, mais vous devriez essayer de réduire l'essence du problème à une ou deux phrases.

Si le résumé de la tâche de cette manière échoue, cela peut signifier qu'elle doit être divisée en plusieurs sous-tâches. En principe, cette étape se transforme en test décisif, indiquant si vous avez réussi à organiser vos tâches sous la forme de fragments suffisamment petits.

Voici un bon exemple d'un tel résumé: "Lors de la mise à jour d'un site, nous attachons un numéro unique aux fichiers, afin que le navigateur comprenne qu'il doit utiliser la dernière version du code."
Cette tâche a réussi le «test décisif» pour la simplicité et, peut-être, il n'est pas nécessaire de le diviser en fragments plus petits.

Et voici un mauvais exemple: «Lors de la mise à jour d'un site, nous attachons un numéro unique aux fichiers, de sorte que le navigateur comprend qu'il doit utiliser la dernière version du code. Nous devons également envoyer un message à notre CDN, le notifiant ainsi de la nécessité de mettre à jour les fichiers. Il faudra également prévoir que les applications pour iOS et Android envoient une mise à jour au marché des applications. Plus ... "

Dans ce cas, le test est définitivement un échec. Beaucoup de travail est nécessaire et peut-être chaque tâche doit-elle être identifiée et suivie séparément.

Mettre en évidence les détails critiques

Maintenant, vous devriez (sous forme libre, la plus pratique pour vous) faire une liste des principales choses à faire.

Encore une fois, cela devrait être des compressions très simples de chacune des étapes principales.

Ce n'est pas un guide de dépannage pas à pas ou détaillé.

N'oubliez pas que tout en continuant d'analyser la tâche qui vous est assignée. À ce stade, je recommande de prendre des notes écrites. Personnellement, j'utilise pour cela l'application Notes.

Notre tâche de mise en cache est très simple et, très probablement, il n'est pas nécessaire de la décrire de cette façon. Regardons un exemple plus complexe dans ce cas.

Notre prochaine tâche est de réaliser une nouvelle opportunité: «Chaque utilisateur devrait recevoir une publicité ciblée de notre produit interne. Cette annonce doit être adaptée aux besoins de l'utilisateur en fonction des données que nous collectons. "

Afin d'isoler les principaux éléments de cette tâche, nous devons clairement imaginer ce qui doit être fait pour implémenter chaque élément.

• Nos publicités existantes devront être distribuées de manière à être en corrélation avec certains paramètres utilisateur spécifiques.
• Pour notre service marketing, nous devons fournir une méthode qui nous permettrait de corréler les nouvelles publicités avec une ou plusieurs données utilisateur (dans ce cas, les marketeurs ne devraient rien programmer!)
• Le système devra regrouper les paramètres utilisateur pertinents dans le cadre de notre publicité.
• Enfin, vous devez créer une sorte de système qui recevra un ID utilisateur et affichera des publicités.

La beauté de ces listes est qu'elles peuvent être rapidement convenues avec l'équipe ou le patron! Donc, dans cet exemple, vous pouvez montrer cette liste à votre chef d'équipe, et il a décidé qu'un autre point très important manquait dans la liste:

• Les utilisateurs devraient pouvoir nous dire qu'ils ne veulent plus voir certaines annonces.

Après tout, à la fin, la dernière chose que nous voulons ennuyer, ce sont nos utilisateurs préférés! En prenant le temps et en réfléchissant à la tâche pendant quelques minutes supplémentaires, nous nous épargnerons des heures et des jours de problèmes à l'avenir. Il est donc important de formuler et de planifier une tâche importante, puis de passer au code.

Avant de poursuivre, je voudrais répondre à vos éventuelles critiques.

Peut-être pensez-vous: «Dans une entreprise normalement livrée, ce type de travail doit être effectué avant que les exigences ne soient mises sur la table pour le développeur» - et je suis entièrement d'accord avec vous!

Cependant, malheureusement, notre monde est imparfait. Parfois, les exigences qui incombent au développeur ne sont en aucun cas énoncées sur les étagères. Par conséquent, nous devons tout mettre en œuvre pour évaluer correctement les exigences avant de nous lancer dans le développement.

Identifiez le (s) problème (s) que vous essayez de résoudre.

Répondez à la question: «pourquoi quelqu'un devrait-il utiliser cela?» ou "Quel est le problème réel ou perçu que j'essaie de résoudre dans ce cas?"

J'espère que la réponse est évidente. Dans notre premier exemple, donné ici, la réponse est: "les utilisateurs verront toujours les dernières mises à jour." Dans le second cas, avec la publicité, "les utilisateurs verront toujours les notifications pertinentes, pas celles qui ne les intéressent pas".

L'utilisation de ces deux réponses devrait être évidente! Une compréhension plus approfondie de la tâche et de ses objectifs vous permet de prendre des décisions plus raisonnables et d'effectuer une telle mise en œuvre qui répondra correctement à vos objectifs commerciaux. S'il est possible d'identifier des solutions médiocres et des tâches dénuées de sens, il sera possible de ne pas perdre de temps et d'énergie dans des recherches qui, par définition, ne permettront pas de résoudre le problème.

Deuxième étape: interpréter et évaluer les exigences

À ce stade, vous devez déjà imaginer ce que vous devez faire et pourquoi.
Ensuite, vous devez comprendre les détails de ce que vous allez faire, comment vous allez le faire et pourquoi vous le ferez de cette façon.
Éliminez les termes importants liés à votre tâche.

Cette étape est probablement plus importante pour un développeur novice faisant partie d'une équipe, ou si vous travaillez dans une grande entreprise. Dans ces deux situations, il est très probable que vous rencontriez des termes inconnus dans les exigences.

Il peut s'agir de concepts commerciaux, tels que les noms de produits, les clients ou les processus. Il peut y avoir des termes liés au développement - par exemple, les noms d'outils, d'applications, de modèles, de services ou de bibliothèques.

Vous devez vous assurer que vous comprenez tous les termes importants de manière absolument claire, afin de pouvoir être sûr que vous exécutez correctement la tâche.

Peut-être que vous comprenez déjà que vous devez inventer un moyen d'accéder aux informations agrégées sur les utilisateurs, mais comprenez-vous ce que signifie «l'ajouter à dao»?
Vous comprenez probablement que vous devez formater les données publicitaires, mais avez-vous une idée de ce qu'est le «MADF» (balisage pour les flux d'actualités publicitaires)?

Je ne comprends ni l'un ni l'autre.

C'est pourquoi vous devez isoler et définir tous les termes importants. Se confondre dans les définitions est la bonne façon de résoudre un problème de manière incorrecte.

Décidez comment la tâche doit être effectuée.

À ce stade, vous devez déjà déterminer comment la tâche sera exécutée. Les détails de ce processus peuvent varier considérablement selon l'endroit où vous travaillez et la tâche spécifique qui vous est assignée.

Dans certaines équipes, personne ne vous expliquera exactement comment mettre en œuvre les exigences, ils diront simplement quelles fonctionnalités devraient être obtenues en sortie.

Dans d'autres, chaque étape que vous franchissez sera détaillée.

Très probablement, vous vous retrouverez dans une sorte de situation intermédiaire.

Si l'équipe ne vous a pas fourni d'instructions, à ce stade, vous ne pourrez presque rien faire. Si vous avez reçu des instructions, commencez à vous familiariser avec les étapes que vous devez franchir.

Cette étape semble tout à fait naturelle, mais il est important de faire attention à l'ordre exact dans lequel nous procédons.

Naturellement, nous aimerions plonger dans tous les détails de la tâche à la fois et les étudier jusqu'à ce que l'objectif que nous nous fixons nous soit parfaitement clair.

Cependant, puisque vous avez déjà pris le temps de comprendre le problème, vous devriez maintenant avoir une idée plus claire de l'ensemble du problème, en évaluant les étapes à suivre pour y parvenir.

Déterminez si les tâches sont traitées.

À ce stade, les étapes de l'analyse et de l'interprétation se confondent. Dans la phase d'analyse, vous vous concentrez sur une image globale et des objectifs à grande échelle - ce que nous faisons et pourquoi.

Dans la phase d'interprétation, concentrez-vous sur les détails - comment nous le faisons.

La deuxième étape est appelée «interprétation et évaluation», car maintenant vous pouvez corréler «comment» et «quoi et pourquoi». Vous interprétez les détails sur la base de l'image globale. Vous évaluez les détails et déterminez si le problème d'origine a été résolu.

Demandez-vous: les étapes que l'on m'a demandé de mener mèneront-elles au résultat, qui a été désigné comme le but ultime de la tâche? Le résultat prévu résout-il vraiment le problème d'origine?

Si vous êtes sûr que tous les problèmes peuvent être résolus et que les détails sont significatifs, alors vous pouvez vous mettre au travail! Sinon, il faut passer à la troisième étape pour résoudre toutes sortes de conflits.

Troisième étape: nous abordons le problème de manière critique

À ce stade, vous devriez être en mesure d'affirmer en toute confiance que vous comprenez à la fois la tâche et la solution. Reste à savoir si cette décision est correcte.

Pour créer un produit de la plus haute qualité, nous devons tous être en mesure de prendre nos responsabilités et de s'exprimer si certaines choses sont clairement erronées.

D'un autre côté, nous n'allons pas faire de réclamations inappropriées. On ne peut pas dire que quelque chose ne va pas, car "il semble que oui" ou simplement "pas comme". Des arguments concrets et bien conçus doivent être avancés.

Donc, nous décrivons les règles de base du désaccord compétent

Savoir quand être en désaccord

• Le désaccord est inacceptable, jusqu'à ce que je comprenne le problème à fond.
  Dire "c'est faux" n'est possible qu'avec une certitude absolue que vous comprenez ce avec quoi vous n'êtes pas d'accord /
  Si vous ne pouvez pas formuler en toute confiance un problème et une solution planifiée, vous ne pouvez pas être en désaccord. Si vous n'êtes pas sûr de tout comprendre correctement, vous ne pouvez pas être en désaccord. N'étant sûr que vous comprenez le problème dans les moindres détails, vous pouvez vous permettre d'être en désaccord.
  Si vous sentez que vous ne disposez pas de toutes les informations nécessaires, il peut être temps d'arrêter et de revoir toutes les étapes qui ont été effectuées avant de prétendre que les exigences sont incorrectes.
• On ne peut qu'être d'accord pour des raisons subjectives. Recherchez de véritables problèmes potentiels.
  «Je n'aime pas comment cela se fait» est un jugement subjectif. «Cela entraînera des problèmes de performances car de nombreuses opérations sont impliquées» est une raison objective. Exemples d'autres raisons subjectives: «Et sur un autre projet, nous l'avons fait différemment» ou «J'aurais implémenté cette solution un peu différemment, mais cela, bien sûr, est une question de goût.»
• Vous devriez avoir des explications bien pensées prêtes à appuyer vos réclamations.
  Si vous ne pouvez pas expliquer pourquoi quelque chose ne va pas - pouvez-vous être sûr d'avoir vraiment raison? Je vous conseille d'écrire les raisons pour lesquelles la décision vous semble erronée et de formuler comment elle peut être corrigée.

Si vous ne pouvez pas proposer une telle solution, dites-le-moi clairement dès le début.

Soyez prudent lorsque vous n'êtes pas d'accord avec les autres. Il faut beaucoup de temps pour écouter tout le monde et tout comprendre - et alors seulement vous ne pouvez pas être d'accord.

Si jusqu'à ce point vous avez soigneusement respecté toutes les étapes décrites, il est très probable que vous maîtrisiez tout. Cependant, essayez de ne pas vous enfermer dans vos calculs - vous auriez pu manquer quelque chose!

J'aime commencer la discussion avec les mots: "Non pas que je ne sois pas d'accord avec vous, je ne comprends tout simplement pas encore." Plus tard, si nécessaire, un fort désaccord peut être exprimé, mais pour commencer - pour le comprendre.

Savoir comment être en désaccord correctement

Afin de garantir que notre désaccord sera objectif, nous prendrons un certain nombre de mesures qui nous aideront à comprendre si nos arguments sont légitimes.

Le désaccord objectif nous permet de démontrer au moins un des faits suivants:

• La décision n'est pas bien informée
• La décision est mal informée
• La tâche ou la solution est illogique
• La solution est incomplète

Le manque d'informations n'est pas un motif de ressentiment; cela signifie simplement que lors de la création de la solution, vous venez de données incomplètes. Peut-être que les rédacteurs des savoirs traditionnels ne connaissaient pas le système déjà existant, capable d'effectuer les actions nécessaires.

Être mal informé signifie créer une solution basée sur des informations incorrectes.

Il s'agit d'un cas où, de l'avis des rédacteurs des savoirs traditionnels, le système existant peut faire quelque chose, mais en réalité cette possibilité n'y est pas prévue. Par exemple, l'équipe SEO vous a demandé que Google indexe la page avec le compte utilisateur dans votre application. Google ne peut pas faire cela. Cela signifie que votre seokhniki comprend mal les fonctions du robot de recherche Google.

Une tâche illogique ou une solution illogique n'a tout simplement aucun sens. Un exemple typique (du point de vue du développeur) est d'implémenter une fonctionnalité qui supprimera une autre fonctionnalité. Une telle exigence peut être considérée comme illogique, car elle est plus susceptible de nuire que d'aider.

La solution est incomplète, et parfois elle est faite exprès. Dans le développement de logiciels, nous essayons souvent de créer MVP (produit minimum viable) pour commencer. Cela signifie que lors de la première opération, vous pouvez intentionnellement retarder la mise en œuvre d'une fonctionnalité qui n'est pas absolument nécessaire.

En fait, une décision ne peut être considérée comme incomplète que si elle ne résout pas le problème qui vous est posé ou si les étapes ci-dessus ne suffisent pas à créer un produit réalisable ou une opportunité à part entière.