Mauvaise boite, changer de boite ;)
Non je rigole.
Il faut dire qu'un BTS est tout de même très (trop?) court pour aborder les nombreuses choses a voir, et même dans des études plus longues (master, école d’ingé), c'est tout de même très difficile de tout voir.
Par exemple, j'avais utilise CVS et SVN dans des projets, mais personne ne m'a enseigne les tests unitaires, alors que j'aurais gagne un temps fou a éviter de retester manuellement les mêmes 3-4 fonctions que l'on avait développé sur le logiciel. J'avais fait su scheme (un (()langage (((LISP))()))), de l'assembleur, du C, C++, Java), mais les tests n'avaient jamais vraiment été abordés.
Les tests sont les parents pauvres de l'éducation en programmation informatique en France (et ailleurs?), et c'est bien dommage.
Bref, je peux juste te recommander de lire certains des liens qui ont circulé sur cette page, lire du Martin Fowler ("Refactoring: improving the design of existing code", j'adore :) ) ou d'autres auteurs comme Paul Graham, Jeff Atwood, Joel Spolsky, Kent Beck, Le Gang of Four (Design Patterns: elements of reusable design) etc. Lis aussi tout sur XP, c'est au moins intéressant pour les pratiques de programmation.
Le plus marrant, c'est que ces articles se contredisent parfois, et c'est la que ça devient intéressant pour que tu te questionnes et te fasse ta propre opinion. Pas toujours tout de suite, mais parfois avec le temps.
Pour finir, pratique encore et toujours, donne toi des petits defi, mais pense toujours que:
Chaque ligne de code c'est du "legacy": c'est plus un problème qu'une solution. Donc si tu peux réduire le nombre de ligne de code, c'est vraiment le mieux.
Le code est lu 10, 20 ou encore plus de fois qu'il n'est écrit, alors soigne particulièrement le code avant de le committer: demande toi si tu en as réellement finis. Doit tu ajouter des commentaires qui expliquent POURQUOI le code est tel qu'il est. Doit tu refactoriser le code? Doit tu renommer cette méthode, est que ce nom est bien choisit? Y-a-t il de la duplication, etc.
Sur ce même sujet, il te faut 2 fois plus d'intelligence pour debugger ton code qu'il ne t'en a fallu pour l’écrire, alors évite le code trop "sioux" :) et pense aussi que tous tes collègues (même les moins bons) doivent pouvoir travailler sur ton code.
Demande a des pairs plus compétents que toit de revoir ton code (pas le gars le plus nul de la boite, parce que ça passe comme une lettre a la poste) et écoute les critiques.
Bien sur, tout ça doit se faire dans le meilleur rapport temps / productivité pour corser le tout. :)
Mais je t'assure que si tu suit les conseils ci-dessus, tu vas progresser a vitesse grand V.
Et tout le monde fait des erreurs a un moment ou a un autre de tout façon ;)
[^] # Re: C'est quoi propre ?
Posté par djano . En réponse au journal Du code propre, c'est quoi ?. Évalué à 2.
Mauvaise boite, changer de boite ;)
Non je rigole.
Il faut dire qu'un BTS est tout de même très (trop?) court pour aborder les nombreuses choses a voir, et même dans des études plus longues (master, école d’ingé), c'est tout de même très difficile de tout voir.
Par exemple, j'avais utilise CVS et SVN dans des projets, mais personne ne m'a enseigne les tests unitaires, alors que j'aurais gagne un temps fou a éviter de retester manuellement les mêmes 3-4 fonctions que l'on avait développé sur le logiciel. J'avais fait su scheme (un (()langage (((LISP))()))), de l'assembleur, du C, C++, Java), mais les tests n'avaient jamais vraiment été abordés.
Les tests sont les parents pauvres de l'éducation en programmation informatique en France (et ailleurs?), et c'est bien dommage.
Bref, je peux juste te recommander de lire certains des liens qui ont circulé sur cette page, lire du Martin Fowler ("Refactoring: improving the design of existing code", j'adore :) ) ou d'autres auteurs comme Paul Graham, Jeff Atwood, Joel Spolsky, Kent Beck, Le Gang of Four (Design Patterns: elements of reusable design) etc. Lis aussi tout sur XP, c'est au moins intéressant pour les pratiques de programmation.
Le plus marrant, c'est que ces articles se contredisent parfois, et c'est la que ça devient intéressant pour que tu te questionnes et te fasse ta propre opinion. Pas toujours tout de suite, mais parfois avec le temps.
Pour finir, pratique encore et toujours, donne toi des petits defi, mais pense toujours que:
Chaque ligne de code c'est du "legacy": c'est plus un problème qu'une solution. Donc si tu peux réduire le nombre de ligne de code, c'est vraiment le mieux.
Le code est lu 10, 20 ou encore plus de fois qu'il n'est écrit, alors soigne particulièrement le code avant de le committer: demande toi si tu en as réellement finis. Doit tu ajouter des commentaires qui expliquent POURQUOI le code est tel qu'il est. Doit tu refactoriser le code? Doit tu renommer cette méthode, est que ce nom est bien choisit? Y-a-t il de la duplication, etc.
Sur ce même sujet, il te faut 2 fois plus d'intelligence pour debugger ton code qu'il ne t'en a fallu pour l’écrire, alors évite le code trop "sioux" :) et pense aussi que tous tes collègues (même les moins bons) doivent pouvoir travailler sur ton code.
Demande a des pairs plus compétents que toit de revoir ton code (pas le gars le plus nul de la boite, parce que ça passe comme une lettre a la poste) et écoute les critiques.
Bien sur, tout ça doit se faire dans le meilleur rapport temps / productivité pour corser le tout. :)
Mais je t'assure que si tu suit les conseils ci-dessus, tu vas progresser a vitesse grand V.
Et tout le monde fait des erreurs a un moment ou a un autre de tout façon ;)