Discussion :

[Sharkou]

Bonjour à tous !

Je crée ce topic aujourd'hui car j'ai un léger problème : n'ayant pas fait d'études en informatique, je n'arrive plus à progresser ni à situer mon réel niveau dans ce domaine...

J'ai commencé à apprendre la programmation assez jeune en autodidacte, vers 14 ans (j'en ai 23 aujourd'hui). Bien sûr, je n'ai pas toujours été très régulier dans mon apprentissage, mais globalement, je pense avoir un niveau plutôt correct.

Le problème étant que j'ai l'impression de stagner, de ne plus pouvoir avancer lorsqu'il s'agit de comprendre les « fondamentaux de l'informatique ». J'ai beau apprendre de nouveaux langages, découvrir de nouvelles technos ou pratiquer continuellement, il y a un gouffre qui m'obstrue le chemin.

Par exemple, utiliser Electron avec Node.js pour développer des applications multi-plateformes ne me pose aucun problème, mais dès qu'il s'agit de comprendre comment ce framework fonctionne réellement (à bas niveau j'entends) pour pouvoir le modifier ou mieux, en créer un similaire (et plus léger !), je suis bloqué et je ne sais pas comment m'y prendre ni par où commencer... Pourtant, le dépôt GitHub est disponible, et je sais grosso modo que ça utilise le moteur V8 en interne, mais je reste devant les sources comme un demeuré ne sachant pas où regarder...

D'où ma question initiale : comment s'améliorer suffisamment en informatique pour être en mesure de comprendre comment tout cela fonctionne ? Qu'est ce qu'il me manque pour progresser (c'est peut-être seulement de la persévérance je ne sais pas trop...) ? Où chercher les bonnes informations ?

Voilà j'espère que vous pourrez m'aider à y voir plus clair

Je vous remercie par avance pour vos réponses !

[gangsoleil]

Bonjour,

J'ai l'impression, mais je ne suis pas certain, que ce qui te manque touche plus à de l'architecture ou de la conception logicielle qu'à des compétences liées au langage. Est-ce que tu as essayé de voir si tu trouvais des ressources sur ces sujets ?

[Sharkou]

Merci pour ta réponse !

Peut-être qu'il me manque des notions en architecture effectivement...
Qu'entends-tu par là exactement ?

En conception logicielle je ne pense pas car je m'étais beaucoup documenté à ce sujet il y a un moment (phases d'analyse fonctionnelle et de conception, méthodes de modélisation avec UML etc...)

Autrement si tu as des ressources je suis preneur !

[gangsoleil]

Bonjour,

Trouver le point d'entrée d'un programme juste en regardant le code, c'est sûr que c'est particulièrement indigeste, et que tu risques de passer des heures/jours à comprendre ce qu'une bonne spécification t'expliquerait en 5 minutes. Exemple à la con, mais si je te file un client/serveur qui échange des données via socket, tu risques de devoir descendre pas mal dans l'implémentation pour voir que le client et le serveur échangent par socket, alors qu'un schéma simple de déploiement te montrerait le tout en 2 minutes.

Essaye de te baser sur ces documents de conception, c'est souvent un meilleur point d'entrée que le code pour tout ce qui est haut-niveau. En revanche, pour ce qui est bas-niveau, le code est sa propre documentation.

[el_slapper]

Très bonne question sur un sujet très important.

Mon estimé collègue a, à mon sens, entièrement raison :

Trouver le point d'entrée d'un programme juste en regardant le code, c'est sûr que c'est particulièrement indigeste, et que tu risques de passer des heures/jours à comprendre ce qu'une bonne spécification t'expliquerait en 5 minutes. Exemple à la con, mais si je te file un client/serveur qui échange des données via socket, tu risques de devoir descendre pas mal dans l'implémentation pour voir que le client et le serveur échangent par socket, alors qu'un schéma simple de déploiement te montrerait le tout en 2 minutes.

C'est pour ça que les vieilles applis dont on a perdu la doc sont un cauchemar à maintenir/remplacer. Perso, j'ai eu à refondre une applis de 36 ans d'âge, et j'ai mis un mois juste à rétro-documenter de manière exhaustive un vieux clou de 5000 lignes. Aurais-je eu la spec initiale, ça aurait été bien plus rapide(il aurait quand même fallu le faire, ne serait-ce que pour voir les écarts que la vraie vie a mis entre la spec et le réalisé, mais ça aurait été torché en quelques jours).

Essaye de te baser sur ces documents de conception, c'est souvent un meilleur point d'entrée que le code pour tout ce qui est haut-niveau. En revanche, pour ce qui est bas-niveau, le code est sa propre documentation.

Voilà. les deux niveaux sont essentiels pour comprendre ce qui se passe. Exemple hors informatique. On veut créer un pont sur le fleuve Soupopoaro, entre San Cerveza et Piranha Ciudad. La conception de haut niveau, c'est par exemple de décider qu'il faut un pont à haubans avec 3 piliers, et qu'on le fera partir du sud de la Rocade de San Cerveza, pour arriver en plein centre de Piranha Ciudad. La conception de bas niveau, c'est de dimensionner les 58 haubans, l'enfoncement des piliers de béton, lechoix des boulons, etc..... La fabrication, c'est de couler le béton et de monter les ferrailles. L'exploitation, c'est quand les véhicules passent sur le pont.

En informatique, la conception de haut niveau, c'est ce qu'on retrouve dans les spécifications techniques générales(ou les spécifications fonctionnelles détaillées). C'est une liste complète du quoi, mais pas du comment. Le comment, c'est la conception de bas niveau, qu'on appelle aussi le code. La fabrication, c'est la compilation/build/tout ce qui va avec. L'exploitation, c'est quand le système tourne. L'impression que j'ai, c'est la même que Gangsoleil : il est plus facile de saisir, pour un projet informatique, la conception de haut niveau avec une spec. Un peu comme un plan de la zone urbaine autour du Soupopoaro permettrait de voir rapidement ou va passer le pont. Par contre, pour la conception de bas niveau, on va aller regarder les boulons directement sur place/dans le code. Le plan pourrait être trompeur,à cette échelle.

Il faut aussi savoir être humble, et accepter qu'une application complète ne rentre pas en entier dans un cerveau humain - y compris le sien. Et spécialement si un autre l'a écrite.

[Marco46]

Si tu as du temps à revendre (à 23 ans ça devrait être le cas) essaie de faire des contributions à des projets opensource d'envergure. C'est pas ça qui manque dans le monde JavaScript.

Ou écrire des plugins. Par exemple écrire des règles pour ESLint te fera toucher à beaucoup de choses que tu ne toucherais pas en temps normal et améliorera très sensiblement ta compréhension du langage. Par contre bon courage c'est un gros gros travail.

Ou encore les petits projets de démo d'outils, je pense par exemple à minipack qui est une implémentation simple d'un bundler. Ça ouvre des horizons

Pour lurker les repos et trouver des choses intéressantes les séries de repos awesome sont de bons points d'entrées.