Vous êtes un mauvais codeur php
En ouvrant google Reader, je suis tombé sur un article référencent 40 caractéristiques du mauvais codeur PHP.
C’est typiquement ce genre de billets qui aura tendance à m’énerver (dans une moindre mesure, j’suis pas non plus un gros impulsif). PHP est un langage des plus permissif (on s’en rend compte quand on va voir ailleurs) donnant très facilement (et généralement) naissance à des applications peu sécurisées (phpBB pour ne pas le citer). Bien sur, on a tout à fait moyen de faire du secure quand on s’en donne la peine avec des petites méthodes simples mais fondamentales (ne jamais faire confiance à l’utilisateur et tester tout ce qui “entre”, par exemple).
Parler de “mauvais codeurs PHP” est finalement (pour moi) un sujet sensible et paradoxal puisqu’on ne fait que récolter les fruits d’un succès majoritairement du à l’accessibilité et à la simplicité du langage.
“don’t comment your code properly with something like phpDoc“
Je sens que je vais me faire taper avec cette phrase, mais je commente très peu mon code que ce soit en PHP, en Java ou en Javascript. J’aurais plutôt tendance à miser sur l’intuitivité de celui-ci. Utiliser la syntaxe de phpDoc c’est pour moi de la sododrosophilie.
“don’t understand the benefits and limitations of Object Oriented Programming”
Celle la c’est pour Julien. Je suis pro-objet, vraiment je trouve ça terriblement pratique mais, et c’est également ce que disait Cyril dans une interview sur tv4it, le fait de pouvoir utiliser de l’objet ou du procédural pour une même application est l’une des forces de PHP.
Je suis conscient de n’être que peu objectif, et d’avoir une faible expérience du développement en entreprise, n’hésitez pas à me lapider dans les commentaires !
Palleas @ février 13, 2008
Moi aussi je suis pas fan de commenter mon code, vu que 99% du code est composé de code simple.
Par contre il faut le documenter, c’est à dire expliquer comment il fonctionne, ses limites, et comment le réutiliser. Et c’est là que phpDoc (ou doxygen, c’est bien doxygen. Oh oui c’est bien !), du reverse engineering pour faire des diagrammes UML, et des explications écrites sont intérressantes.
Mais bon j’ai le même problème que toi, je n’ai jamais travaillé sur des projets qui ont été repris plus tard.
Quant à la POO, on peut travailler autrement ?
Ah bah nan, la POO c’est coule, mais pour du php, ne coder qu’en poo c’est un peu prise de tête, je trouve. Mais sinon non, la POO c’est vraiment génial de décomposer au maximum ton application <3
Pour répondre au coup de la POO en PHP, j’ai envie de citer Heroes :
Mr. Linderman: You see, I think there comes a time when a man has to ask himself whether he wants a life of happiness or a life of meaning.
Nathan Petrelli: I’d like to think I have both.
Mr. Linderman: Can’t be done. Two very different paths. I mean, to be truly happy, a man must live absolutely in the present. No thought of what’s gone before, and no thought of what lies ahead. But, a life of meaning… A man is condemned to wallow in the past and obsess about the future.
La “life of happiness” étant la POO, et la “life of meaning” étant l’optimisation des performances.
Aller, pour le fun :
Mr. Linderman: Tu vois, il arrive un moment où tu dois choisir entre du code objet et du code performant.
Nathan Petrelli: Je voudrais avoir les deux.
Mr. Linderman: Impossible. Deux chemins trop différents. Je veux dire que pour être objet, le code ne doit pas se soucier de la montée en charge. Sans penser aux hits de la version précédente, et sans réfléchir à ceux qui viendront. Mais un code performant… Un développeur est condamné à benchmarker son code et à être obsédé par sa montée en charge.
Le commentaire de code on me le réclame à corps et a cri au boulot et c’est galere, je corrige des bugs je sais pas comment alors va expliquer la solution que tu viens de trouver …
sinon POO or not POO, tout dépend de ce que tu fais, un pauvre truc qui va te chercher une pauvre infos dans une base pas besoin d’objet mais pour des gros trucs bien lourd et bien complexe c’est POO
@Julien : tu préfères le code performant (en terme de rapidité et de monter en charge) au code réutilisable, maintenable et structuré ?
Personnellement, je préfère d’abord m’intéresser au développement d’une application bien structurée et évolutive. La question de l’optimisation viendra après lorsque cette dernière sera déployée définitivement en production avec ses jeux de données réels. Il est très difficile de penser “optimisation” avant la mise en production d’une application. Certes on peut évaluer avant globalement les ressources nécessaires au bon fonctionnement du logiciel, mais on ne peut pas prévoir avec exactitude à quelle fréquentation elle sera utilisée. Si tu développes un intranet pour une entreprise, il sera assez facile d’établir le taux de fréquentation du site. En effet, tu connais globalement combien de personnes travaillent dans l’entreprise, combien auront accès à l’application et à quelles heures de la journée elle sera le plus utilisé. En revanche, si tu veux déployer une application Internet grand public, tu ne peux pas prévoir à l’avance que le site récoltera quotidiennement 100, 1000, 10 000 ou 1 000 000 de visiteurs uniques. Il faudra adapter l’optimisation en fonction des carences que l’on détectera sur le site à force d’être utilisé.
L’optimisation doit être vraiment justifiée. Est-ce vraiment important de se casser la tête pour gagner un pouillème de microseconde ? Pour moi, l’important pour une application logicielle quelle qu’elle soit, c’est de :
1. fonctionner conformément au cahier des charges
2. être sécurisée
3. être structurée et facilement maintenable
4. être optimisable si nécessaire
L’optimisation dépend tellement de nombreux paramètres (configs matérielles et logicielles du serveur, choix du SGBDR, qualité du code, qualité des algorithmes, qualité de la bande passante, taux de fréquentation du site, nombre de données manipulées quotidiennement, qualité des requêtes SQL…) que l’on ne peut pas s’y attarder trop longtemps au début. Surtout qu’en général, les environnements de développement et de production ne sont pas du tout les mêmes.
Bref ! Le débat POO vs performance reste ouvert mais au 21 ème siècle avec des machines toujours plus puissantes et moins chères, je pense que l’on peut s’orienter vers du gaspillage de ressources au profit d’une application robuste. Il y’a encore quelques années en arrière, l’optimisation pouvait primer dans la mesure où les dépassements de bande passante ou d’espace de stockage coûtaient relativement cher. Aujourd’hui ce n’est plus le cas.
++
Hugo.
L’optimisation ce n’est pas gagner “quelques microsecondes”, c’est diminuer les besoins en mémoire et gagner du temps partout où c’est possible.
Sur certains projets, l’optimisation a permis de passer de 300 ou 400 ms (génération php/sql uniquement) à moins de 100 ms.
Le temps de chargement est perceptible quand il est supérieur à 0.3s, pas en dessous.
En mémoire, une optimisation a permis de passer de 700 ko de ram par script à 300 ou 400 ko selon les actions.
Concrètement, ça ne va pas te parler puisque sur ton site tu peux bouffer 2Mo de ram et 1 seconde par page, le serveur derrière suffit au nombre de visites. Maintenant le jour où ton site aura 10.000 VU/jour il va casser ton serveur, alors qu’en l’optimisant tu pourrait taper 30.000 VU/jour.
Et tout ça, c’est sans compter que ce n’est pas parce que les ressources sont moins chères qu’il faut les gaspiller. 3 serveurs là où 1 suffit, c’est autant d’énergie perdue à les alimenter et à les refroidir. Tu as raison, le hardware on s’en fout, ça ne coûte vraiment plus grand chose pour ce que ça peut donner. Mais ça consomme toujours beaucoup.
PS: coder optimisé n’a jamais empêché d’être évolutif et réutilisable. Coder objet et optimisé est beaucoup plus difficile par contre.
Je ne suis pas contre l’optimisation. J’essaie moi aussi de prendre conscience que certaines tâches de mon programme pourraient être largement améliorées. Le problème de l’optimisation c’est que l’on peut difficilement l’appréhender tant que l’on ne se trouve pas dans l’environnement de production final ! Quand on développe, on est bien souvent en local sur sa machine, voire sur un serveur web dédié local. Il nous manque donc déjà le premier paramètre “réseau Internet” pour qualifier le temps que prendra la page à se charger. S’en suivent également les disparités de configuration matérielles et logicielles entre les serveurs de développement et de production (surtout quand ce dernier appartient au client et que tu ne peux pas vraiment y toucher…). Mais il y’a aussi la quantité des jeux de données de tests en développement qui est bien souvent peu représentative des jeux de données de la réalité en production. Je ne parle même pas ensuite de comment va être utilisée l’application par l’utilisateur final…
Je suis complètement d’accord avec toi qu’il est nécessaire de chercher à optimiser son application pour gagner du temps, gagner de la mémoire, gagner de l’espace disque, gagner de l’énergie et par la même occasion gagner de l’argent (et encore, ce n’est pas toujours vrai ça…)… Mais il est clair pour moi que l’on ne peut pas faire passer l’optimisation en priorité dans le développement d’une application. Il faut en avoir conscience et chercher à optimiser surtout à la fin lorsque l’on se trouve dans un état de production réel.
L’optimisation doit également se justifier et être proportionnelle aux attentes (exigences je dirai même) du client. Elle peut rentrer de manière explicite dans le cahier des charges, et auquel cas tu n’y échappes pas. Par exemple si tu dois développer une application qui fera des calculs à longueur de journée. Mais bien souvent, un client te demandera avant tout que l’application satisfasse à ses besoins. Donc dans un premier temps, il faut répondre à cette exigence. Puis s’il s’aperçoit que certains traitements sont un peu longs et que ça le dérange, il ne manquera pas de le faire savoir.
L’informatique n’est pas une science exacte car elle dépend d’une multitude de paramètes. Finalement, optimiser c’est bien mais pas trop. C’est généralement perdre beaucoup de temps à rechercher pour obtenir peu de résultats significatifs. Surtout si l’application est dans l’ensemble bien développée et bien pensée au départ.
>> coder optimisé n’a jamais empêché d’être évolutif et réutilisable. Coder objet et optimisé est beaucoup plus difficile par contre.
On est d’accord sur le fait que l’on peut produire un code maintenable et réutilisable qu’il soit écrit en procédural ou en OO. Mais lorsqu’un projet devient un peu trop complexe, l’approche procédurale a tendance à devenir assez fastidieuse pour le développeur. Certes, elle sera très certainement légèrement plus performante que l’approche OO mais elle aura l’inconvénient d’être moins gérable…
Donc POO ou pas, c’est au développeur de décider et de savoir ce qu’il attend avant tout de son application :
* Un logiciel qui trace mais plus difficilement maintenable
* Un logiciel qui consomme un petit plus mais que l’on aura beaucoup moins de mal à faire évoluer.
Je suis partagé et c’est aussi pour cette raison que j’aime PHP car il permet de combiner les deux approches en même temps. J’aime garder l’approche objet pour structurer et pour réutiliser du code existant (classe de génération de flux RSS par exemple) mais également l’approche procédurale qui permet de coder plus rapidement et de gagner en performances.
Et le point de vue utilisateur ?
C’est p’tet cool pour le développeur, mais ce n’est pas lui qui l’utilise après.
De plus, je ne suis pas sur que ta grande expérience te permette de juger, contrairement à celle de Julien par exemple.
@NoOne : c’est bien ce que je dis, il faut optimiser en fonction des besoins et des exigences de l’utilisateur final. Si ton client est satisfait du fonctionnement global de l’application alors que tu n’as pas plus optimisé que ça, pourquoi aller se casser la tête pour optimiser si le besoin ne s’en fait pas ressentir ? Quand on optimise, il faut savoir s’arrêter à un moment et rester cohérent avec les besoins de l’utilisateur final. C’est à dire qu’il faut doser jusqu’à quel point il est acceptable d’utiliser l’application sans qu’elle gêne l’utilisateur.
>> De plus, je ne suis pas sur que ta grande expérience te permette de juger, contrairement à celle de Julien par exemple.
Je suis d’accord ! Je ne suis ni expert en développement et encore moins en optimisation. Néanmoins, mon expérience actuelle me permet d’affirmer qu’il n’est pas nécessaire de toujours vouloir tout optimiser. Il faut savoir optimiser quand c’est nécessaire et justifiable. Aujourd’hui on n’est plus vraiment à une demi-seconde près ou bien à un dépassement de mémoire de 100 ko avec les machines dont on dispose.
Moi j’suis d’accord avec tout le monde (ahah le mec qui ne se mouille pas) mais j’pense quand même que l’optimisation doit toujours être prise en compte dès la création de l’application, prendre des bonnes habitudes qui font qu’on aura à la base une quelque chose qui tourne correctement.
Il n’y a, de toute façon, aucune réponse nette et précise à la question : faut-il optimiser (dès le début) ?
La réponse est donc : “Ca dépend” ! Mais il faut quand même y penser au début du développement de l’application, au même titre que la sécurité (que beaucoup évincent et se retrouvent bec dans l’eau lorsque leur logiciel a été hacké). Il est bon dès le début du développement de prévoir des stratégies d’optimisation comme par exemple :
- On va installer un cache d’opcode
- Devra-t-on plutôt placer en base des valeurs précalculées par le langage ou bien laisser le SGBDR calculer lui même ?
- Doit-on plutôt faire une requête de ouf malade ou bien plusieurs pour cette action ?
- …
Mais pensez l’optimisation dès le début ne suffira peut-être pas. Elle permettra juste de minimiser les éventuels ralentissements qui surviendront lorsque l’application sera définitivement en état de production avec des jeux de données réels et représentatifs.
Hugo >> Ta Savoie fait envie vu comme ça
Je sais, je vends du rêves ^^