Discussion :

[setni]

Cher développeurs,

Aujourd'hui, j'ai attend un petit niveau (junior) sur php et Symfony.
Mon objectif dans les prochains mois est de passer du stade d'amateur à celui de pro.

Voici un exemple de mon code

https://github.com/setni/allvisio

Ou encore

https://github.com/setni/mcmakler

Est-ce que vous pouvez me donner votre avis et aussi des conseils pour passer au stade pro?

Merci beaucoup par avance


PS : Merci d'éviter les "c'est null" ou autres. Je cherche vraiment du constructif

[Tsilefy]

En parcourant rapidement, c'est difficile à dire pour moi puisque tes applications sont essentiellement des CRUDs, c'est-à-dire qu'il n'y a pas beaucoup de code métier. Ça montre que tu maîtrises suffisamment bien le framework, mais ça ne dit rien sur le reste de tes compétences.

J'aurais juste un conseil: évite d'utiliser des noms français dans ton code et si vraiment c'est inévitable, ne mélange pas les deux (ex: setAdresse).

Le plus simple est d'écrire en anglo-américain à 100%, c'est la lingua franca de la programmation.

[setni]

Merci

Oui je vois pour les commentaires

J'ai aussi quelques Repo de php pur

[Celira]

J'aurais juste un conseil: évite d'utiliser des noms français dans ton code et si vraiment c'est inévitable, ne mélange pas les deux (ex: setAdresse).

Le plus simple est d'écrire en anglo-américain à 100%, c'est la lingua franca de la programmation.

+1 et -1 à la fois sur cette remarque :
+1, parce que reprendre un code écrit dans une langue qu'on ne parle pas, c'est vraiment horrible. Donc si jamais il y a un pouième de chance que ton code soit relu/utilisé par un non-francophone, c'est mieux de coder directement en anglais.

-1, parce que des fois on a pas le choix, par exemple, lorsqu'on bosse pour un client qui fixe des conventions de nommage et/out les entités à utiliser. Dans ce cas, il faut éviter le mélange des langues SAUF pour les choses imposées par le langage ou le framework : comme les accesseurs (getVariable/setVariable), les méthodes "magiques" (__construct, __destroy...), les implémentations de classes abstraites, etc... Donc setAdresse est acceptable (parce que c'est un accesseur), alors qu'une horreur du genre createLettreIfNonRenseignée ne le serait pas du tout.

A part ça, ton code a l'air propre, mais comme l'a dit Tsilefy, c'est du code assez simple, fonctionnellement parlant. La seule façon de tester réellement tes compétences est de faire des choses un chouia plus compliquées.

Tu peux par exemple essayer de coder un mini-chat (ce qui utilise en général plein d'AJAX et nécessite de gérer les conflits de gens qui parlent en même temps, et les petits malins qui postent du javascript avec des "coucou !" en boucle infinie...).
Ou alors les vieux défis PHP de DVP : Défi #01 : Développer une liste de tâches avec un framework PHP.
Tu as aussi le bon vieux projet de la gestion d'une médiathèque, avec l'interface utilisateur pour la recherche multi-critères, l'emprunt et le retour de document et l'interface admin, avec l'interface CRUD des documents et des utilisateurs, la gestion des réservations (avec un ordre de priorité, la gestion des doublons, quelque chose qui signale que le document réservé est disponible...), les mails de retards...

Bon évidemment, la plus grosse différence entre un projet amateur et un projet pro est qu'en général on ne travaille pas à partir de rien : on modifie/complète/corrige des applications déjà existantes. Donc tu peux essayer de chercher un exemple de projet PHP sur le web, qui soit un peu vieux et essayer de le réécrire avec une version plus moderne, ou avec un autre framework...

[Seb33300]

Essaye aussi de respecter les conventions de codages :
http://symfony.com/doc/current/contr...standards.html

[Tsilefy]

parce que des fois on a pas le choix, par exemple, lorsqu'on bosse pour un client qui fixe des conventions de nommage et/out les entités à utiliser.

Dans ce cas, le client a toujours raison :-)

Bon évidemment, la plus grosse différence entre un projet amateur et un projet pro est qu'en général on ne travaille pas à partir de rien : on modifie/complète/corrige des applications déjà existantes.

Tout-à-fait, le refactoring et l'extension (même de tes propres applications) est important. Autre différence majeure: on n'a pas de deadline pour un projet amateur...

[CosmoKnacki]

Sur allvisio dans ton defaultController:

- test du userAgent:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (preg_match('/iphone/i',$ua) || preg_match('/ipad/i',$ua) || preg_match('/ipod/i',$ua))

Il s'agit de rechercher des chaînes littérales, autant utiliser stripos ça ira plus vite. Ou une mise en facteur: if (preg_match('/ip(?:[oa]d|hone)/i', $ua)) ou en utilisant le modificateur "Study" pour rester lisible et profiter d'une recherche rapide pour chacune des branches: if (preg_match('/iphone|ipad|ipod/Si', $ua)). (Cela dit la différence de performance n'est pas très importante dans ce cas de figure, c'est une broutille, il s'agit plus d'utiliser "une bonne façon".)

- test de l'email:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if($email != "" || preg_match("#^[a-z0-9._-]+@[a-z0-9._-]{2,}\.[a-z]{2,4}$#", $email))

PHP dispose de filter_var avec l'option FILTER_VALIDATE_EMAIL qui acceptera bien plus d'emails correct que ta pattern.

- test de l'extension:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if(preg_match('/(.php|.php2|.php3|.html|.htm|.xml|.xhtml|.asp|.css|.cfm|%00)/', $nomF))

Là c'est carrément faux, le point représente n'importe quel caractère (sauf un saut de ligne) dans une pattern, pour décrire le caractère . tu dois l'échapper: \.. De plus, vue qu'elle n'est pas ancrée rien ne prouve que ".php" est l'extension du nom de fichier, exemple: jesuislefichiertextediabolique.php.txt.

Sinon symfony a le service Validator qui peut servir à ce genre de choses.

- ligne 189:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  } else {
 
                if ( in_array($ext, $pattern) ) {

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 } elseif ( in_array($ext, $pattern) ) {

évitera un niveau d'imbrication.