[PHP] Un mauvais développeur PHP en 41 points
Bonjour à tous,
Hop, comme Witalk j’ai reçu la petite chaine décrivant un mauvais déveur PHP en 41 points… C’est parfois un peu extrême, mais cela dit l’esprit est bon !
L’utilité d’une telle liste n’est pas de se faire traiter de nuls, mais plutôt de voir les points importants que l’on peu doit améliorer.
Witalk a fermé les commentaires sur son billet, je ne le ferais pas. Vous pouvez donc m’insulter et me traiter de newbie tant que vous voulez 
La version française :
Vous êtes « mauvais » si:
1. Vous ne commentez pas votre code comme le veut le manuel phpDoc
2. Vous ne voyez pas la nécessité et / ou les avantages d’une bonne programmation IDE comme Zend Studio ou Eclipse PDT
3. Vous n’avez jamais utilisé une certaine forme de contrôle de version comme Subclipse
4. Vous n’adoptez pas les normes de codage et de “nommage”, de conventions générales et de s’en tenir à eux au moins tout au long du projet
5.Vous n’utilisez pas une méthodologie cohérente
6. Vous n’échappez pas et / ou ne validez pas correctement entrée ou de requêtes sql
7. Vous ne planifiez pas votre demande de manière approfondie avant de commencer à coder
8. Vous n’utilisez pas de test axé sur le développement
9. Vous ne programmez pas, ni testez avec des rapports d’erreurs
10. Vous ne voyez pas les avantages d’un “débugger”
11. Vous ne factorisez pas votre code
12. Vous ne conservez pas les différentes couches séparées en utilisant quelque chose comme MVC
13. Vous ne savez pas ce que représentent : KISS, DRY, MVC, POO, REST
14. Vous ne retournez pas le contenu, mais l’écho ou l’imprimé de vos fonctions ou de vos classes
15. Vous n’avez jamais vu l’avantage des tests unitaires ou d’essai en général
16. Les sorties sont toujours du HTML et ne sont ni des données, ni du texte, ni des objets.
17. Code dur messages et les paramètres de configuration
18. Vous n’optimisez pas vos requêtes sql
19. Vous n’utilisez pas __autoload
20. Vous ne permettez pas de gestion des erreurs intelligentes
21. Vous utilisez $ _GET au lieu de $ _POST pour toute action destructrice
22. Vous ne savez pas comment utiliser les expressions régulières
23. Vous n’avez jamais entendu parler de sql injection ou cross-site scripting
24. Vous ne permettez pas la simple configuration, les paramètres peuvent être transmis à un constructeur de la classe, set / get méthodes appelées plus tard, ou constantes définies à un moment de l’exécution.
25. Vous ne comprenez pas les avantages et les limites de la “programmation orientée objets”
26. Détournement POO / tout ce que vous écrivez, quel que soit ce qui est petit est POO
27. Vous pensez que les logiciels réutilisables pour votre code nécessitent d’être POO
28. Vous ne choisissez pas de défaut intelligent
29. Vous n’avez pas un seul fichier de configuration
30. Vous ne voulez pas que le contenu du fichier soit vu, alors vous lui donnez une extension .Inc au lieu de .Php
31. Vous n’utilisez pas de couche d’abstraction de base de données
32. Ne pas tenir compte du DRY (Dont repeat Yourself). Si vous devez copier et coller ou dupliquer quelque chose de votre dessin ou modèle doit être améliorer.
33. Vous ne faites pas de fonction / classe / méthode pour faire une seule chose et ne pas les faire interagir.
34. Vous n’essayez pas de tirer parti des caractéristiques spécifiques comme la POO résumé / interface classes, héritage polymorphisme et l’accès préférentielle.
35. Vous n’optimisez pas votre conception d’application établie avec les schémas de design
36. Vous ne permettez pas à votre utilisateur de définir le répertoire de base si vous avez plusieurs fichiers et / ou répertoires
37. Vous polluez l’espace de “nommage” global, une option serait de préfixer les fonctions dans votre bibliothèque avec une chaine de caractères
38. Vous ne permettez pas de préfixe de table lors de l’utilisation de tables de bases de données
39. Vous utilisez un moteur de template
40. Vous ne jetez pas un coup d’œil à établir des cadres d’inspiration php, la plupart d’entre eux ont avancé des concepts de dev web et de bon code
La version originale anglaise :
- don’t comment your code properly with something like phpDoc
- don’t see the need and/or benefits of a good programming IDE like Zend Studio or Eclipse PDT
- have never used some form of version control like Subclipse
- don’t adopt some coding & naming standards and general conventions and stick to to them at least throughout the project
- don’t use a consistent methodology
- don’t escape and/or validate properly input or sql queries
- don’t plan your application thoroughly before starting to code
- don’t use test-driven development
- don’t program & test with error reporting on
- don’t see the benefits of a debugger
- don’t refactor your code
- don’t keep the different layers seperated using something like MVC
- don’t know what these stand for: KISS, DRY, MVC, OOP, REST
- don’t return content but echo or print it from your functions or classes
- have never seen the advantage of unit tests or testing in general
- return HTML, not data, strings, or objects.
- hard code messages and configuration parameters
- don’t optimize your sql queries
- don’t use __autoload
- don’t allow intelligent error handling
- use $_GET instead of $_POST for any destructive actions
- don’t know how to use regular expressions
- you’ve never heard of sql injection or cross-site scripting
- don’t allow simple configuration, can be parameters passed to a class’s constructor, set/get methods called later, or constants defined at a runtime.
- don’t understand the benefits and limitations of Object Oriented Programming
- misuse OOP / everything you write , no matter how small is OOP
- you think reusable software equals/requires your code to be OOP
- don’t choose intelligent defaults
- don’t have one single configuration file
- don’t want the file contents to be seen, but give it a .inc extension instead of .php
- don’t use a database abstraction layer
- don’t keep it DRY, Don’t repeat yourself. If you have to copy and paste or duplicate something your design may be off.
- don’t make a function/class/method do just one thing and don’t make them interact.
- don’t try to take advantage of OOP specific features like abstract/interface classes, inheritage polymorphism & access modifiers.
- don’t optimize your application design with established design patterns
- don’t allow your user to define a base directory if you have multiple files and/or directories
- pollute the global namespace, one option is to prefix the functions in your library with a common string
- don’t allow a table prefix when using database tables
- use a separate template engine
- don’t take a look at established php frameworks for inspiration, most of them have advanced web dev
Je suis évidement un mauvais !
Un commentaire a faire?
Have fun,
Jaguie
[photo]
Billets similaires
Tags: PHP // 15 Commentaires »
Je ne comprend pas ce que l’utilisation d’un moteur de template viens faire ici…
Excuse-moi, mais si on veut respecter les principes DRY/KISS/MVC et ne pas réinventer la roue à chaque projet, l’utilisation d’un moteur de template est un pré-requis lourd il me semble…
Il faut également savoir dimensionner ses réalisations, genre utiliser CakePHP (tenté soit que ce fut-ce possible) pour un site perso Free ou trois pages pour le site d’un artisan boucher, franchement…
En fait j’ai l’impression qu’il ne respecte pas lui-même le KISS…
Pour dire les choses plus crument, on dirait que cette liste a été écrite par un noob qui vient d’être félicité pour un projet où il a fait mumuse avec les dernières techno et qui se sent le droit de juger tout le monde…
Oui j’ai lu ça aussi ce matin dans le twitt de Korben… Bien vu mais pas complètement juste comme liste. Notamment lorsqu’on développe sous Linux on s’en sort proprement avec le combo Terminal / Bloc Note / Mercurial…. les IDE du style d’eclipse Zend etc ne sont pas indispensables pour le Web d’après moi.
Oups je me reconnaît dans plusieurs points, c’est grave docteur ? ^^
J’adore
trop geek pour moi…
mais bientot je serais experte en lotusscript sous domino designer… ça c’est la classe! 
Pas mal de trucs que je fais ou ne fais pas (et qui sont dénoncées), ce qui doit prouver que je suis encore « mauvais », mais y a quelques petits trucs qui me chagrinent… Comme @Kane, je vois pas ce que l’utilisation d’un moteur de template a de mal (je suppose que la personne en question est anti-template, mais c’est un sujet qui est franchement discutable, tout dépendant d’un choix [propreté contre rapidité]).
Ah et la 32. est très mal traduite en français !
Entièrement d’accord au sujet des templates… Ne serai ce que pour une question de SEO …
Ensuite, je suis assez d’accord avec Kane dans son analyse. Mais l’utilité d’une telle liste est de voir les points que l’on peut améliorer comme j’ai déjà pu le dire.
[...] [PHP] Un mauvais développeur PHP en 41 points | ChroGeekwww.chrogeek.com/2009/02/php-un-mauvais-developpeur-php-en-4… par jaguie il y a quelques secondes [...]
@Arcus : chacun sa tech, sérieux, j’étais fan de bluefish, j’ai test Eclipse PDT, limite je me sens sale tellement j’ai connu un gain de productivité malsain.
|
@Priest : désolé, ça se soigne pas XD et le pire c’est que c’est une maladie dégénérative sur long terme et non létale…
|
@DeLpH : c’est pas geek, c’est juste pas ton truc, te rabaisse pas comme ça
|
@Adrian Gaudebert : je viens de me mettre à Smarty, bah je n’ai pas constaté trop de perte de vitesse, plus le cache intégré, et facile à prendre en main par les graphistes, il est vrai j’ai pas maté les sources encore, mais vu par qui s’est soutenu, je pense que le code sent bon l’acajou… mais bon, comme on dit souvent, question de point de vue, de feeling.
|
@jaguie : dans l’esprit open source je pense faire une liste, après tout je suis comme tout le monde, j’ai même moins de diplômes officiels que certains ici, donc why not ?!.
|
1. utilisation de globals
2. patternite aïgue : utilise toujours des pattern pour le moindre truc, même celui qui devrait être en static ou fonctionnel selon le milieu dont on viens.
3. anti-pattern user : utilisation massive de « classes dieu » qui font même le café, de « coulées de laves » et autres subtilité qui rendent l’obfuscation un art brut (genre « Tour aux figures » de Jean Dubuffet).
4. artiste autiste : non respect de conventions de nommage, nommage « artistique » genre « pourquoi appeler l’itérateur $i ? C’est tellement mieux : $hortense ou $velo ou $_okzdd8982″.
4. bis bonus. ne documente pas son code.
5. Ne parle pas aux autres dév du projet, fait ce qu’on lui demande dans son coin.
6. produit du code efficace mais suivant une logique totalement absconne et loin du raisonnement « IRL ». voir 4.bis.
7. Ne prend pas en compte l’encodage du serveur, de la BDD et de ses pages.
8. Perroquet bavard : nombreux « ctrl-c ctrl-v » de code = non factorisation.
9. Trust the User Input : ne sécurise pas les entrées de ses logiques (métier ou app indifféremment)
10. Laisse error_reporting à true en production sans faire une fonction perso qui cache les messages à l’user et report dans un log ou équivalent.
*vous êtes libre de rajoutez ici ce que vous pensez (voir license GNU)(pour ceux qui seraient amené à le penser, oui je suis un connard de libriste XP), sinon je me limite à 10 points perso, donc …*
En effet dans la liste certains points ne sont pas forcement obligatoires. Tout comme l’a dit kane cela me fait également penser à une liste d’une personne qui veut faire bien car il à utilisé toutes les dernières technologies dans son projet
Pour moi le point que je ne comprend pas c’est le deuxième. Comment un truc écrit en Java peut aider à la productivité. Franchement j’ai beau me creusé, je voit pas. En plus il prend Eclipse, qui pour moi est une usine à gaz sans nom.
@Kane : chacun sa tech, sérieux, j’étais fan de bluefish, j’ai test Eclipse PDT, limite je me sens sale tellement j’ai connu un gain de productivité malsain.
Bah déjà t’as réussi à l’installer, pour moi c’est déjà un exploit en soit.
Perso j’utilise Quanta, il fait exactement ce que tu as besoin et très simplement. Je voit tellement de gars dire qu’il bosse sous Eclipse et quand on leur demande pourquoi il te réponde : » Eclipse c’est ce qu’il y a de mieux. » mais non soit jamais essayer autre chose ou bien il ne peuvent pas tenir un argumentaire sur la plus value de cet éléphant.
Enfin tous est relatif, je suis apparemment un très mauvais codeur. Quelque part je suis un peu rassuré c’est pas mon métier et je n’est pas la prétention d’être The Coder.
@Kane ne voit pas dans ma remarque quelque forme de jugement. C’est juste que je suis un Anti-Eclipse/Java.
Bon, j’ai visiblement encore du boulot…
Olala… je dois être un terrible développeur alors !
La traduction est pas tip top non plus.
Si vous utilisez PHP, vous etes un mauvais developpeur.