Je ne sais pas ce que je ne sais pas, comment régler le problème ?

Salut,

Eh bien en lisant un autre tuto x)
Evidemment tu ne connais pas tout du langage et tu es en apprentissage, bah ça sera TOUJOURS le cas, tu ne connaitra jamais le langage puisqu’il est en constante évolution (sinon il faut l’abandonner)
C’est au gars qui a défini la fonction (Oracle qui défini le Java, ISO qui défini le C++ etc…) de fournir une documentation pour dire à quoi sert cette fonction et comment on s’en sert. Ensuite, puisque cette fonction répond à un besoin, elle va se créer une base d’utilisateur. Puis de cette base d’utilisateur se créera une communauté et enfin de cette communauté naitra des tutos.

Bah il est où le soucis ? Tu as réalisé ce qu’il y avait à réaliser. L’optimisation n’était pas critique, elle n’a donc pas lieu d’être, ou plutôt elle va couter trop chère par rapport au gain que tu vas avoir.

En restant curieux, et en prenant le temps d’e-penser
Organise une veille technologique pour te tenir au courant des nouvelles les plus récentes possibles, et réfère toi toujours au document de référence pour récupérer les informations, c’est le document le plus complet et le plus à jour qu’il puisse y avoir, souvent à défaut d’être le plus compréhensible.

Cela est le moteur de la veille technologique. http://www.linternaute.com/citation/4054/tout-ce-que-je-sais–c-est-que-je-ne-sais—socrate/

Vous devez être en permanence en connexion avec des sources d’information permettant de mettre à niveau vos connaissances.

L’histoire de la StringBuilder n’est qu’un cas parmi des centaines. Vous avez de bon cours, complets et à jour, c’est dans votre besace. Mais ce qui est vrai aujourd’hui ne le sera pas forcement demain. La veille technologique est là pour mettre tout ça à jour.

Il existe pour bien des langages des outils d’analyses statiques de code qui vous signaleront les cas de mauvaise utilisation potentielle. Et ces outils peuvent être extrêmement tatillons, et sont souvent mise à jour avec les dernières avancées des bonnes pratiques du langage.

Bonjour !

Alors, pour le fait que tu n’avait jamais utilisé/entendu parlé des StringBuilder avant, c’est que ce que tu supposes être des bonnes pratiques ne le sont pas. Enfin, ce sont des pratiques qui sont peut être adaptée en développement en général, mais chaque langage à ses propres bonnes pratiques.

JAVA est mon langage de dev principal. Je configure mon IDE en mode tonitruant, toutes les choses comme une chaîne de caractère en dur me génère une notification, toute chose partiellement définie devient une erreur au lieu d’être une notification ou un warning. Ça m’empêche principalement de remettre à plus tard, vu que ça me bloque la compilation. Comme pour tout langage, l’IDE est un soutiens non négligeable, mais il ne fait pas tout. L’expérience joue pour beaucoup. (En fait, j’ai 2 IDE, un qui gueule pour tout que j’utilise pour les gros projets visant à être partagés, et un autre plus laxiste pour les tests)

Pour les professeurs, c’est assez triste, mais il y a de fortes chances qu’ils ne connaissent pas bien le langage qu’ils enseignent non plus. Donc s’il ne montrent pas de connaissances suffisantes, ne compte pas sur eux. Pour des futurs collègues, disons que tu devras t’adapter à eux, à ce qui est déjà mis en place etc. (je ne dis pas que s’il codent mal il faille forcément les suivre).

Pour apprendre, il faut lire, expérimenter, s’amuser, creuser toujours plus. Normalement, un peu de motivation est la seule chose nécessaire (et un accès aux ressources) !

Comment déterminer le degré de qualité d’un code ?

C’est simple, l’algorithme employé doit être lisible ! S’il n’est pas évident à comprendre, on y place des commentaires… L’objectif est de réussir à suivre toutes les étapes à la résolution du problème.

Le code doit être maintenable ! Imaginons que tu souhaites modifier la ligne d’un code; cette modification ne doit pas te faire jeter l’ensemble de ton code. Donc rendre maintenable, c’est parer à quelques surprises éventuelles…

Ton code doit éviter les mauvaises pratiques et sont généralement indiquées dans des documentations dignes de ce nom… Certains termes sont dépréciés, et souvent liés à des trous de sécurité. Après quelques mises à jour, ils disparaissent, et ont comme conséquence la modification du code.

Comment voir plus loin que mes professeurs, mes collègues (le jour oú j’en aurais) ou quelque soit la personne qui puisse examiner mon code ?

Se documenter, encore et encore, lire beaucoup, essayer de comprendre pourquoi une façon est plus efficace qu’une autre, faire des tests, contrôler RAM + CPU, etc. Souvent en pratiquant, on peut soit même déterminer la meilleure manière de faire.

TL;DR: La stratégie que j’essaye (et que je te suggère) d’adopter tient en 3 mots très simples : get shit done.

Ça veut dire :

