[sf 1.4.x] audit de code

[guiyomh]

Bonjour,

je doit réaliser un audit de code symfony.
j'aurais aimer avoir votre avis sur les points auquel je dois porté attention.

merci.

[stealth35]

t'es l'auditeur ou l’audité ?

[guiyomh]

Effectivement ça manque de précision, je suis l'auditeur.

Je pense que le code est sous du symfony 1.4 car le projet a déjà 1 an d'historique.

Apparement le client pour qui est développé cette application, a des doutes sur symfony, suites aux remontés de ses développeurs.
Après une longue discussion téléphonique, je pense plutôt que les développeurs devraient soit se remettre en causes, soit être formé sur symfony.

Je pense que je vais devoir chercher les problèmes de conception de l'application et les améliorations dû aux bonnes pratique php. Mais concernant symfony, j'aurais aimé avoir votre aide, pour m'indiquer ce qu'il faudrait chercher.

merci

[Nico_F]

Hmmm en vrac des points classiques :

Respect du modèle MVC (si on commence avoir des requêtes Doctrine dans les templates y a un début de malaise) et respect de la structure symfony elle même (vois comment ils utilisent les classForm, classTable, les actions etc.), cohérence du schema (très important), la manière dont ils surchargent les bases, utilisation des fichiers de config (les app.yml, routing.yml, settings.yml ne sont pas là pour décorer...à moins que...).

Ça c'est vraiment que pour la partie symfony, ensuite je pense que comme pour tout audit de code tu as déjà préparé tout ce qui est bonnes pratiques comme tu disais, conventions de code etc. et qui est tout aussi important que le reste.

Je suis loin d'être exhaustif mais voilà les premiers points qui me sont venus en tête.

[gototog]

Vérifie la bonne utilisation de l'ORM choisit. (j'ai déjà vu un code sous SF avec des requêtes a la mano...)

[stealth35]

Je comprend pas comment peut on auditer sur un sujet que l'on ne maitrise pas...

[Michel Rotta]

Partir sur l'audit d'une application écrite en symfony sans connaître symfony me semble difficile.

Je pense qu'il faut le prendre un niveau au dessus, c'est à dire qu'il sera difficile d'auditer le code en lui même. Par contre, il faudra auditer l'écriture et le respect des normes de développement objet et l'analyse projet.

Faire rapidement (au moins lire, mais faire c'est mieux), les 12 premiers jours du tutoriel jobeet permettrais d'avoir une bonne idée de la base (prévoire 12 heures).

[guiyomh]

Je connais bien symfony, la question n'est pas là.
Je connais également bien PHP. Je pratique PHP depuis plus de 6 ans et symfony depuis sa version 1.0.

J'ai client qui m'appelle pour me demandé d'auditer le code source de sont applications, car d'après ces développeurs symfony est pas un bon outils.

Au vu de mon expérience, avec symfony, j'ai dû mal a concevoir un tel discourt.

Je veux bien croire que les demande du client soit mal exprimé, et peut être difficile à concevoir. Mais je pense pas que ça soit irréalisable avec symfony.

Pour moi, il y a différente causes possible :
* les développeurs ne sont pas former à symfony et ne maitrise pas le sujet.
* la conception est mal faite
* les demandes client sont mal définis, voir mal loti (du coup ses demande peuvent paraître infaisable)

Enfin bref, je ne vois pas ce qui pourrait remettre en cause symfony dans sont projet.
(Je connais pas encore le projet dans ça totalité, j'ai crus comprendre que c'était de la gestion de stocke ou d'inventaire) avec un SI un peu complexe.

Prouver que la conception du site est mal faite ne seras pas dure si c'est réellement le cas. Par contre, avec toute l'aide en ligne de symfony, les joobeet et autre. Même ma grand-mère serais faire une appli symfony.

Ma question est donc de par votre expérience, vous qui faite également du symfony, quelle sont les erreurs fréquentes que vous avez rencontré.

Merci Nico_F et gototog.
Je note donc de porté une attention particulière sur les fichiers de configuration, les modèles de données et connexion au bases.


cordialement

[Michel Rotta]

Le plus gros problème de toutes les applications vient souvent d'un modèle mal conçu à l'origine. Ce qui va impliquer des modifications structurantes importantes durant le développement lorsque l'on va se rendre compte que certaines fonctionnalités ne peuvent être mise en place sur le modèle originel. On va alors le modifier, mais à minima pour impacter le moins possible sur ce qui a déjà été développé. Ceci est vrai pour tous types de projets, avec tous les langages et tous les framework.

Le deuxième point important (je ne sais les hiérarchiser avec le précédant, la place de deuxième n'est que le résultat de l'écriture) est l'absence d'une analyse suffisante du projet. Soit au niveau du fonctionnel, soit au niveau du développement lui même. Ceci n'est pas nécessairement le fait des équipes informatiques, cela peut aussi résulter de problèmes au niveau du donneur d'ordre.

Ensuite on va pouvoir mettre tout une série de manquement que tu as déjà identifiés, notamment des problèmes de formation de l'équipes. Tu peux aussi y rajouter un manque d'encadrement structurant dans ces équipes. On peut aussi parfois trouver des manques flagrants de connaissances en PHP sur les notions objets, les names spaces, les design parterne,... Mais ceci rejoins le manque de formation.

Reste les difficultés à mettre en œuvre le projet qui pourraient être liée à la gestion des priorités. Soit au niveau du projet, soit au niveau du donneur d'ordre qui interviendrait dans la gestion du projet.

Un des problèmes que tu vas rencontrer sera de gérer les éventuelles responsabilités de ton donneur d'ordre qui pourraient être directement liées au mauvais déroulement du projet. A toi de voir comment tu arriveras à gérer cet élément et comment tu pourras préserver ton indépendance quant aux résultats. C'est à prévoir avant la souscription du contrat d'audit (si c'est encore possible), pour protéger ton indépendance et tes conclusions. J'ai eu a gérer ce type de problème dans un projet indirectement lié à l'informatique, même si c'est l’informatique qui était partiellement en cause, le donneur d'ordre était directement responsable du désordre résultant. Mon rapport d'audit n'était, hélas, pas conforme à ce qu'il désirait lire, j'ai eu un mal de chien à être payé.

Une solution de travail, pour toi, consiste à utiliser une vue distante. Ne pas regarder les choses avec les yeux sur l'écran mais de très loin, très globalement, avant de descendre au niveau des détail. Ne surtout pas ce laisser avoir par des détails qui cacherait la foret. Un bon moyen pour détourner les yeux d'un auditeur d'un problème connu que l'on veut masquer consiste à lui donner un os à ronger, un bel os, bien visible mais sans grand intérêt au final. J'ai déjà utilisé cette technique, mais j'étais de l'autre côté de l'audit (j'ai connu les deux cotés à plusieurs reprises ). Le truc vient d'un amis, ancien contrôleur des impôts, il l'utilisait pour détourner les yeux des ces ex-confrères d'une véritable fraude pour leur donner de quoi travailler, sans trop avoir à chercher.

Surtout n'essayes pas de te dire, j'aurais fait ainsi, ils ne l'ont pas fait, c'est donc qu'ils ont eu tords, ton travail consiste à trouver ce qui n'a pas marché, pas ta solution pour que cela marche, c'est assez difficile à prendre comme position les premières fois.