Comment gérez-vous la compréhension de l'abstraction dans le code?
Lorsque j'examine une nouvelle base de code, j'aime partir d'une approche ascendante.
Où je comprends un fichier, puis passe à l'abstraction suivante.
Mais il m'arrive souvent d'oublier ce que fait l'abstraction de niveau inférieur.
Je serai donc à ce point où je me retrouve dans une boucle presque sans fin de revenir aux fichiers que j'ai déjà entièrement compris, puis d'essayer de les réapprendre; tout en essayant de jongler avec de nombreuses autres abstractions qui se connectent les unes aux autres dans ma tête.
Existe-t-il une meilleure stratégie pour faire face à cette situation?
Dois-je simplement oublier les détails de niveau inférieur et les prendre pour acquis? Mais même alors, plusieurs fois, une compréhension préalable de l'abstraction de niveau inférieur est nécessaire pour comprendre ce que fait l'abstraction actuelle.
La programmation est concrètement l'impulsion de tirer les détails vers vous afin que vous puissiez les clouer tous en un seul endroit. Nous commençons tous de cette façon et il est difficile de lâcher prise.
La programmation abstraite est très certainement "oublier les détails de niveau inférieur". Parfois même des détails de haut niveau. Vous repoussez les détails et laissez quelque chose d'autre s'en occuper. La chose sournoise, c'est que vous avez fait cela tout au long. Comprenez-vous vraiment ce qui se passe entre print "Hello world" et il apparaît sur votre écran?
La première chose à exiger alors que vous avez du mal à lâcher ces détails est de bons noms. Un bon nom garantit que vous ne serez pas surpris lorsque vous regarderez à l'intérieur. C'est pourquoi vous n'avez pas été surpris que print ait mis quelque chose sur votre écran et que vous vous en foutiez vraiment. foo "Hello world" aurait été une autre histoire.
De plus, les niveaux d'abstraction doivent être cohérents. Si vous êtes à un niveau qui consiste à calculer pi, vous ne devriez pas également vous soucier de la façon d'afficher pi. Ce détail s'est infiltré dans une abstraction où il n'appartient pas.
Des détails inférieurs, supérieurs ou latéraux, qui ne sont pas la seule chose à laquelle je pense à cet endroit, peuvent soit disparaître complètement, soit au moins se cacher derrière un bon nom.
Donc, si vous avez vraiment du mal à rebondir d'un fichier à l'autre, je ne pense pas que quelqu'un vous ait coincé avec de mauvais noms ou des abstractions qui fuient.
Je corrige cela en lisant avec mes doigts. Une fois que j'ai fait des tests décents autour de ce gâchis, je taquine les responsabilités, leur donne des noms clairs qui évitent les surprises et le montre à quelqu'un d'autre pour m'assurer que je ne vis pas dans un monde fantastique.
Apparemment, je ne suis pas le seul à travailler de cette façon:
Chaque fois que je travaille sur du code inconnu, je commence à extraire des méthodes. Quand je fais cela, je cherche des morceaux de code que je peux nommer - puis j'extrait. Même si je finis par intégrer les méthodes que j'ai extraites plus tard, au moins j'ai un moyen de masquer temporairement les détails afin que je puisse voir la structure globale.
En bas, il y a quelques mises à jour sur la façon dont cela s'est passé pour moi chaque trimestre de l'année, je pense qu'elles sont précieuses.
Bonne dénomination. Ou, si c'est le code de quelqu'un d'autre, essayer d'attribuer de bons noms/responsabilités basés même sur de mauvais noms sur les classes/fonctions de ce système afin qu'il fasse sens dans ma tête. Une fois cela fait, les implémentations de bas niveau deviennent beaucoup plus faciles à mémoriser.
C'est tout ce que j'ai. Il y a beaucoup de puristes sur ce site qui jureront par Dieu sait quels modèles ou objets de tous types, mais une bonne dénomination vous mènera loin. J'ai fait plus que bien moi-même en créant du code minimalement documenté/bien nommé/bien découplé et il n'est jamais revenu me mordre, même si mon code a été utilisé dans beaucoup d'endroits, par beaucoup de gens, mais le une chose que j'ai bien fait a été de perdre beaucoup de temps sur une bonne dénomination, de bons commentaires et des schémas qui expliquaient le flux de mon code. Une implémentation de bas niveau est nécessaire pour comprendre si vous souhaitez développer mon code de manière approfondie. Un code bien écrit peut être développé de manière raisonnable, il est donc normal que quelqu'un ou vous ne compreniez pas/ne vous souveniez pas des implémentations de bas niveau.
Si vous êtes intéressé par un peu de controverse que les gens de mon domaine d'origine ainsi que moi savent être la vérité, mais si vous écoutez ce qui est écrit ici, vous apprendrez à la fois à être d'accord et en désaccord avec cette réponse. , lisez la suite:
Mais il y a un autre problème ici - les puristes. Vous entendrez des réponses et des idéologies bien formulées qui sont raisonnables et tout à fait logiques, en fait, il n'y a rien de mal à cela. Mais vous n'êtes pas obligé de les suivre, en fait, ils pourraient jouer dans votre désavantage.
Mes amis ont travaillé avec de gros systèmes et ils rient juste des gens qui se soucient un peu trop des conventions et des modèles et pour une bonne raison, je le ferais aussi - je peux trouver mon raisonnement pour cela dans mon domaine principal d'analyse de données, puisque je ne suis pas un développeur aussi expérimenté: La plupart des choses que vous pensez sont importantes, peu importe et il y a une forte corrélation avec votre ego dans ce sens. Souvent, un individu, en raison de son ego, aura acquis des connaissances qu'il a très probablement mal comprises en raison de ses préjugés qui sont maintenant renforcés par une autorité qui, selon lui, vient de dire "la même chose que moi". C'est un piège très connu dans lequel vous ne devriez jamais tomber. Cela ne signifie pas qu'il ne l'utilise pas correctement ou pour le plus grand bien, mais souvent, ce que ces gens feront, c'est promettre que tout ce qu'ils disent est le prix d'or.
Alors que peux-tu faire?
Expliquez votre code à un collègue et demandez-lui si cela a du sens d'un point de vue de haut niveau.
C'est tout ce qui compte. Bien sûr, quiconque lit le code de quelqu'un d'autre aura toujours une fête de tabulation pour voir la mise en œuvre de certaines choses, mais cela n'a pas d'importance, si celui qui lit votre code a une compréhension de haut niveau de votre système et comprend "pourquoi les choses se produisent" "(encore une fois, sans nécessairement savoir pleinement" comment ils se produisent "), alors vous êtes en or.
Ce n'est pas moi qui dis d'aller de l'avant et d'écrire du code de merde qui n'est pas performant ou qui ne respecte rien, mais ce que je dis c'est:
1) C'est bon d'oublier. Avec le temps, vous améliorerez la lecture du code avec lequel vous travaillez. Si le code que vous lisez exige que vous connaissiez les implémentations de bas niveau à un bon niveau, alors c'est du code mal écrit et cela joue dans ce que j'ai dit auparavant: un collègue vous comprend-il?
2) Le monde est rempli de beaucoup de gens très intelligents qui ne sont pas très intelligents. Ils sont aussi souvent très émotifs et enclins à renforcer les préjugés des forces extérieures. Ils sont très bons dans ce qu'ils font, mais ce qu'ils oublient, en tant qu'acteurs de la diffusion de l'information, c'est que les idées/informations, même si elles sont appuyées par la "logique", ont le contexte de celle qui les envoie, ce qui est crucial pour comprendre si oui ou non cela les informations vous sont également utiles. Ce qui a du sens pour vous pourrait avoir du sens pour les autres et ils adoreraient cela, mais les informations ne devraient pas être considérées comme absolues et l'une, encore une fois, devrait considérer, ou au moins essayer de comprendre le contexte d'où elles proviennent et vérifier par rapport aux siennes. propre contexte pour voir s'il correspond. C'est vraiment la même chose que les milliardaires qui nous donnent ces "connaissances pour aller de l'avant" - il est sûrement facile de dire ce qu'ils disent, mais plus difficile à mettre en œuvre, bien sûr, c'est un exemple stupide mais vous avez l'idée.
En bref: écrivez du code compréhensible et réalisez qu'il est toujours discutable là où nous avons besoin d'autant de modèles/classes et de raffineries que certains le disent. Il y a des gens très intelligents des deux côtés de l'argument et cela ne devrait que renforcer l'idée de faire tout ce qui fonctionne pour votre équipe de manière raisonnable - ne vous limitez pas aux petits détails qui n'ont pas d'importance, vous les comprendrez plus tard, rappelez-vous, vous vivez dans un monde extrêmement compétitif où le timing est la chose la plus importante:
Timing dans le succès des startups.
Allouez votre temps et vos ressources de manière significative et gourmande.
Voici un montage, 6 mois plus tard:
Ce fut un voyage fou. Je n'ai jamais pensé que juste une séparation/une bonne dénomination et une bonne documentation peuvent fondamentalement vous permettre de brancher quoi que ce soit dans et hors de votre base de code. J'ai dû réécrire beaucoup de code pour le mettre à jour avec les nouveaux changements et j'en ai fait une bonne partie en 2-3 jours. Je peux dire en toute sécurité que je n'ai pas suivi SOLID partout en raison du manque de connaissances, ni des meilleures pratiques et je peux dire qu'ils sont dans ma dette technique, mais pas beaucoup. Séparé, bien nommer et documenter, cela vous permettra de changer le code en un rien de temps lorsque vous réaliserez à quel point vous étiez stupide.
Ne vous méprenez pas: si vous écrivez votre code étroitement couplé, vous aurez beaucoup de peine, que vous détestiez ou non SOLID, même le comprendre et l'appliquer au niveau de base permet un grand découplage qui, honnêtement, est la seule chose qui OOP aide vraiment avec. OOP était censé aussi être sur la réutilisation du code et pendant ce temps ici et là , vous n'avez pas vraiment la possibilité de réutiliser beaucoup d'objets que vous créez, alors concentrez-vous à vous assurer que votre système est bien séparé. Supposons que l'oncle Bob vienne prendre la tête de votre projet, il dira "Ok, c'est idiot comme l'enfer mais au moins tout est séparé, bien nommé et documenté donc au moins je sais de quoi il s'agit" (j'espère). Pour moi, cela fonctionne. Mon LOC change constamment, mais au moment de la rédaction, c'est 110k lignes de code, 110k lignes de code performant qui fonctionnent en harmonie pour une seule personne, c'est beaucoup.
Voici un montage, 3 mois plus tard, sur un code de 8 mois que je refactoring:
Tout cela a du sens. Je peux maintenant reprendre ce que j'ai écrit à l'époque, conceptuellement et reforger le code à nouveau, avec de nouvelles idées parce que je comprends parfaitement ce qui se passe et pourquoi cela fonctionne à cause des schémas/bons noms et commentaires. J'ai écrit du code il y a longtemps que je ne me souciais pas de bien nommer et ainsi de suite et c'est pénible à traverser. Je pense maintenant à ce que pourrait être la prochaine étape pour expliquer mon code.