Bonjour,
Une petite reflexion que je me fait depuis peu, en connaissant mieux cakephp.
Je vois qu'en fait il est impossible voir tres difficile de migrer de framework en framework, par exemple sur le "Model" il y a tellement de facilité que d'une part, on a apprend pas vraiment a manipuler PHP et SQL, et que les facilités données comme le comportemant "containable" permet difficilement une migration.

Bref je pense qu'il faut se faire qu'en cas de soucis, on est captif du framework si on utilise trop les fonctionnalités spécifiques.
D'un autre coté, le gain en vitesse de developpement est peut etre appreciable apres que l'on ai pu apprendre a s'en servir. ce qui me fait quand meme dire que apprendre un framework n'est pas apprendre php, et qu'une personne qui connais bien PHP POO, aura plus de facilité que celui qui connais un Framework simplement.

11 réponses


real34
Réponse acceptée

Bonjour,

Chaque chose que tu apprends sur un framework est un nouveau concept acquis. En comparant 2 frameworks tu pourras te faire alors une idée des points communs qu'il sont (et que tu maitrises déjà), mais surtout de leurs différences. C'est là qu'en creusant tu comprendras les choix faits par les uns et les autres.

A force de comparer tu finiras par trouver un framework qui correspond à ta "philosophie" et ton style de développement ... et tu prendras du plaisir à développer au quotidien. Le reste n'est qu'expérience : tu apprends au fur et à mesure des problématiques et challenges à résoudre, ainsi que des erreurs effectuées. Si tu es un "bon" développeur PHP il n'y a aucune difficulté à se plonger dans le coeur d'un framework pour comprendre comment cela marche. Cet apprentissage sera bien sûr facilité et accéléré si tu suis une formation, des cours / tutos en ligne ou si tu es accompagné par un développeur plus expérimenté.

Ceci n'a aucune spécificité à PHP ou CakePHP. C'est la base même d'une carrière de développeur : apprendre, comparer, réutiliser et transposer ses connaissances pour ... apprendre encore. Dans 5 ans tu seras encore développeur et peut-être que PHP sera caduque, si dès aujourd'hui tu apprends les concepts il sera simple d'évoluer. Si tu n'apprends que le "comment faire" cela sera plus difficile.

Ca fait un petit moment que tu lance des topics dans le même thème. Si tu n'es pas satisfait du framework, je ne vois pas pourquoi tu t'obstines à nous faire dire que les frameworks c'est le mal...

Utilises ce qui te vas le mieux ;)

En règle général quand tu utilises un framework plutôt qu'un autre c'est que tu le maitrises mieux qu'un autre et que tu as fait de la veille sur les frameworks existants afin de savoir si celui que tu utilises est le plus adapté à tes besoin. Il n'y a donc pas de raison pour en changer... Je dis bien en règle général...

Deuxièmement, tu dis qu'apprendre un framework ce n'est pas apprendre PHP, en tant que professionnel je peux t'affirmer que par contre, apprendre un framework sans connaitre PHP c'est impossible. Tout simplement car un framework est souvent basé sur le model MVC et presque toujours codé en POO. Une personne qui ne connait pas le PHP est incapable de comprendre la POO.

Troisièmement, attention de ne pas trop poster dans la même journée, choisis bien tes questions...

sylvain
Auteur

@coloo: Je cherche des réponses a mes réflexions. Je ne dit pas que tout est mal ou bien. Je dit qu'il faut savoir ou on s'aventure, enfin je pense.

@mespeche: sans les tutos de garfikart, je pense que j'aurais jamais compris toutes les subtitlités de cakephp.

J'ai appris le php (sans poo) avant cakephp, et le fait d'apprendre cakephp m'a fait comprendre beaucoup de chose sur php poo, et je me considère maintenant plutot bon en php poo (grace a cakephp donc).
Par ailleurs je pense que migrer de framework en framework c'est plus facile que de dev perso à framework. apres c'est rare de migrer, sauf quand le nouveau framework approrte beaucoup de nouvelle chose, dans ce cas tu devra apprendre le nouveau framework : n'es-ce pas un bon moyen d'apprendre un framework que de migrer d'un framework a partir d'un autre (ça me donne meme des idée ^^) ou bien de repartir a zero justement.

