La question de réinventer la roue revient souvent ici. Beaucoup de gens se trouvent un prétexte pour recoder un énième framework.
Il est vrai que tu apprendras des choses en essayant de coder toi même une version de ces couches, mais il faut le faire intelligemment. Par exemple :
1. Prendre quelques heures et faire un prototype, jouer avec, regarder si ça fonctionne, être fier de soi d'y être arrivé.
2. Comparer son code avec un framework reconnu. Avoir été devant les mêmes choix permet de comprendre les choix des auteurs des frameworks, ainsi que leurs limitations.
3. Ranger ton code dans un coin, utiliser le framework reconnu et attaquer vraiment ton projet.
J'ai fait ça maintes fois, j'ai appris énormément de trucs, mais mes projets reposent pleinement sur du code qui n'est pas à moi en lequel j'ai confiance. Sauf dans un cas parce que la fonctionnalité n'était pas vraiment couverte pour le langage que j'utilise, je n'avais pas le choix et j'ai eu raison car mon package est utilisé par de nombreuses personnes.
Je pense qu'on a tous tendance à vouloir recoder ces couches parce qu'au fond c'est facile. Tu sais déjà ce que tu dois faire, et traiter une requête HTTP, savoir les headers à utiliser, les status codes à renvoyer, c'est basique en fait. Les frameworks connus ont beaucoup de code et de fonctionnalités car ils couvrent beaucoup de cas spécifiques, c'est pour ça que je ne vanterai pas de pouvoir faire aussi bien, mais les cas de base faciles, le chemin est bien balisé. C'est pour ça que tous les quatres matins tu as un pékin qui vient te présenter un nouveau Router pour PHP. Mais bon, oui, c'est facile de parser une URL et de chercher le controller correspondant dans un array, tout le monde y arrive.
Bon et des fois t'as un gars ou une meuf qui arrive avec un nouveau Router, et là par contre le truc est nickel et plus performant que la concurrence. Mais ces gens ont déjà utilisé de nombreux autres routeurs (c'est un exemple, ça vaut aussi pour les modèles, les controllers, …). Tu ne verras pas un débutant arriver avec une innovation qui chamboule le monde de PHP.
Ensuite quand on parle de créer un jeu, là on attaque quelque chose de difficile : c'est toi seulement qui doit définir ce que tu dois coder, ce qui est déjà difficile. Tu as peu d'exemples pratiques car tous les jeux ont une bonne partie de fonctionnements uniques, ou ne sont pas open-source. C'est donc là dessus qu'il faut se concentrer.
Mais bon, comme je le disais, n'hésite pas à coder toi-même des briques dont tu veux comprendre le fonctionnement et les enjeux. Simplement, ne t'y attache pas, et pense à les remplacer par un équivalent bien maintenu quand tu en as l'occasion. Mais je pense que tu apprendras tout aussi bien simplement en lisant du code. C'est en forgeant qu'on devient forgeron il paraît, mais ça ne marche pas pour tout. Par exemple on ne s'improvise pas chirurgien en commençant par dix ans à charcuter des gens au hasard. On se tape dix ans d'études à lire ce qui a été fait avant, à s'entrainer sur des prototypes, apprendre à choisir le bon outil (framework) pour chaque opération, etc.
Enfin, ce qui est intéressant dans un framework c'est également de créer une architecture, un tout cohérent. Mais un jeu à besoin de ça aussi, il te laisse donc toute la place pour t'amuser et t'exprimer.
Donc, se reposer de plus en plus, c'est bien, ne pas se poser de questions c'est bête mais l'un n'implique pas l'autre.
Il est vrai que tu apprendras des choses en essayant de coder toi même une version de ces couches, mais il faut le faire intelligemment. Par exemple :
1. Prendre quelques heures et faire un prototype, jouer avec, regarder si ça fonctionne, être fier de soi d'y être arrivé.
2. Comparer son code avec un framework reconnu. Avoir été devant les mêmes choix permet de comprendre les choix des auteurs des frameworks, ainsi que leurs limitations.
3. Ranger ton code dans un coin, utiliser le framework reconnu et attaquer vraiment ton projet.
J'ai fait ça maintes fois, j'ai appris énormément de trucs, mais mes projets reposent pleinement sur du code qui n'est pas à moi en lequel j'ai confiance. Sauf dans un cas parce que la fonctionnalité n'était pas vraiment couverte pour le langage que j'utilise, je n'avais pas le choix et j'ai eu raison car mon package est utilisé par de nombreuses personnes.
Je pense qu'on a tous tendance à vouloir recoder ces couches parce qu'au fond c'est facile. Tu sais déjà ce que tu dois faire, et traiter une requête HTTP, savoir les headers à utiliser, les status codes à renvoyer, c'est basique en fait. Les frameworks connus ont beaucoup de code et de fonctionnalités car ils couvrent beaucoup de cas spécifiques, c'est pour ça que je ne vanterai pas de pouvoir faire aussi bien, mais les cas de base faciles, le chemin est bien balisé. C'est pour ça que tous les quatres matins tu as un pékin qui vient te présenter un nouveau Router pour PHP. Mais bon, oui, c'est facile de parser une URL et de chercher le controller correspondant dans un array, tout le monde y arrive.
Bon et des fois t'as un gars ou une meuf qui arrive avec un nouveau Router, et là par contre le truc est nickel et plus performant que la concurrence. Mais ces gens ont déjà utilisé de nombreux autres routeurs (c'est un exemple, ça vaut aussi pour les modèles, les controllers, …). Tu ne verras pas un débutant arriver avec une innovation qui chamboule le monde de PHP.
Ensuite quand on parle de créer un jeu, là on attaque quelque chose de difficile : c'est toi seulement qui doit définir ce que tu dois coder, ce qui est déjà difficile. Tu as peu d'exemples pratiques car tous les jeux ont une bonne partie de fonctionnements uniques, ou ne sont pas open-source. C'est donc là dessus qu'il faut se concentrer.
Mais bon, comme je le disais, n'hésite pas à coder toi-même des briques dont tu veux comprendre le fonctionnement et les enjeux. Simplement, ne t'y attache pas, et pense à les remplacer par un équivalent bien maintenu quand tu en as l'occasion. Mais je pense que tu apprendras tout aussi bien simplement en lisant du code. C'est en forgeant qu'on devient forgeron il paraît, mais ça ne marche pas pour tout. Par exemple on ne s'improvise pas chirurgien en commençant par dix ans à charcuter des gens au hasard. On se tape dix ans d'études à lire ce qui a été fait avant, à s'entrainer sur des prototypes, apprendre à choisir le bon outil (framework) pour chaque opération, etc.
Enfin, ce qui est intéressant dans un framework c'est également de créer une architecture, un tout cohérent. Mais un jeu à besoin de ça aussi, il te laisse donc toute la place pour t'amuser et t'exprimer.
Citation :Je trouve que de plus en plus, on se repose sur des utilitaires sans se poser assez de questions sur comment ça fonctionne.
Donc, se reposer de plus en plus, c'est bien, ne pas se poser de questions c'est bête mais l'un n'implique pas l'autre.