Discussion :

[Titou19]

Bonsoir,

Voilà j'aimerais progresser dans ma façon de coder. J'ai 2 ans et demi d'expérience dans le développement web, je ne suis pas bête je pense, et j'arrive au résultat, mais parfois d'une manière pas très elegante ni synthétique. Je progresse mais trop lentement à mon goût et j'ai déjà eu des remarques de mon employeur sur ce point. Pourriez-vous me donner des conseils de lecture? Je ne cherche pas à apprendre de nouveaux langages dans l'immédiat, mais plus une bonne méthodologie de codage. Je code en PHP, jquery, html, css.

Merci d'avance!

Titou

[Mat.M]

en 2 mots
1 c'est peut-être pas la bonne section ( ici c'est l'emploi)

2- pour bien coder il faut avoir un minimum l'esprit cartésien et mathématique...
il faut comprendre des théorèmes mathématiques comme la simplification de polynômes.
Mettons une expression au pif y=ax1+ ax2 +ax3...il faut en trouver une simplification
Parce que des lignes de code cela en quelque sorte ce sont des polynômes des expressions avec des variables.
3sinon pêle-mêle donner des noms de variables pertinents,initialiser toutes les variables, mettre des commentaires pertinents dans le code source..

[el_slapper]

Code comme une fille. Je suis sérieux. Se mettre dans la peau d'une collégienne qui ne pourrait pas, même menacée de mort, rendre au professeur une copie qui ne soit pas impeccable en terme de présentation. C'est ce que j'essaye de faire. Toujours me poser la question : est-ce que ma fille oserait rendre un torchon pareil? Non? Alors le boulot n'est pas fini.

[phili_b]

@el_slapper

Une phrase misogyne s'est cachée dans ton paragraphe, sauras tu la retrouver ?

[tdutrion]

Si tu bosses avec PHP, regarde du côté de PHP The Right Way et PHPMentoring.org, regardes aussi les PSR et utilises phpmd (mess detector). Si tu peux fixer tes erreurs répertoriées par PHPMD tu est déjà très bon.

Regarde aussi du côté des design patterns et comment on les utilise.

[ed73170]

Avant tout, pose-toi les questions suivantes : Quelle reconnaissance vais-je en tirer ? Mon employeur va-t-il m'augmenter pour mon joli code ? Est-ce que cela va me servir pour avoir un poste plus intéressant et/ou mieux payé ?

Ensuite, tu verras s'il est pertinent de passer plus de temps sur ce qu'on te demande de faire.

[Glutinus]

Moué, je suis moyennement d'accord, c'est surtout un travail pour soi et pour le futur.
En général, et je dis bien en général, un code propre et lisible permet une meilleure maintenabilité à toi et surtout aux autres, et s'il est factorisé tu perds moins de temps. Aussi stupide que cela puisse paraître, j'avais chez un client quasiment 10 fois la même portion de code qui se répétait, et souvent des éléments techniques, c'est-à-dire "dans le cas de tel produit faire ceci", et les développeurs avaient pris l'habitude de créer une branche supplémentaire dès qu'il y avait une particularité au niveau en dessous. Mais s'il y avait un impact, il fallait tout reprendre, et ça finissait par prendre un temps fou et surtout multipliait les risques d'oublier quelque chose.

Autre exemple, sur le framework que j'utilise les performances partent souvent en vrille, mais finalement le meilleur moyen de coder c'est... de le coder comme on l'apprend en formation chez l'éditeur mais ça beaucoup semblent l'oublier !

[Carhiboux]

Humm, sans rentrer dans un débat sans fin, qu'est-ce qu'un bon code?
.
Pour le "client" c'est simplement un code qui marche, et qui réponds dans les temps.
.
Pour celui ou celle qui doit le maintenir, c'est un code dans lequel on peut rentrer rapidement.
.
Pour celui qui l'écrit... je pense qu'il y a à peu près une réponse différente pour chaque développeur sur cette terre.

Quand à l'élégance, franchement, c'est pas ce qu'on demande à un code.

Pour moi, un "bon code" c'est un code :

Qui est homogène ; et ça croyez moi, c'est compliqué quand il y a X personnes passées dessus, donc seulement X-Y ont compris les grands principes et que les Y restants ont fait... comme ils ont pu pour arriver au résultat, quitte à court-circuiter les circuits normaux.

Qui est bien découpé, techniquement et fonctionnellement : couche DAO, couche métier, MVC (ou variante), dans des packages qui sont parlant, etc...

Qui est versionné. Oui, cela contribue à faire un bon code, car on peut voir les dernières modifs, et donc éventuellement revenir dessus. Plus compliqué à faire lorsqu'il n'y a pas de versions et qu'il faut aller à la pêche au hasard.

Et on a toujours moyen de s'améliorer. Toujours. C'est bien rare que quand je relis un code écrit il y a quelques mois, je ne me dis pas que je suis vraiment trop con et que j'aurais pu faire ça beaucoup plus proprement ou élégamment autrement. Si j'ai le temps, que je dois toucher à ce composant et que cela apporte un plus, je change, sinon, souvent à regret, je laisse tel quel.