• T’efforcer à chaque instant de faire le code le plus simple (simple != facile) auquel tu puisses penser pour ajouter une valeur immédiate à ton code du point de vue de l’utilisateur.

• Préférer rendre ton code testable et écrire des tests automatiques pour les trucs importants, plutôt que chercher le raffinement ou l’élégance dans son design. À choisir, les tests garantissent que le code fonctionne, et donc qu’il sert à quelque chose, là, tout de suite ; c’est plus important qu’un design pensé pour ce à quoi ton code servira un jour, peut-être, ou pas.

• Foncer et ne pas avoir peur de faire des erreurs, dès lors que tu tires des leçons de chaque erreur que tu fais.

Parce qu’un code, tu ne connais jamais sa durée de vie. Un projet peut mourir demain. Le but de ton code est d’être utile tout de suite. Même un tout petit peu.

Ok plus en détails :

La qualité du code est un sujet super sensible. Tout le monde a une opinion plus ou moins étendue, plus ou moins partagée sur ce qu’est un code de qualité. Ce que je te conseille, c’est, au lieu de demander quoi ou comment, de revenir au pourquoi.

Pourquoi vouloir un code de qualité ?

Ma réponse serait la suivante (par ordre de priorité) :

• Pour éviter que mon soft ne pète en prod à la tronche du client ou de l’utilisateur.
• Pour ne pas du tout galérer quand je cherche à le débugger.
• Pour ne pas trop galérer si je veux ajouter, modifier ou refaire une fonctionnalité.
• Pour que d’autres que moi puissent bosser dessus.

Des deux premiers points, je déduis qu’un code de qualité est un code testé, ce qui implique qu’il soit testable. Sans être partisan du TDD ni du 100% de coverage, ton code est de qualité si c’est facile d’écrire des tests automatiques sur ses parties les plus critiques, et si ces tests sont écrits et tournent à chaque modif du code. Si c’est chiant d’écrire un test, alors il faut peut-être repenser le code.

Le troisième point demande de l’expérience : il faut éviter que le moindre bout de code dépende de tout le reste de ton programme. Dans l’idéal, tu dois pouvoir le prendre, le récrire, et le rebrancher dans le programme en n’impactant pas (ou très peu) le reste (les tests sus-mentionnés sont d’une aide inestimable pour ça d’ailleurs).

Le dernier point impose que le code soit intelligible et documenté avec des commentaires utiles qui expliquent comment le tout a été pensé et organisé.

Alors bien sûr à tout cela tu vas ajouter des détails, des bonnes pratiques, des design patterns… Qui sont tous sujets au gré du vent et à la mode (quand j’avais 25 ans, on ne jurait que par les design patterns, aujourd’hui on revient de la POO et on aime les choses KISS, hier on créait des frameworks qui faisaient tout et plus encore, aujourd’hui on ne jure presque plus que par le modulaire et le micro-service…). En réalité c’est l’expérience et tes erreurs qui priment : tu feras des erreurs, tu ne peux pas l’empêcher, mais tu peux apprendre de ces erreurs à chaque fois et c’est ça qui compte.

Cela implique aussi un truc important : il ne faut pas tomber dans le travers qui consiste à penser qu’un code doit être parfait du premier coup. Il doit fonctionner et être facile à tester. C’est tout. Inutile de se palucher une semaine sur le design pour deux heures d’implémentation : tu ne peux pas prévoir quand (ni même si) tu auras besoin d’y retoucher. L’attitude intelligente, dans ces conditions, est de faire le minimum d’efforts pour satisfaire les quatre points plus haut.

Alors avec ça, savoir qu’il existe telle classe, tel pattern, telle bibliothèque qui fait le boulot pour toi, c’est complètement secondaire. Quand tu le sais, la seule chose que ça te fait gagner, c’est du temps. Si tu le découvres alors que ton code est déjà fait, c’est pas un drame : tu le gardes sous le coude pour le jour où tu devras y retoucher. C’est inutile de faire une fixation sur ce genre de choses : ce qui compte ce sont les choix que tu fais à partir ce que tu connais à l’instant T, et les leçons que tu tires de leurs conséquences. Si tu passes littéralement tout ton temps à chercher avidement à connaître plus de choses, c’est autant de temps en moins passé à mûrir tes choix et faire les erreurs dont tu as besoin pour avancer.

Pour compléter le commentaire pragmatique de nohar auquel j’adere totalement, si ton code fonctionnait bien et sans ralentissement sans tel ou tel outil, alors c’est que l’outil n’était pas indispensable et donc ça ne servait pas à grand chose de l’utiliser, voir c’était contre productif.

Je vais donner un exemple : en Python on a une clause else pour les boucles (for et while). Bien que ce soit pratique par moment, c’est tellement inhabituel dans un code que je vais les éviter très souvent. Me faire gagner une ligne ne vaut pas le coût que va entraîner cette fonction : que moi ou les autres dev qui lisent le code y réfléchissent 5 min à chaque fois parce qu’on a pas l’habitude de lire ce genre de code.