et pis si tu change de framework tout les 4 matin au moins apres tu sera bon partout!!!!

bref je me rend compte que mon poste ne sert a rien, donc je vais quand même dire que les framework c'est bien, de passez du temps a en choisir un c'est bien, et de le garder c'est bien, d'en changer c'est pas grave. Mais en tout cas c'est important d'en connaitre au moins un je pense.

Je suis tout a fait d'accord avec real34.

sylvain
Auteur

@real34, merci pour cette explication.
Je ne suis pas développeur à la base, juste un petit patron, qui a envi de comprendre comment mettre en place une architecture solide pour les prochaines années. Je tests plusieurs solutions pour voir celles qui sera la plus pérenne et surtout la plus souple.

Dans 5 ans, j'espère ne pas toucher une ligne de code, mais je serais au courant un peu de la façon de gérer les projets technique.
Si par exemple dans l'entreprise je me lance a tete perdu sur cakePHP alors en cas de soucis, il me faudra un expert sur ce framework.
Je pourrais pas prendre un developpeur qui a eut 5 ans d'experience en symfony ou zend pour etre operationnel tout de suite.

Bref ce que je veux dire, c'est qu'au niveau d'une entreprise le choix n'est pas aussi simple. Devrais je alors embaucher que des developpeurs qui aime cakephp ?

sylvain
Auteur

Je ne connais aucun développeur expérimenté qui aime cakephp. Les deux seul que je connaisse fond leurs propres microframework. Et évidemment ne peuvent pas trop m éclairer sur cake

sylvain
Auteur

@eeal34: que veux tu dire par "le comment faire ?"
Il me semble que l apprentissage sur le tas se fait que par la.

sylvain
Auteur

Je pense que m'as façon d'apprendre est à revoir...

Pour moi en rester au "comment faire" lors de son apprentissage signifie faire en sorte que cela marche ... et s'arrêter lorsque c'est le cas. C'est très bien car le client est content, mais s'en satisfaire ralentit considérablement l'acquisition de nouvelles compétences.

L'étape suivant qui est la plus importante est le "quoi faire" (terme plus ou moins arbitraire que j'invente sur le tas ;)). C'est pour moi se demander 3 choses :
* qu'est-ce que j'ai fait pour résoudre le problème ? et donc comprendre exactement ce que fait chaque ligne de code que l'on a écrit ou chaque librairie que l'on utilise (éviter le copier / coller idiot)
* pourquoi est-ce cette solution fonctionne ? et donc comprendre la logique derrière, le design pattern et de manière plus générale le concept sous-jacent (c'est ceci qui se transpose quelque soit le framework)
* comment pourrai-je faire mieux ? ceci amène directement à ce que l'on appelle le "refactoring". Il y a souvent une meilleure manière de faire ce que l'on a dejà fait ou d'organiser son code de manière plus lisible et réutilisable.

Le "comment pourrai-je faire mieux" est également alimenté par une phase de veille : suivre les nouveautés apportees par le framework, des articles de blog ou des publications faites par des gens compétents dans la techno utilisée etc... Avec Twitter, les blogs et le monde de l'open source il est de plus en plus facile de rester au contact de développeurs nettement plus expérimentés et d'apprendre quotidiennement. Si tu as déjà lu plusieurs articles ou vu passer plusieurs plugins pour faire une chose lors de ta veille, le jour où tu en aura besoin tu sauras exactement où regarder ...

Etant également chef d'entreprise je comprend totalement ton souci de "recrutement de main d'oeuvre" pour pouvoir recruter quelqu'un de qualifié le jour venu. Bien que la transposition des connaissances d'un framework vers un autre est assez rapide si le développeur a un niveau correct cela a un coût. Les bons développeurs CakePHP sont je pense plus rare aujourd'hui en France que leurs équivalents Symfony (mais les mauvais aussi du coup ...). Pour le coup il n'y a pas de recette miracle : il faudra le moment venu recruter la bonne personne ou avoir suffisamment confiance pour pouvoir former celle-ci à ta manière (mais ceci me semble valable quelque soit le framework choisi).