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 souvent, je me retrouve à 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 se laisser aller.

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 entreprint "Hello world" le moment où il apparaît sur votre écran?

La première chose à exiger alors que vous avez du mal à lâcher ces détails, ce sont les bons noms. Un bon nom garantit que vous ne serez pas surpris lorsque vous regarderez à l'intérieur. C'est pourquoi vous n'êtes pas surpris d'avoir printmis quelque chose sur votre écran et que vous ne vous en souciez pas 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.

Michael Feathers - Code Orange

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 appellation.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 que cela ait du sens dans ma tête. Une fois cela fait, les implémentations de bas niveau deviennent 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 à résoudre 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 se moquent simplement 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 des 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 la connaissance qu'il a très probablement mal compris 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, toute personne qui lit le code de quelqu'un d'autre aura toujours une fête alt-tab 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 forcément 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 celui 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"

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 d'un manque de connaissances ou de meilleures pratiques et je peux dire qu'ils sont dans ma dette technique, mais pas beaucoup. Séparez, nommez bien et documentez, 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 avec laquelle la POO aide vraiment. La POO était censée concerner également la réutilisation du code et bien que cela se produise ici et là, vous ne pouvez pas vraiment réutiliser beaucoup d'objets que vous créez, alors concentrez-vous sur la bonne séparation de votre système. Une fois que vous atteignez la maturité et supposons que l'oncle Bob arrive et prend 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, ça marche. 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 devient clair. 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.