Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pas d'accord avec ça. N'as-tu jamais vu de contrat en alternance dans ton entreprise, des apprentis ? Ils sont étudiants et ont leur place en entreprise, puis il faut bien commencer un jour.Envoyé par cs_ntd
Tu as donc commencé ton travail dans le développement en étant directement expérimenté, sans passer par la case débutant ? Intéressant !
Sinon je vois une règle manquante, ma numéro 1:
- Un papier, un crayon et de la réflexion !
Moi ces règles ne me paraissent pas déconnante à partir du moment ou elles ne sont pas la pour devenir des règles permanente de codage, mais seulement pour acquerir des bases pour programmer.
Alors certes, elles ne sont pas adapté au travail, mais elles sont surtout la pour apprendre un certains nombre de règles de programmations...
La première et la deuxième sont à mon sens une façon d'apprendre à aérer son code et à le structurer. découper autant en fonction apprend aussi justement à le faire de façon intelligente et oblige à écrire un programme non pas d'une traite, mais en y pensant avant.
la troisième et quatrième sont la, pour moi, pour que le programmeur puisse ce concentrer sur la façon de réfléchir lorsqu'on programme et permet d'acquérir la logique nécessaire à toute programmation. l'utilisations de fonctions particulière a un langage, ou l'utilisation de fonctionnalité non connu ne peut à mon avis être qu'un frein par la suite... on perd aussi l'accès a la logique informatique vu que le boulot est prémaché.
La cinquième est la pour obliger a réflechir et à apprendre. Le fait de comprendre une fonction et son rôle ne permet pas toujours de comprendre les difficultés qu'on peut parfois rencontrer sur des minuscules détails. Le fait de réécrire les choses laissent la place à la possibilité de faire des erreurs, et je pense qu'on apprend mieux de ses erreurs que d'un joli cours théorique.
La Sixième est a mon avis la pour réduire le champs de travail au départ... il vaut mieux que pour commencer un programmeur sache faire les bases avant de ce lancer dans des concepts vraiment complexe ( même si plus valorisant intellectuellement)
Quand a la septième, elle est a mon avis juste la preuve de ce que j'avançais au début de ce sujet : ces règles ne sont la que pour apprendre à programmer, pas pour devenir des règles absolues à appliquer toute sa carrière.
Personnellement, je bosse dans un milieu ou beaucoup de personnes qui n'ont que des notions de programmation écrivent quand même des bout de code (la joie des macro sous Office).
Je ne suis pas à l'origine programmeur non plus, mais je me rend compte avec le temps que ces règles même si apparement pour certains d'entre vous programmeur de formation et de métier semblent inutile, moi elle me parraissent formatrice et je pense qu'elles risquent de me servir prochainement.
Bravo l'ouverture d'esprit professionnelle. Tout comme le suggère Reward, les contrats d'apprentissage, les stages, ça sert à quoi? Justement à ça, à apprendre.
Faut arrêter l'idée de l'informaticien auto-didacte qui apprend dans sa piaule comme un gros galérien et qui est apte à aller en entreprise ensuite. C'est pas professionnalisant comme comportement.
Comparez la qualité et le prix du matériel de bricolage ou de maison avant d'acheter : MatosMaison
Le boutonne masse pas les pieds, mais ça aide la communauté.
Règle 1: Soyez KISS (Keep It Simply Stupid) Une méthode doit faire une seule opération unitaire mais la faire bien. Une opération unitaire ne doit pas nécessiter plus de 50 lignes de codes commentées
Règle 2: Soyez DRY (Don't repeat yourself) On évite absolument le copier coller, l'héritage et les interfaces existent pour cela
Règle 3: Réfléchissez à ce que vous allez faire, à ce que vous faites et réfléchissez à comment vous pourriez faire si vous aviez à refaire ce que vous êtes en train de faire :-)
Règle 4: Relisez votre code de la veille si vous en avez le temps. Vous serez surpris de voir comment ce qui était "évident" la veille peut paraître obscur le lendemain (alors imaginez pour un autre développeur) => DOCUMENTEZ (JavaDoc, PHPDoc, CsDoc ...)
Si tu ne sais pas faire, apprends. Si tu fais, fais bien. Si tu sais bien faire, enseigne.
Mieux vaut paraître stupide quelques temps que rester stupide toute sa vie.
la limite en lignes de code dépend du langage, et il existe des exceptions, mais tant qu'on peut, oui, il faut garder les choses simples. Je vais rajouter un autre point KISS qui va sans doute me valoir d'autres cotes négatifs : même quand on est expérimenté, il faut limiter l'usage des ordres exotiques.
Parcequ'on peut toujours avoir un gnou comme successeur, et que même un gnou doit pouvoir s'en sortir avec ce qu'on lui laisse. Si on fait un truc magnifique, élégant, hyperefficace, mais que seuls les meilleurs peuvent comprendre, ça finira à la poubelle dès qu'on aura le dos tourné. Je sais, c'est atroce. Ca m'est arrivé une fois. Pas deux.
+1. Pas tellement parceque ça permet de faire un "meilleur" code(c'est toujours subjectif), mais parcequ'à la maintenance, si on a le même IF à 15 endroits différents, ça fait 15 maintenances au lieu d'une.
ça, ça dépasse largement l'informatique.
amen.
encore une fois, le commentaire ne doit pas reprendre le code. D'aucuns ici ont adopté la doctrine sexycoder du "code ne doit pas avoir besoin de commentaires". Moi aussi. Mon code ne doit pas avoir besoin de commentaires pour être compris et analysé. Pourtant, je mets quand même des commentaires. Pas pour dire ce que fait le code(puisque il n'en a pas besoin, on est d'accord), mais pour expliquer le contexte. Comme ça, le gugusse qui arrive derrièrer et qui essaye de comprendre un plantage, il sait, sans même regarder le code, si c'est là qu'il faut qu'il cherche ou pas.
Après, si j'ai bien codé, il saura tout de suite ce qui cloche. C'est le sens de la démarche sexycoder. Mais tant qu'il ne sait pas ou chercher, mon code a beau être parfait, il s'arrache les cheveux. Aucun code ne sera aussi rapide à lire qu'une ou deux phrases en bon Français(ou Anglais quand on bosse dans une boite internationale).
Quand en plus le commentaire en question est repris dans la doc, c'est Byzance.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Savoir prendre du recule et s'auto critiquer.
Il y a un piège très facile qu'un débutant ne doit pas entrer. Le moment ou ils commencent à comprendre les choses et de là, des idées arrivent dans tout les sens. Le débutant commence à vouloir tout automatisé, trop automatisé. Ils passent un grosse soirée fumer du code. Le lendemain matin c'est la gueule de bois et il se dit. "Mais qu'est-ce qu'il m'a prit à faire ça...
Donc :
- Rester humble sur son code
- Accepter la critique des autres
- Se remettre en cause
- Ne pas commenter l'inutile.
Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...
Mouais
Rien que l'utilisation du mot "procedure" me glace un peu le sang...
Et 6 mois sans utiliser les particularités du langage, tout ça dans le but de "training you in the use of a programming language"... Un peu contradictoire non ?
Sinon les règles autour de DRY (overlapping, copier-coller...) sont assez saines.
Je suis plutôt d'accord avec ces règles mais il faut avant tout du pragmatisme.
Concernant la taille des méthodes, il faut pouvoir voir la fonction dans son ensemble d'un seul coup d'oeil donc la limite pour moi est l'écran.
Ensuite, effectivement les débutants ne devraient pas trop expérimenter dans le cadre du travail. Bien sûr que ça lui fait apprendre mais c'est un risque de mal utiliser une fonctionnalité ou d'introduire des limitations ou des incompréhensions du fait d'une inexpérience du développeur.
Le copier/coller sans comprendre j'en souffre en ce moment sur mon projet où je vois des tas de classes copiés d'anciennes classes avec des portions énormes de code commentés ou de paramètres non utilisés.
Mais le plus important en fait c'est qu'un débutant on l'encadre. On lui laisse pas faire son programme pendant 3 semaines avant de venir lui dire qu'il est à la bourre parce qu'on a dépassé la date de livraison.
Par ailleurs, sur un projet respectable, il y a des normes de développement mises à jour et que tout le monde doit avoir lu!
- Mettre du commentaire UTILE.
- Le plan d’exécution doit être préparé avant le codage (dans la tête ou sur papier selon la taille de la tâche à effectuer).
- Comprendre ce que l'on fait ! (combien de fois j'ai pas entendu : "oui heu la fonction là elle marche plus heu elle fonctionnait toujours avant).
- Toujours se remettre en question. Cette phrase me fait bondir : "non ca marche sur mon poste, ca doit marcher chez eux!"
Dans ce que je vais dire, je me met dans le lot
Au lieu de sans arrêt nous comparer
Au lieu de sans arrêt créer des groupes et de toujours se placer dans celui qui nous arrange
Au lieu de sans arrêt édicter des lois, des règles
Au lieu de sans arrêt gueuler démontrer qu'on a raison et que beaucoup d'autres ont tort.
Et si on essayait de donner des exemples de code précis ?
Et si on essayait de donner un lien vers un projet bien codé ?
Et si on essayait de donner des liens vers des sources considérées comme des références ?
Et si on essayait d'appuyer un peu ce que l'on dit sur du concret plutôt que sur des déclarations du type : "Moi je fais comme ci, et je pense que c'est pas mal parce que les autres font comme ça et je pense que c'est pas bien"
Bref, franchement ces super développeurs qui postent sur leur blog leur super guidelines comme si c'était des paroles d'évangiles et surtout la "one best way"...ça commence à me gonfler
Donnons des ressources, des vraies ! Et pas des listes de bonnes intentions !
Qu'en pensez-vous ?
Tous simplement quand on est avant minuit.Je n’ai jamais compris cette règle. À quel moment n’est-on pas après minuit ?
Gremlins étant plus proche de la comédie et de la parodie, je doute fort qu'il existe une réponse cohérente à la question.
"tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"
Il faut éviter la surcharge de commentaires ! Cela reviendrait à rendre illisible le code.
Alors je ne suis pas d'accord avec toit sur le "plutôt que" car je ne vois pas en quoi faire du TDD t'empêche de réfléchir en amont au lieu de foncer dans le code ni te garantie un code facilement compréhensible par les autres, ce qui pour moi sont des prioirités.Pour drHelmut : plutot que de leur demander de planifier en amont, fait leur faire du TDD : un cas, un test, un bout de code. ça prends autant de temps que la conception que tu leur fais faire, mais bonus : le code est valide du premier coup
le TDD j'adhère, mais c'est un luxe qu'on ne peut pas s'offrir avec les délais qu'on nous impose. (ou plus exactement les chefs de projets ne veulent pas perdrent de temps avec ça, quitte à se payer des regressions horribles en pleine recette...)
On a une petite branche R&D qui devrait elle utiliser à fond le TDD, mais ce n'est pas moi le responsable... ;-)
Etant jeune développeur je m'évertue à suivre quelques règles assez simple et dont certaines ont déjà été énoncé.
- A savoir, une relecture du code fait la veille (surtout si j'y ai passé du temps et que mon cerveau à surchauffé).
- Le nommage de mes mes méthodes et variables le plus clair possible.
- Des commentaires de contexte (genre pourquoi je me désabonne d'un événement temporairement) parce que je sais que tôt ou tard quelqu'un reprendra mon projet.
- Et puis beaucoup de lecture et de recherche, ainsi que de la veille technologique pour me maintenir à niveau.
Mais ma règle principale est de toujours m'éclater dans ce que je fais, je pense qu'avec ça, suivre les autres règles et beaucoup plus aisé.
Un sage se distingue des autres hommes, non par moins de folie, mais par plus de raison.
Emile-Auguste Chartier, dit Alain
J'en pense que :Bref, franchement ces super développeurs qui postent sur leur blog leur super guidelines comme si c'était des paroles d'évangiles et surtout la "one best way"...ça commence à me gonfler
Donnons des ressources, des vraies ! Et pas des listes de bonnes intentions !
Qu'en pensez-vous ?
> à partir du moment où les mecs postent sur leur blog, je ne vois pas bien qui ça peut déranger dans la mesure où ceux qui viennent consulter ce blog... consultent ce blog.
> qui a parlé de paroles d'évangile ?Chacun essaie de confronter ses propres "règles" à celles des autres pour les partager et les améliorer si possible.
> des ressources des vraies ? Il y a tout le reste de developpez.com et developpez.net ! Si tu veux éviter les règles générales et les conseils sur les bonnes pratiques, évite les thread qui s'appellent "Quelles règles les programmeurs débutants devraient-ils toujours respecter ?" et tout ira bien
Ne pas non plus oublié d'indenter son code. Surtout si on souhaite le faire corriger par une personne plus expérimenté. Si l'on travail à plusieur définir des règles d'indentations strictes.
Tout à fait d'accord.
Quand je commence un projet sous Eclipse, une de mes premières étapes est de définir les formatters.
Ainsi quand on crée une classe et qu'on a directement les règles d'indentations automatiques, le squelette JavaDoc avec les tags SVN avec de vrais TODO qui laissent une liste de tâches sur sa vue Eclipse =>
1) On n'a pas à se prendre la tête avec l'indentation
2) On ne peut pas dire "J'ai oublié de remplir la JavaDoc" ou "Dans le mail que t'as envoyé, le copier-coller de ton source, c'était quel révision ?"
Si tu ne sais pas faire, apprends. Si tu fais, fais bien. Si tu sais bien faire, enseigne.
Mieux vaut paraître stupide quelques temps que rester stupide toute sa vie.
[QUOTE=Michael REMY;5996108]la régle n°1 pour le débutant : C O M M E N T E R !
Pas du tout d'accord ! Le but de faire des procédures courtes est justement qu'elles soient compréhensibles en un (bon, deux) coup(s) d'oeil, et que le nom de celle-ci oriente la compréhension de son action. Du coup, les commentaires deviennent inutiles, et tant mieux, car c'est ça de moi à maintenir lorsque le code évoluera (et il évoluera, on parle de dév débutant là ;-)
Par contre, on voit bien qu'on vient de chez Microsoft, il manque une règle essentielle :
Règle n°0: Tester son code avec des tests unitaires !
Bonjour, je suis un gros troll.
Plus sérieusement, tout comme commenter, tester unitairement son code est une telle évidence que l'auteur n'a pas vu l'utilité d'en parler pour aller à d'autres règles "importantes" mais peut-être moins évidentes.
Comparez la qualité et le prix du matériel de bricolage ou de maison avant d'acheter : MatosMaison
Le bouton
+1000
Dans cet ordre d'idées, j'aime bien la série des Dear Junior qui est plutôt bien documentée et évite les truismes de 2 lignes à l'emporte-pièce.
Après en même temps, sur la bonne façon de débuter en programmation on va avoir du mal à trouver des liens ou exemples pertinents de choses qui sont en production dans la vraie vie... Mais c'est vrai qu'il est toujours plus facile de troller sur des généralités que de retrousser ses manches et se plonger dans un débat sur du vrai code
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager