PHP
La mauvaise manière
Dernière mise à jour : 31/01/2023
Dans le monde de la programmation en PHP, un ensemble de tendances est massivement propagé par certaines personnes en tant que « PHP moderne » (dans leurs livres et sur leurs sites web), tandis que les autres approches sont considérées comme arriérées, stupides ou fausses.
Ces personnes semblent travailler sans relâche pour que d’autres suivent leur manière de faire.
Ce site web a été créé dans le but de présenter une vision pragmatique de la programmation en PHP. Une vision dictée par l’expérience et les conséquences pratiques plutôt que par les tendances, la théorie ou le dogme académique.
Ce site web PHP - La mauvaise manière est un document évolutif et continuera à être mis à jour avec davantage d’informations quand elles seront disponibles.
N’hésitez pas à contribuer.
Le problème avec les règles et lignes de conduite en programmation, c’est qu’elles servent un but dans un contexte précis. Sortie du contexte, une bonne règle peut devenir une horrible règle. En effet, toute bonne règle devient mauvaise lorsqu’elle est poussée à l’extrême.
Ceci est important à comprendre car beaucoup de principes et de règles de développement logiciel développés au cours du temps et présentés par plusieurs personnes deviennent souvent mal utilisées dans les mains d’extrémistes.
L’expérience nous a appris que la mauvaise utilisation de règles générales et de lignes de conduite a toujours pour effet une complication, un problème de sécurité, des résultats eronnés et dans certains cas un désastre complet.
Le principe KISS qui est un acronyme anglais pour “Keep It Simple, Stupid” (« Garde ça simple, stupide » ndt), est un bon et sage principe qui est généralement vu par les développeurs expérimentés comme un très bon conseil à suivre, mais même ce grand principe devient un danger pour un projet s’il est suivi à la lettre. Une chose « trop simple » conduit à un manque de fonctionnalité.
La mauvaise manière : Suivre religieusement les règles et lignes de conduite. 
Tous les cadriciels PHP généralistes craignent !
Dans la communauté PHP, une très mauvaise tendance est devenue un standard de-facto dans le développement des applications web, c’est-à-dire l’utilisation d’un cadriciel généraliste populaire.
Cette tendance a émergé et est devenue populaire, non pas parce qu’elle améliore le résultat du processus de développement d’une quelconque façon ou parce que c’est la bonne chose à faire d’un point de vue technologique et architectural. Cette tendance est devenue populaire parce que certains développeurs de cadriciels ont réussi à entraîner les masses dans leur polémique envers la programmation à partir de zéro avec des strophes telles que « Ne réinventez pas la roue ! » et « Ne le faites pas vous-même, d’autres sont plus compétents que vous ».
Nombre de développeurs actuels ignore complètement les principes fondamentaux de la programmation sonore et passe une grande partie de leurs temps à rêver à de nouvelles couches de complexité dans le but d’apparaître plus intelligents, plus cool ou plus acceptables par ceux qu’ils considèrent comme leurs pairs.
Ces personnes semblent tirer leur fierté dans l’idée d’avoir d’autres gens qui suivent leur « manière de faire les choses », devenant en quelque sorte un meneur de la communauté PHP, et voyant d’autres gens utiliser leurs derniers outils Open Source à la mode, au point d’oublier de s’assurer que le conseil qu’ils donnent est valide.
Dans l’industrie logicielle, vous pouvez comparer une maison pré-fabriquée à un cadriciel généraliste. Construire un logiciel avec un cadriciel généraliste ne fait pas plus de vous un programmeur qu’assembler une maison pré-fabriquée fait de vous un charpentier.
Sur ce site, nous différencierons les cadriciels et les bibliothèques de la manière suivante :
Dans le monde de Python et Ruby, construire des sites web à partir de zéro est fatiguant parce que ni Python, ni Ruby n’ont été créés originellement pour construire des sites web. De ce fait, les cadriciels généralistes tels que Django et Ruby on Rails devinrent rapidement populaires pour construire des site web dans ces langages.
PHP d’un autre côté a été créé dès le départ par Rasmus Lerdorf comme une trousse à outils écrite en C qui vous permet de développer du HTML dynamique facilement et rapidement. Cela faisait de PHP, et fait toujours, un cadriciel lui-même.
PHP a évolué massivement depuis lors, et PHP peut désormais être utilisé pour davantage de choses que construire du HTML et des sites web, mais voir PHP comme une sorte de cadriciel n’est pas faux. PHP est par nature une couche d’abstraction pour le développement d’applications web écrit entièrement en C procédural.
Utiliser une bibliothèque dans votre projet est tout ce qu’il y a de plus naturel. PHP lui-même est livré avec un ensemble de bibliothèques que vous pouvez utiliser pour étendre votre code. PDO par exemple est une bibliothèque légère qui fournit une interface unifiée pour accéder aux bases de données en PHP.
Utiliser un cadriciel au-dessus de PHP est une toute autre question.
Lorsque vous utilisez un cadriciel en PHP, vous ajoutez une couche d’abstraction au-dessus d’une autre couche d’abstraction, celle qui était déjà en place pour que vous commenciez. La couche d’abstraction ajoutée que le cadriciel fournit peut simplement servir à organiser votre code en un ensemble pré-établi de schémas, ou il peut ajouter encore plus de complexité en interconnectant des centaines ou des milliers de classes et méthodes en un cauchemar de dépendances, dans tous les cas en ajoutant des couches de complexité à votre code qui ne sont pas nécessaires !
Toute l’expérience commence par l’interface. L’expérience de l’interface est le résultat de la technologie sous-jacente et du nombre de couches d’abstraction. Plus vous utilisez d’abstractions, moins l’interface est efficace et plus l’application est sujette aux erreurs. Plus l’interface est haut niveau, plus le détail et l’efficacité sont perdus.
Comprenez bien : Le nombre idéal de lignes de code dans tout projet est aussi peu que possible tout en étant le plus clair et lisible que possible !
Ce dont tout le monde n’a pas besoin, c’est d’un cadriciel généraliste. Personne n’a un problème général, tout le monde a un problème très précis qu’il tente de résoudre.
Quelques entreprises commencèrent à entendre l’effet de mode autour des cadriciels PHP et lancèrent leur nouveaux projets en utilisant l’un de ces populaires cadriciels généralistes, pour ne finir que dans un désastre. Non seulement ils découvrirent que le cadriciel généraliste était mauvais pour résoudre leur problème précis, mais il était aussi extrêmement lent à le faire. Il était impossible de suivre l’extensibilité des besoins et de ce fait ils commencèrent à déchirer le cadriciel en morceaux dans une tentative désespérée de sortir les parties dont ils n’avaient pas vraiment besoin.
Utilisez toujours l’approche pragmatique :
Une action ou une conduite dictée par la considération de conséquences pratiques immédiates plutôt que par la théorie ou le dogme.
– Dictionnaire anglais Collins, complet et intégral, 12e édition 2014
La mauvaise manière : Toujours utiliser un cadriciel au-dessus de PHP.
J’ai cette grande allergie envers les conceptions et les patrons de conceptions en tour d’ivoire. Peter Norvig, quand il était à Harlequin, écrivit ce papier sur la manière dont les patrons de conception sont en réalité des défauts dans votre langage de programmation. Trouvez un meilleur langage de programmation. Il a absolument raison. Vénerer les patrons et penser : « Oh, je vais utiliser le patron X ».
– Brendan Eich dans Coders at work - Reflections on the Craft of Programming (en)
En ingénierie logicielle, un patron de conception est une solution réutilisable pour un problème récurrent arrivant en conception logicielle. Un patron de conception n’est pas une conception finie qui peut être transposée directement en code. C’est une description ou une idée sur la manière de résoudre un problème qui peut être utilisée dans différentes situations. Les patrons de conceptions orientés objets montrent typiquement les relations et interactions entre des classes et des objets, sans spécifier l’application finale des classes et objets impliqués.
PHP supporte les paradigmes impératif, fonctionnel, orienté objet, procédural et réflectif. PHP est une énorme trousse à outils avec beaucoup de différents outils avec lesquels il est possible de résoudre divers problèmes de manières différentes – pas uniquement une seule.
PHP c’est avant tout la liberté, des solutions rapides et extensibles, et possédant de multiples façons de traiter les problèmes.
Lorsque nous tentons de nous améliorer, et notre code dans ce cas, nous nous accrochons parfois à la philosophie d’un idée ou d’un patron particulier et tendons à oublier de penser de manière pratique.
Quand je vois des patrons dans mes programmes, je le considère comme une signal d’alarme. La structure d’un programme ne devrait refléter seulement que le problème qu’il tente de résoudre. Tout autre singularité dans le code est un problème, pour moi au moins, que je suis en train d’utiliser des abstractions pas suffisamment efficaces — et souvent que je génère à la main des expansions de quelque macro que j’ai besoin d’écrire.
Nous ne devrions avoir à nous accrocher à une philosophie ou une idée derrière un patron ou une solution spécifique. Notre souci principal est de garder le code aussi facile à naviguer et comprendre que possible et de ce fait facile à maintenir et garder sécurisé.
Nous devons aussi nous souvenir qu’il existe une chose appelée anti-patron. C’est un patron qui peut être couramment utilisé mais qui n’est pas efficace et / ou contre-productif en pratique.
Je pense que les patrons ont commencé comme les meilleures solutions généralement reconnues pour les problèmes habituels. Mais maintenant qu’ils sont là depuis un moment et que nous subissons des applications dix fois plus compliquées que nécessaires parce que les gens tentent de placer tous les patrons dont ils ont entendu parler (« mon application est bien architecturée, parce qu’elle est construite avec des patrons »), mon impression de la valeur des patrons a changé.
– Paul Wheaton dans Evil Design Patterns (en)
Utilisez toujours l’approche pragmatique :
Une action ou une conduite dictée par la considération de conséquences pratiques immédiates plutôt que par la théorie ou le dogme.
– Dictionnaire anglais Collins, complet et intégral, 12e édition 2014
La mauvaise manière : Chercher un patron pour résoudre un problème.
Le problème avec les langages orientés objet est qu’ils ont tout cet environnement implicite autour d’eux. Vous vouliez une banane mais ce que vous obtenez c’est un gorille tenant une banane et la jungle tout entière.
– Joe Armstrong dans Coders at work - Reflections on the Craft of Programming (en)
L’abstraction est puissante. Ce dont je suis réellement allergique et à quoi j’ai réagi dans les années 90, était tout ces non sens orientés objet tels CORBA, COM, DCOM. Toutes les startups du jour avaient ces bizarreries qui prenaient 200 000 appels de méthodes pour démarrer et afficher un « Hello world ». Quel travestissement ! Vous ne voulez pas être un programmeur associé à ce genre de chose.
– Brendan Eich dans Coders at work - Reflections on the Craft of Programming (en)
Beaucoup de développeurs, et beaucoup d’entreprises, ont le sentiment que la programmation orientée objet est la seule méthode raisonnable pour développer des logiciels de nos jours. Quiconque conteste la programmation orientée objet prend immédiatement conscience qu’il conteste la « sagesse conventionnelle » de l’industrie.
Sur les forums et les blogs de programmation, il y a une quantité de personnes formidables qui défendent la programmation orientée objet, et qui sont certains qu’ils savent de quoi ils parlent, en dépit du manque d’une définition standard.
Le fait est que cette soit-disant programmation orientée objet inflige souvent un lourd fardeau de complexité non nécessaire !
En tant que informaticiens et programmeurs, nous devons apprendre à mettre de côté nos préjugés et trouver la meilleure solution à un problème donné.
De nos jours, l’une des forces principales de PHP est son support des paradigmes impératif, fonctionnel, orienté objet, procédural et réflectif. PHP est une énorme trousse à outil avec beaucoup d’outils différents qui lui permet de résoudre quantité de problèmes de différentes façons - pas seulement une seule !
Aussi longtemps que nous essayons d’imposer aux différents problèmes d’une application un unique et spécifique paradigme de programmation, nous ne pensons pas de manière créative et nous ne travaillons pas efficacement !
L’une des meilleures manières de comprendre un paradigme de programmation spécifique est de regarder comment il a évolué au préalable. Quelle était la raison de son développement ? Quels problèmes existaient avec les autres paradigmes de programmation qui ont nécessité une nouvelle manière de penser ? Était-ce un problème réel ou un problème académique ? Et comment a-t-il évolué depuis ?
Cela n’a pas d’importance ce que Untel a dit ou quelle définition Unetelle donne, ce qui est important dans le contexte des paradigmes est l’histoire qui les a créé.
Il y a deux manières de construire une conception logicielle. La première est de la faire si simple qu’il n’y a évidemment aucun défaut. L’autre manière est de la faire si complexe qu’il n’y a aucun défaut évident.
Dans le passé, avant la venue de la programmation orientée objet, à la fin des années 50, nombre de programmes étaient développés en utilisant des langages mettant en avant une programmation destructurée, parfois appelée langages de première et deuxième génération. La programmation destructurée (ou programmation sans structure) est historiquement le premier des paradigmes de programmation. Il fut massivement accusé de produire du code « spaghetti ».
Il existe des langages de programmation de haut et de bas niveaux qui utilisent la programmation non structurée. Ceux-ci incluent les premières versions de BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, le code machine, les premiers systèmes assembleurs (ceux sans les méta-opérateurs procéduraux) et quelques langages de script.
Un programme dans un langage non structuré consiste habituellement en une séquence ordonnée de commandes, ou instructions, généralement une par ligne. Les lignes sont habituellement numérotées ou peuvent avoir des étiquettes qui permet au flux d’exécution de sauter vers n’importe quelle ligne du programme (comme l’impopulaire instruction GOTO).
Puis, dans les années 60, la programmation structurée émergea - principalement due au célèbre Edsger W. Dijkstra L’instruction Go To est considérée dangereuse (en).
La programmation structurée est un paradigme de programmation qui améliore la clarté, la qualité et le développement logiciel par l’utilisation de sous-routines, de blocs de structure et de boucles. C’est un contraste à l’utilisation de simples sauts tels que l’instruction GOTO.
Plus tard, la programmation procédurale fut dérivée de la programmation structurée. La programmation procédurale est basée sur le concept d’« appels de procédures ». Un « appel de procédure » est simplement un autre nom pour « appel de fonction ». Les procédures sont aussi appelées routines, sous-routines ou méthodes. Une procédure contient simplement une séries d’étapes calculatoires à effectuer. Toute procédure peut être appelée à n’importe quel endroit durant l’éxécution du programme, y compris au sein des autres procédures, ou d’elle-même.
Au départ, toutes les procédures étaient disponibles à n’importe quelle partie du programme en tant que données globales. Dans les petits programmes cela ne représentait aucun problème, mais les choses devinrent plus complexes lorsque la taille du programme augmentait, les petits changements d’une partie du programme affectant beaucoup d’autres parties.
Personne ne prévoyait de changements dans le programme et il existait quantité de dépendances. Un changement mineur dans une procédure aurait impliqué une cascade d’erreurs dans beaucoup de procédures qui dépendaient du code originel.
Une nouvelle technique qui permettait aux données d’être divisées en portées cloisonnées appelées « objets » évolua. Seules les procédures appartenant spécifiquement à la même portée pouvaient accéder à la même donnée. On l’appela masquage de données, ou encapsulation. Cela résultat en un code mieux organisé.
À l’origine, les objets ne s’appelaient pas objets, ils étaient juste vus comme des portées séparées. Plus tard, quand les dépendances furent réduites et les connexions entre les procédures et les variables dans ces portées furent considérées comme des segments isolés, le résultat donna naissance au concept d’« objets » et à la « programmation orientée objet ».
Plus tard, principalement dû au développement de Java, certains « buzzwords » ont émergé et « une procédure » ou « une fonction » n’était plus appelée une fonction, mais fut renommée « une méthode » quand elle se trouvait dans une portée séparée. Les variables n’étaient plus non plus appelée « variables », mais furent renommées « attributs » quand elles se trouvaient dans une portée séparée.
Ainsi, un objet est par essence simplement une collection de fonctions et variables désormais appelées « méthodes et attributs ».
La façon dont les méthodes et attributs sont gardées isolées dans une portée séparée est dans l’usage « une classe ». Une classe, une fois instanciée, est appelée un objet.
Les objets peuvent se référencer les uns les autres et ainsi, les méthodes à l’intérieur (fonctions) peuvent communiquer. Les objets peuvent aussi « hériter » de méthodes d’autres objets par ce qui est appelé « l’héritage ». Il s’agit d’une méthode pour réutiliser le code et permettre les extensions indépendantes du logiciel via les classes publiques et les interfaces. Les relations d’objets donnent lieu à une hiérarchie. L’héritage fut inventé en 1967 pour le langage de programmation Simula 67.
Les objets peuvent aussi hériter de méthodes d’autres objets et les « surcharger » en ajoutant ou changeant des fonctionnalités, cela s’appelle le « polymorphisme ».
Comment ces différentes idées sont implémentées varie grandement d’un langage de programmation à un autre.
La programmation orientée objet est une autre manière d’organiser le code qu’auparavant. C’est une extension de la programmation procédurale visant à cacher les données (encapsulation) et éviter la portée globale. Il s’agit d’étendre les fonctions en « empruntant » leurs plans directeurs sans affecter le code originel (héritage). Et il s’agit de surcharger les fonctions sans affecter le code originel (polymorphisme).
Le modèle orienté objet facilite la construction de programmmes, par l’accrétion. Ce qui signifie souvent, en pratique, que ça fournit une manière structurée d’écrire du code spaghetti.
– Paul Graham dans Ansi Common Lisp (en)
La mauvaise manière : Toujours utiliser la programmation orientée objet.
Un argument souvent entendu en faveur de l’usage de cadriciel est que les gens ne veulent pas gérer les codes écrits de zéro par d’autres.
C’est une mentalité étrange cependant, principalement rencontrée parmi les web développeurs de la communauté PHP. Elle reflète un manque d’expérience et de professionnalisme.
Écrire un logiciel et gérer le code d’autrui est normal. C’est une part du travail journalier d’un programmeur professionnel. Ce n’est pas quelques chose dont on doit avoir peur.
Un programmeur professionnel ne regarde pas le code d’autrui pour commencer à se plaindre qu’il est à la merci du programmeur précédent, qui n’est probablement plus associé à l’entreprise ou au projet, et si seulement le programmeur précédent avait utilisé le cadriciel A ou B, la vie aurait été plus facile.
Ce n’est pas la mentalité d’un programmeur professionnel. Personne ne fait ça.
Peut-être que la facilité d’entrée dans le développement web PHP joue un rôle dans ce genre de mentalité. Quoiqu’il en soit, c’est le signe d’une personne étant dans une mauvaise ligne de conduite.
Une grande partie de la programmation est d’avoir à travailler avec le code d’autrui. C’est une part du travail d’essayer d’améliorer le code existant et parfois cela implique une réécriture complète.
Prenez note sur les grands maîtres de la programmation en lisant le livre Coders at work - Reflections on the Craft of Programming (en).
Certaines des plus grandes et des plus réussies bases de code dans le monde sont des bases de code qui ont été développées par des centaines de personnes qui ne se sont jamais rencontrées, des bases de code développées sans l’utilisation d’aucun cadriciel, des bases de code faites entièrement dans un langage procédural sans rien d’autre que le paradigme procédural, et ils ne rêveraient pas d’en faire autrement.
Le noyau Linux (en) consiste en plus de 20 millions de lignes de code toutes écrites utilisant la programmation procédurale par plus de 14 000 participants sans aucun cadriciel d’aucune sorte.
La projet BSD et une grande partie de l’espace utilisateur GNU Linux (en) ont été écrits utilisant la programmation procédurale sans aucun cadriciel.
Même chose pour des centaines de projets Open Source autour du globe qui ont éventuellement été abandonnés par le(s) programmeur(s) original(s) pour être repris par d’autres programmeurs talentueux. Nombre de ces projets ont peu de documentation (voire aucune), aucun commentaire dans le code et aucun guide ou aide à proposer.
Le code PHP est fait en C, un langage de programmation procédural pur, sans cadriciel.
Lorsque vous définissez une classe en PHP ou quand vous démarrez votre cadriciel PHP favoris, vous lancez le code procédural de quelqu’un d’autre !
Certes, le code horrible existe, le code qui n’a pas été conçu dès le départ, ou le code qui est devenu trop grand pour lui-même mais dont le client ne veut pas gérer une réécriture, le code tellement mauvais que vous ne savez pas par quel bout le prendre, mais aucun cadriciel ne pourrait empêcher ça. C’est souvent le processus normal de croissance d’un programme. Probablement que n’importe quel cadriciel aurait été découpé en morceaux.
Et bien sûr qu’il existe du code spaghetti, mais personne n’écrit du code spaghetti intentionnellement. Parfois, c’est le résultat d’un manque d’expérience, souvent c’est de la faute du client qui change les spécifications plusieurs fois en cours de développement, ou les deux, bien qu’un cadriciel ait été utilisé, le résultat serait quand même du code spaghetti ; peu importe à quel point la programmation orienté objet a été respectée, cela resterait du code spaghetti.
En tant que programmeurs, nous essayons tous de prévenir ces situations, mais c’est normal, c’est l’art de la programmation, c’est une partie de ce que ça veut dire d’être programmeur !
La mauvaise manière : Avoir peur du code d’autrui.
Le FIG signifie « Groupe d’interopérabilité de cadriciel » (Framework Interoperability Group)
Le PHP-FIG a été créé par un groupe de développeurs de cadriciel au php|tek en 2009. Depuis, de nombreux autres membres se sont inscrit et votent, augmentant la taille du groupe d’origine de 5 à plus de 20.
Quelques controverses existent concernant le PHP-FIG. Quelques personnes considèrent le PHP-FIG comme la meilleure chose qui soit arrrivée à la communauté PHP depuis PHP lui-même, d’autres considèrent le groupe comme quelques chose qu’il serait mieux d’oublier.
L’un des problèmes avec le PHP-FIG est qu’il se présente lui-même comme ceci dans leur FAQ :
L’idée derrière le groupe est de permettre aux représentants de projets d’échanger autour des points communs entre nos projets et trouver des manières de travailler ensemble. Notre principale audience est l’un l’autre, mais nous somme tout à fait conscients que le reste de la communauté PHP nous observe. Si d’autres gens veulent adopter ce que nous faisons, ils sont les bienvenus même si ce n’est pas l’objectif. Personne dans le groupe ne veut vous dire, en tant que développeur, comment construire votre application.
Néanmois, quand nous voyons le travail de plusieurs membres du groupe, nous voyons clairement que l’objectif est un peu contraire à l’assertion précédente. Ces membres travaillent sans relâche à faire du PHP-FIG un « groupe des standards PHP », ce qui était aussi le nom originel du groupe. Ils font cela en classifiant le travail du PHP-FIG comme « PHP moderne » dans leurs livres, sur leurs sites web, blogs, forums, etc., et en décrivant les autres manières comme arriérées.
L’un des problèmes concernant le PHP-FIG est que même si nombre de cadriciels et projets Open Source ont adopté plusieurs de leurs standards, ceux-ci gèrent principalement les problèmes sous un « angle cadriciel », ce qui les rends pratiquement inutilisables dans beaucoup de situations réelles de l’industrie.
Beaucoup de gens développent des logiciels pour l’industrie qui ont besoin d’être extrêmement efficaces, sécurisés et à coûts réduits, des logiciels que les clients ont envie d’acheter et d’utiliser. Ils ne peuvent pas s’ennuyer avec des standards qui se conforment aux besoins de fanatiques de cadriciel. S’ils le faisaient, ce serait un désastre pour les affaires.
Si un groupe de standardisation a besoin d’être créé, c’est pour refléter les intérêts de la communauté PHP, et pas uniquement les développeurs de cadriciel et des CMS Open Source. Il doit être représenté par les développeurs du langage PHP lui-même et être réprésenté par un plus grand nombre ayant le droit de voter.
Si vous décider d’adopter les standards développés par le PHP-FIG, vous devez comprendre que certains de ces standards - tels que le standards de l’autoloader PSR-0, PSR-4 et quelques autres - ont un impact direct sur votre manière de coder.
Quantité d’industries demandent des logiciels extensibles, fiables et à coûts réduits, ce qui ne peut simplement pas être effectué en suivant les standards du PHP-FIG.
La mauvaise manière : Suivre le PHP-FIG religieusement.
Le problème avec les développeurs, c’est que vous ne pouvez jamais dire ce qu’un développeur fait, jusqu’à ce qu’il soit trop tard.
– Seymour Cray sur defprogramming.com (en)
La programmation sécurisée est la façon d’écrire des programmes résistant à l’attaque de personnes malveillantes ou de d’autres programmes. La programmation sécurisée aide à protéger les données contre le vol et la corruption. De plus, un programme non sécurisé peut permettre à un attaquant de prendre le contrôle d’un serveur ou de l’identité d’une personne, avec des résultats allant d’un déni de service pour un simple utilisateur à la compromission de secrets, une perte de service ou des dommages sur les systèmes pour les milliers d’utilisateurs.
Tout programme informatique est une cible potentielle pour une attaque. Les attaquants tenteront de trouver des vulnérabilités dans vos applications. Ils tenteront ensuite d’utiliser ces vulnérabilités pour voler des secrets, corrompre les programmes et les données, prendre le contrôle de serveurs et de réseaux. La propriété de vos clients et votre réputation sont en jeu.
La sécurité n’est pas quelques chose qui peut être ajoutée à un logiciel !
Un programme non sécurisé peut demander une reconception étendue pour le sécuriser. Vous devez identifier la nature des menaces envers votre logiciel et incorporer des pratiques de codage dès le départ et tout au long du planning et du développement de votre application.
Sécuriser les ressources critiques d’un logiciel est plus important que jamais, puisque l’attention des attaquants s’est déportée vers la couche d’application. Une étude SANS de 2009 a révélé que les attaques envers les applications web constituent plus de 60% de toutes les attaques observées sur Internet.
PHP est inhabituel en ce qu’il est à la fois un programme informatique et un cadriciel web. Cela signifie que PHP a beaucoup de fonctionnalités web intégrées dans le langage qui rend très facile d’écrire du code non sécurisé.
La complexité tue. Elle aspire la vie des développeurs, elle rend les produits difficiles à planifier, construire et tester, elle introduit des défis des sécurité et cause une frustration des utilisateurs finaux et des administrateurs.
Afin que les applications soient conçues et implémentées avec de bonnes spécifications de sécurité, les pratiques de programmation sécurisées et une attention sur les risques de sécurités doivent être intégrées dans les opérations journalières et les processus de développement eux-mêmes.
Généralement, il est moins coûteux de construire des programmes sécurisés que de corriger les problèmes de sécurité après que le logiciel ai été livré, sans évoquer les coûts liés à une brêche de sécurité.
La mauvaise manière : Ne pas développer un programme sécurisé par défaut.
Il est facile de mal comprendre un document écrit, donc clarifions quelques points.
Q : Quel est le but de ce site et pourquoi l’approche par confrontation ?
R : Pour créer la discussion et la réflexion sur les pratiques actuelles et les vues extrêmes.
Q : Êtes-vous en train de dire que la programmation orientée objet est mauvaise ou fausse ?
R : Bien sûr que non ! Nous disons que toujours penser selon le paradigme orienté objet est mauvais. Lorsque vous pensez seulement en blanc et noir, vous vous trompez.
Il existe même différents problèmes au sein d’une même application. Le multi-paradigme est parfois la meilleure solution, tout dépend du problème que vous tentez de résoudre.
Lorsque vous tentez de fourrer un problème spécifique dans une solution inadaptée, de mauvaises choses se produisent.
Q : Êtes-vous en train de dire que tous les cadriciels sont mauvais ?
R : Nous essayons de ne pas juger des cadriciels spécifiques. Nous parlons du fait de toujours utiliser un cadriciel au-dessus de PHP.
Q : Si un cadriciel peut démarrer rapidement, quel est le problème ?
R : Si vous avez analysé la situation et les implications à long terme et que vous voyez que « démarrer rapidement » est le seul problème que vous avez, ce n’est pas si mal, mais alors il ne s’agit plus de développement logiciel, nous ne faisons que des solutions point-and-click.
Démarrer rapidement n’est pas de la conception logicielle, cela veut simplement dire que vous n’avez pas analysé votre problème et que vous ne comprenez pas les implications à long terme de votre choix.
Q : Êtes-vous en train de dire que les paquets tiers sont mauvais ?
R : Non. Nous favorisons l’usage des bibliothèques tierces. Du code que vous pouvez facilement intégrer dans vos projets sans limitations ou restrictions de quelque sorte. Elles sont géniales !
Q : Qui êtes-vous ?
R : Ce site a trait aux idées et combat les extrémismes dans la communauté PHP, il ne s’agit pas de célébrité ou de reconnaissance. Nommer des gens déplacera seulement l’attention des problèmes évoqués vers les gens qui évoquent ces problèmes. Restez concentré sur les idées.
Q : Quelles est votre expérience en développement logiciel ?
R : Les idées, pensées et conclusions exprimées sur ce site ne prennent pas tant d’expérience que ça si vous restez concentré sur le thème principal qui est de toujours faire une chose uniquement parce que les autres vous le dise.
PHP The Wrong Way sur Hacker News (en)
Pourquoi un mauvais code scientifique bat le code suivant les « bonnes pratiques » (en)
Comment programmer sans Programmation Orientée Objet (en)
Coders at work - Reflections on the Craft of Programming (en)
Les traits d’un programmeur efficace (en)
Lignes de conduite OWASP de la programmation sécurisée (en)
Principes de Sécurité par conception (en)
Survivre à la Grande Fin : la Sécurité PHP (en)
La refactorisation pour améliorer la conception de code existant (en)
La Pratique de la Programmation (en)
Le programmeur pragmatique (en)
Comprendre les langages de programmation (en)
Contribuer sur GitHub.