Faire de la sur-qualité à aussi un cout. et il n'est amorti que si tout le monde en fait. Or, dans une entreprise, c'est rarement le cas. En plus, le code est rarement documenté, donc ceux qui passeront sur ton code après pourraient louper des subtilités élégantes ou trop optimisées. Ça m'est arrivé il y a quelques mois, je devais implémenter des nouveaux "services" dans une architecture Apache Camel. Je suis passé derrière une brutasse technique, il a mis en place plein plein de choses, franchement, c'est très classe et c'est super bien fait. Sauf que rien n'est documenté, et qu'il communique aussi bien qu'un pelle à tarte. Du coup, j'ai perdu un temps fou à cause de cela. Alors que, pourtant, tout ce qu'il a fait était vraiment génial et aurait du nous faire gagner un temps fou. Sauf qu'il ne l'a jamais expliqué à personne...

[Titou19]

Le terme est là : code factorisé, facilement réutilisable. J'essaye de m'améliorer dans ce sens. En interne c'est sans doute la chose la plus importante je pense. Il y a un très bon développeur dans mon entreprise mais en effet on pourrait lui repprocher de ne pas mettre de commentaires..

[Mat.M]

En général, et je dis bien en général, un code propre et lisible permet une meilleure maintenabilité à toi et surtout aux autres, et s'il est factorisé tu perds moins de temps. Aussi stupide que cela puisse paraître, j'avais chez un client quasiment 10 fois la même portion de code qui se répétait, et souvent des éléments techniques, c'est-à-dire "dans le cas de tel produit faire ceci", et les développeurs avaient pris l'habitude de créer une branche supplémentaire dès qu'il y avait une particularité au niveau en dessous.

pour le problème du code qui se répète et pas factorisé suffisamment, malheureusement on semble le rencontrer souvent..on préfère travailler vite et bâcler plutôt que de bien faire les choses...

Autre exemple, sur le framework que j'utilise les performances partent souvent en vrille, mais finalement le meilleur moyen de coder c'est... de le coder comme on l'apprend en formation chez l'éditeur mais ça beaucoup semblent l'oublier !

alors il ne faut pas utiliser de framework mais c'est un autre débat

[ed73170]

pour le problème du code qui se répète et pas factorisé suffisamment, malheureusement on semble le rencontrer souvent..on préfère travailler vite et bâcler plutôt que de bien faire les choses...

Ce n'est pas tellement qu'on "préfère" travailler vite et bâcler les choses, c'est qu'une journée de travail fait un certain nombre heures et n'est pas extensible à l'infini, en tous cas pour ceux qui font respecter leur contrat de travail ou de prestation.

Alors, lorsqu'on me donne des délais pour réaliser une tâche, la première chose que je fais c'est d'estimer la manière dont je vais m'y prendre pour réussir à la terminer dans le temps imparti. Si je dispose d'assez de temps pour faire du code factorisé, réutilisable, propre, etc... alors je le fais, sinon je vais au plus rapide pour avoir quelque chose qui marche, quitte à revenir dessus 6 mois après, mais ceci devient une autre tâche avec d'autres délais.

[Mat.M]

Ce n'est pas tellement qu'on "préfère" travailler vite et bâcler les choses, c'est qu'une journée de travail fait un certain nombre heures et n'est pas extensible à l'infini, en tous cas pour ceux qui font respecter leur contrat de travail ou de prestation.

salut ed73170 je me suis mal exprimé c'est vrai.
Je sais comment ça se passe les derniers projets auxquels j'ai participé c'était comme ça il fallait faire vite.
De toute façon étant donné que le client il paie la journée de prestation à un certain taux journalier, le prestataire doit faire vite pour arriver à un résultat.

[Glutinus]

alors il ne faut pas utiliser de framework mais c'est un autre débat

Haha je me suis aussi mal exprimé, c'est pas vraiment un framework, c'est un ETL. Il y a un aspect graphique très ludique et surtout le moteur derrière est autocalculé. Mais la plupart du temps, les projets partent en vrille, les développeurs ont 2 jours poru faire un dev et vont faire ce qu'on appelle une "surcharge SQ" c'est-à-dire qu'ils vont faire un SQL et ne pas utiliser la puissance de l'outil.

Ca mène souvent à pas mal de souci de lecture, vous allez me dire il y a plus de gens qui savent lire le SQL, certes, mais si c'est une requête de 3000 lignes c'est plus compliqué alors que le "mapping" est graphique et on voit les différentes composants.

Bref, je suis à peu près sûr qu'en faisant un mapping propre pendant allez 3 jours et une requête qui va te prendre 5 minutes à prendre, c'est sûr la requête en one-shot coûte moins, mais j'ai constaté qu'à terme en maintenance tu te prends 10 jours dans la tronche plus des performances épouvantables - et les clients vont multiplier la puissance des serveurs alors que si ça avait été paramétré proprement et de manière réfléchie, le serveur original aurait largement suffi.

[Bousk]

et les clients vont multiplier la puissance des serveurs alors que si ça avait été paramétré proprement et de manière réfléchie, le serveur original aurait largement suffi.

Vrai mais il se;ble qu'aujourd'hui l'upgrade hardware ne coute quasi rien face a un upgrade "humain" (cout de la main d'oeuvre, duree necessaire, voire formation de la main d'oeuvre necessaire)

[Glutinus]

Effectivement, j'ai eu justement cette discussion et il n'y a pas si longtemps mais il y a eu beaucoup d'expériences dans lesquelles passer par un mastodonte de guerre était cher mais sûrement moins que de se reprendre je ne sais de combien de jh de refactoring.