1. #1
    Membre éprouvé

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 532
    Points : 1 013
    Points
    1 013

    Par défaut Symfony et les autres sont-ils obligatoires ?

    Bonjour,

    Pourquoi ne peut-on plus aujourd'hui, se positionner sur un poste de développement sans la maîtrise d'un framework ? Ne peut-on réellement plus développer avec ses propres méthodes, en respectant les concepts de développement (MVC par exemple). En quoi un code fonctionnel et propre a moins de valeur s'il ne rentre pas dans les schémas de tel ou tel framework ? En quoi un code maison n'est plus considéré comme professionnel, même s'il répond au cahier des charges et aux contraintes de sécurité ?

    Je vois venir l'argument du "code maintenable", "de l'outil commun" ou le fameux critère "productif". A vouloir tout standardiser, ne risquons-nous pas de perdre une certaine diversité dans la manière de programmer, et donc de finir par être des robots peu créatifs qui ne codent plus rien, et qui passent leur temps à lancer des lignes de commandes pour générer automatiquement leur script ?

    En quoi installer des bundles et générer du code à partir de ligne de commandes peut encore être considérer comme du développement ?

    Zecreator.
    "Rien ni personne décide de ta vie. Ton bonheur comme ton malheur, tu les dois à toi seul."

  2. #2
    Membre expérimenté
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    365
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 365
    Points : 1 590
    Points
    1 590

    Par défaut

    Bonjour,

    Je ne suis pas développeur web et je ne connais pas Symfony. Je développe surtout en C++.

    En entreprise, je préfère que les développeurs utilisent un framework externe à l'entreprise plutôt qu'un framework maison, à condition bien sûr que ledit framework externe réponde au besoin.

    La principale raison est qu'utiliser un framework externe est plus productif.
    En effet :
    • Le framework externe est déjà codé. On gagne du temps en développement et en maintenance.
    • Un framework externe est généralement plus riche en fonctionnalités.
    • Un framework externe est généralement moins bogué.
    • Un framework externe est généralement mieux documenté.
    • Un framework externe est généralement plus performant.
    • Un nouveau venu dans l'entreprise peut déjà connaître ce framework externe et bénéficier de son expérience.


    Certes, concevoir et implémenter un framework maison est plus enrichissant et plus agréable.
    Mais il faut nuancer ce point : il est enrichissant et agréable principalement pour les premières personnes qui l'implémenteront.
    Plus tard, les nouveaux développeurs embauchés, au lieu de travailler avec un framework externe de qualité, subiront un framework maison bogué, mal codé et peu voire pas documenté.
    Après tout, dans un sondage récent, on a vu que, ce qui agaçait le plus les développeurs, en moyenne, c'était d'écrire la doc.

    Réinventer la roue, c'est très enrichissant, mais ça doit rester hors de l'entreprise, chez soi, dans son temps libre.

  3. #3
    Membre éprouvé

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 532
    Points : 1 013
    Points
    1 013

    Par défaut

    Avant que cela ne parte en Troll, on est tous d'accord pour dire que l'un des principaux avantages d'un Framework, c'est sa productivité. C'est la première raison qui poussent les entreprises à vouloir l'utiliser. De même, on est quasi certains de retrouver les mêmes frameworks, quelle que soit l'entreprise que l'on rencontre. Un gain de temps énorme sur la formation. Il y a un effet "tronc commun", qui fini par nous obliger à les utiliser.

    Cependant, si l'on en revient à son métier de développeur, l'utilisation de framework me questionne :

    - Est-ce vraiment moi qui développe, ou bien le Framework ?
    - Les bugs sont-ils les miens, ou celui du Framework ?
    - Mon métier n'est-il pas réduit à être un simple opérateur derrière un système d'usinage ?
    - Sera t-on encore capable, dans 10 ans, de développer sans Framework ?

    Mon questionnement vient des profils récemment rencontrés lorsque j'ai eu besoin de recruter un développeur web pour mon équipe. J'ai rencontré trois développeurs, tous mettaient en avant leur maîtrise des Frameworks courants (Symphony, CakePHP, Angular...). Mais j'avais besoin de connaitre leur maîtrise réelle des langages, et des concepts MVC. Car pour moi, en toute logique, un développeur doit être capable de produire du code à partir de rien, juste avec ses compétences. Là est tout l'intérêt d'embaucher un développeur.

    Pour cela, je leur ai soumis ce questionnaire. Une catastrophe au point où je me suis demandé si les mecs avaient déjà codé quoique ce soit avant. Et je me suis dis que c'était là, l'effet pervers du Framework. Mais ce qui ma vraiment sauter aux yeux, ceux sont leur réponses aux questions générales. Il n'y a aucune passion, ni réelle curiosité dans leur approche du métier de développeur. A croire qu'ils subissent leur métier plus qu'ils ne le vivent.

    A vouloir s'enfermer dans des automatismes/conformismes (je ne leur jette pas la pierre, c'est la demande actuelle du job), ces développeurs étaient en train de perdre leur savoir-faire (l'ont-ils déjà eu, je ne sais pas). Pire, ils n'apprenaient plus rien.

    Du coup, ne faudrait-il pas différencier développeur et frameworker ? N'est-ce pas, en fin de compte, 2 métiers avec un savoir-faire différents ? Je fini par me poser la question...

    Zecreator.
    "Rien ni personne décide de ta vie. Ton bonheur comme ton malheur, tu les dois à toi seul."

  4. #4
    Expert éminent Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 402
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 402
    Points : 7 022
    Points
    7 022

    Par défaut

    Citation Envoyé par zecreator Voir le message
    - Est-ce vraiment moi qui développe, ou bien le Framework ?
    - Les bugs sont-ils les miens, ou celui du Framework ?
    - Mon métier n'est-il pas réduit à être un simple opérateur derrière un système d'usinage ?
    - Sera t-on encore capable, dans 10 ans, de développer sans Framework ?
    - C'est toi qui tape sur le clavier jusqu'à preuve du contraire, pas le framework.
    - Les bugs qui relèvent de ton implémentation sont les tiens, ceux qui relèvent du framework relèvent du framework. A question stupide réponse stupide.
    - On va t'envoyer à l'usine sur un poste de tourneur-fraiseur ou même plus cool en contrôle qualité pendant quelques mois et puis on en rediscutera
    - Est-on capable aujourd'hui de développer sans librairies ? Je suis certain que si on avait accès à des discussions de dev d'il y a 20 ans, on aurait les mêmes reproches à propos des librairies ...

    Citation Envoyé par zecreator Voir le message
    Du coup, ne faudrait-il pas différencier développeur et frameworker ? N'est-ce pas, en fin de compte, 2 métiers avec un savoir-faire différents ? Je fini par me poser la question...
    Et pourquoi pas différencier les vrais développeurs qui bossent avec notepad des fillettes qui utilisent un EDI ? Ou ceux qui n'utilisent aucune dépendance et qui codent absolument tout ?

    ...

    Bon j'arrête de te provoquer, de mon point de vue un mauvais développeur est un mauvais développeur, qu'il utilise un framework ou pas ne change rien, et utiliser un framework ne transforme pas un développeur en mauvais développeur de même qu'utiliser des librairies n'a rendu un développeur mauvais.

    Tu as simplement rencontré des mauvais profils c'est tout. Ceci dit si tes critères d'exigences c'est ce questionnaire t'es pas sorti du sable !
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

  5. #5
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    642
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 642
    Points : 2 286
    Points
    2 286

    Par défaut

    Oui, il y a de gros problèmes autour des frameworks aujourd'hui :

    • Ils en font souvent beaucoup trop par rapport à ce dont le développeur a réellement besoin et cachent mal leurs "dessous" techniques, ce qui fait qu'on se traîne des dépendances, de la configuration et des problèmes dont on aurait jamais eu à se préoccuper normalement.

    • La traduction d'une approche théorique en framework est un passage ultra délicat et pas toujours bien réussi. Il suffit d'une seule fausse bonne idée dans l'implémentation pour forcer les utilisateurs du framework à faire des trucs complètement alambiqués voire contraires à la philosophie d'origine. Sans compter les auteurs de frameworks qui décident sur un coup de tête de renommer à leur sauce tous les concepts préexistants, ou qui ne sont même pas au courant qu'ils existent.

    • Beaucoup de développeurs apprennent l'aspect de surface d'un framework sans maîtriser les concepts intemporels de programmation qui sont mis en oeuvre derrière. Au rythme où se succèdent les frameworks à l'heure actuelle, ce sont des connaissances qui se périment très vite.


    L'uniformisation en soi ne me gêne pas, tant qu'on parle d'une théorie comprise par tous et d'abstractions que tout le monde s'accorde à nommer pareil. En d'autres termes, les frameworks ne sont pas mauvais tant qu'on en comprend les ressorts et qu'on serait capables de les réimplémenter nous-mêmes. C'est l'uniformisation vers des produits parfois dysfonctionnels à grands coups de hype superficielle qui en effet est plus inquiétante.

    Après, le développement maison n'est pas la seule alternative aux gros frameworks, il existe aussi des bibliothèques plus petites et mieux segmentées.

  6. #6
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 565
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 565
    Points : 18 671
    Points
    18 671

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    snip
    C'est pour ça qu'il faut savoir calculer de tête, rapidement, même si on a une calculatrice(ou un smartphone) sous la main. Accélérer ce que l'on comprend, c'est bien. Accélérer ce que l'on ne comprend pas, c'est "paf muret'.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #7
    Membre éprouvé Avatar de Nico_F
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2011
    Messages
    711
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : avril 2011
    Messages : 711
    Points : 1 277
    Points
    1 277

    Par défaut

    Globalement je suis d'accord avec ce qui a été dit notamment par Pyramidev pour tout ce qui concerne productivité, nouveau dev opérationnel etc. Les arguments classiques

    En quoi installer des bundles et générer du code à partir de ligne de commandes peut encore être considérer comme du développement ?
    Pour moi il fait distinguer le code productif et le code créatif. On ne se lancera pas dans les deux dans le même contexte.
    En tant qu'employé ou indépendant, les contraintes de productivité nous laissent peu de place à la créativité : tout simplement parce que ce n'est pas ce qui est demandé : on veut délivrer un produit répondant à tel besoin le plus vite possible et le mieux possible. Et c'est ça que nous apportent les framework et les libs : des outils de qualité qui nous font gagner du temps.
    Si tu veux être créatif, fais ça sur ton temps libre, crée ou participe à un projet open-source, fais toi une lib qui ne dépend d'aucune autre et utilise là ailleurs une fois qu'elle est fonctionnelle. Dès qu'elle est terminée, si tu veux l'utiliser dans un projet "productif", tu en fais un bundle et tu l'installes comme si c'était le bundle d'un autre.

    Maintenant l'erreur qu'on a tous fait au moins une fois (et qu'on fait peut-être encore) lorsqu'on a utilisé un framework c'est de ne pas s'en abstraire dans l'implémentation.

    Aujourd'hui beaucoup d'entreprises et beaucoup de développeurs se lancent dans un nouveau projet : première question technique "on utilise quel framework ?".
    Comme si le choix du framework était une contrainte métier.
    Comme si le développement ne pouvait pas commencer avant d'avoir choisi le framework.
    Comme si on voulait commencer par s'enfermer dans un choix technique non réfléchi sur lequel il sera souvent impossible de revenir par la suite.

    Et c'est ce qui se passe. On commence par choisir Symfony (ou un autre) on garde la structure standard proposée (parce que c'est standard donc bien pratique), on met des annotations dans tous les sens (parce que c'est bien pratique aussi et qu'on gagne du temps), on génère les CRUD parce que si déjà on peut le faire on aurait bien tort de se priver, etc. Et on a un magnifique prototype avec le label : SYMFONY-FOR-EVER dessus et des dépendances au frameworks dont on ne sortira plus jamais à moins de repasser sur quasiment tout.

    En réalité, l'erreur se trouve là : on lie trop souvent son développement au framework : le développement d'un projet devrait commencer AVANT le choix d'un framework, avant le choix d'une base de données aussi pourquoi pas. Développer les packages du domaine ne nécessite à priori aucune (ou très peu de) lib externe. Parce que si une règle de mon business est "une fois que j'ai créé un user je lui envoie un mail" : ça doit se produire indépendamment du framework, de l'ORM ou de la BDD utilisés. Le framework vient se greffer AU DESSUS du domaine pour permettre une interaction avec un utilisateur quelconque : c'est la couche applicative. S'abstraire du framework est la meilleure manière d'utiliser le framework.

    Donc à la question "Symfony et les autres sont-ils obligatoires ?", je serai tenté de te dire : que pour des raisons de productivité, oui ils le sont. Un bon développeur Symfony va plus vite que le même bon développeur from scratch.
    Maintenant le "légèrement moins bon" développeur Symfony va souvent faire l'erreur de baser tous ses développements sur le framework alors qu'il pourrait isoler son dev et faire en sorte qu'il fonctionne ailleurs qu'avec Symfony ... mais pour des raisons de temps et parfois aussi de compétences, il est très fréquent de voir du code métier totalement dépendant du code applicatif. Et c'est là qu'on se rend compte que le "légèrement moins bon" développeur Symfony oublie qu'il peut aussi faire des POPO (Plain Old PHP Object) qui n'étendent et ne dépendent de rien au lieu de tout faire à la sauce Symfony/Doctrine.

    Pour ton questionnaire deux questions importantes pour moi seraient :
    Connais-tu et appliques-tu les principes S.O.L.I.D. ?
    Maitrises-tu la notion de Separation of concern ?

    Mais ça s'applique plus à du dev back (l'utilisation de Symfony également cela dit).




    TL;DR: Les frameworks sont un must-have en terme de productivité et permettent de standardiser le développement. En revanche le choix du framework (un micro ou un très gros) doit être totalement indépendant du reste et peut se faire tard dans le cycle de développement d'un projet. On prendra le soin d'isoler le code métier (qui lui ne peut pas être généré ou remplacé par une lib toute faite) et de ne le faire dépendre d'aucune contrainte technique du type ORM/Framework/BDD etc. C'est à ce niveau là qu'un développeur doit apporter de la valeur à un projet.

  8. #8
    Membre éprouvé

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 532
    Points : 1 013
    Points
    1 013

    Par défaut

    Ce qui m'a toujours gêné dans les frameworks, quel qu'il soit, c'est la multiplication d'opérations et le nombre de fichiers qu'il faut déployer par défaut. Je prends pour exemple ce tutorial sur Symfony 2, très bien fait.

    Le nombre incroyable de manipulations et de commandes en ligne que l'on doit faire pour obtenir quelques pages web connectées à une base mySQL. Alors c'est sûr, ça fonctionne bien. Mais on a passé plus de temps à configurer des scripts et à ouvrir la console Windows, qu'à programmer. On a 30 Mo de fichiers à déployer, pour seulement 4 pages web qui pourraient tenir sur moins de 1Mo en évitant le framework. Et ce sentiment de n'avoir rien codé, c'est frustrant...

    Je vois bien là l'intérêt "productif" d'utiliser un framework, on obtient le bon résultat en quelques manip. Mais à quel prix. On laisse de coté son métier de développeur en ayant une confiance aveugle dans le framework, parce que c'est celui qui est utilisé partout, et que c'est obligé. Ils sont tous fais à partir des mêmes moteurs.

    Marco46 : je te sens un peu sanguin sur le sujet

    Je me demande juste ce qu'il reste aujourd'hui du métier de développeur. Ceux que l'on tag de développeur "à la papa" et qui refusent le conformisme des frameworks pour privilégier leur épanouissement technique, sans vouloir être élitistes. Ceux qui souhaitent pratiquer leur métier avec le vrai plaisir de le faire. Sont-ils vraiment devenus ringards et inutiles ? Le contexte du métier tourne t-il définitivement autour de la productivité et de la rentabilité ?

    Zecreator.
    "Rien ni personne décide de ta vie. Ton bonheur comme ton malheur, tu les dois à toi seul."

  9. #9
    Membre éprouvé Avatar de Nico_F
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2011
    Messages
    711
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : avril 2011
    Messages : 711
    Points : 1 277
    Points
    1 277

    Par défaut

    Citation Envoyé par zecreator Voir le message
    Le nombre incroyable de manipulations et de commandes en ligne que l'on doit faire pour obtenir quelques pages web connectées à une base mySQL. Alors c'est sûr, ça fonctionne bien. Mais on a passé plus de temps à configurer des scripts et à ouvrir la console Windows, qu'à programmer. On a 30 Mo de fichiers à déployer, pour seulement 4 pages web qui pourraient tenir sur moins de 1Mo en évitant le framework. Et ce sentiment de n'avoir rien codé, c'est frustrant [...] Je me demande juste ce qu'il reste aujourd'hui du métier de développeur
    Et c'est normal : dans ce tuto il n'y a aucun code métier : et c'est ça qu'il reste du métier de développeur : le plus important c'est le code métier. Coder un système de routing peut-être intéressant sur un projet à part, mais si tu dois t'amuser à recoder un système de routing sur chaque nouveau projet tu perds un temps fou, et surtout ça va rapidement te lasser. Donc pour t'éviter cette tache répétitive et n'apportant aucune valeur, tu lances un script qui fait ça à ta place

    Citation Envoyé par zecreator Voir le message
    Je vois bien là l'intérêt "productif" d'utiliser un framework, on obtient le bon résultat en quelques manip. Mais à quel prix. On laisse de coté son métier de développeur en ayant une confiance aveugle dans le framework, parce que c'est celui qui est utilisé partout, et que c'est obligé. Ils sont tous fais à partir des mêmes moteurs.
    Tu fais la même confiance aveugle dans ton langage de programmation que d'autres dans leur framework.
    Et si faire moins de code "boilerplate" c'est mettre son métier de développeur de coté je pense que tu n'as pas encore saisi la valeur qu'un développeur est supposé apporter.

    Ceux que l'on tag de développeur "à la papa" et qui refusent le conformisme des frameworks pour privilégier leur épanouissement technique, sans vouloir être élitistes. Ceux qui souhaitent pratiquer leur métier avec le vrai plaisir de le faire. Sont-ils vraiment devenus ringards et inutiles ? Le contexte du métier tourne t-il définitivement autour de la productivité et de la rentabilité ?
    Tu pars du principe qu'un dev utilisant un framework ne pratique pas son métier avec le vrai plaisir de le faire ? Parce que si c'est le cas, là encore tu te trompes. Je prends plus de plaisir à développer des fonctionnalités qui n'existent pas encore, et qui sont uniques à mon projet qu'à redévelopper un système de routing, de container de service ou de formulaire lorsque j'en ai des dizaines à disposition qui non seulement font ce que j'attends d'eux, mais qui en plus évoluent bien mieux que je n'aurais été capable de faire moi même.


    Si tu es un jeune développeur je comprends cette frustration car j'ai été réticent également au départ à utiliser "du code tout fait" : j'avais le même sentiment que toi à passer à coté de quelque chose. Et je t'encourage à essayer de faire un ou deux projets from scratch pour te permettre de savoir faire ce que proposent les composants des framework, et pour mieux comprendre le gain. C'est après avoir développé soi-même une ou deux libs qu'on comprend mieux : d'une comment ça fonctionne, et de deux à quel point c'est mieux d'utiliser une lib qui prend en compte tous les cas de figure tordus auxquels on avait pas nécessairement pensé.

    Si tu es un vieux de la vieille du code je n'ai qu'une chose à te dire et elle ne va pas te plaire : le métier de développeur (comme plein d'autres métiers dans tout domaine) évolue en même temps que les langages et les frameworks et c'est au dev de suivre s'il ne veut pas devenir "ringard et inutile".

  10. #10
    Membre averti
    Inscrit en
    novembre 2008
    Messages
    289
    Détails du profil
    Informations forums :
    Inscription : novembre 2008
    Messages : 289
    Points : 379
    Points
    379

    Par défaut

    Citation Envoyé par Nico_F Voir le message
    Si tu es un jeune développeur je comprends cette frustration car j'ai été réticent également au départ à utiliser "du code tout fait"
    Tout à fait d'accord. Pour moi, la question est un peu curieuse. Un framework est juste un outil d'aide au développement comme d'autres (EDI, gestionnaire de versions, intégration continue...). Pourquoi ne pas se poser la question pour ces outils aussi ?

    A l'extrême, utiliser un langage évolué, c'est déjà utiliser du "code tout fait". Avec cette optique, le seul langage acceptable, c'est assembleur, et encore (sinon, où est la limite ? C ? python ? Avec ou sans librairie tierce ?...).
    L'utilisation de librairies, d'objets tiers ou de frameworks n'est ni plus ni moins qu'une évolution de la dynamique qui consiste à éviter de mal développer ce que quelqu'un d'autre a bien fait.

    Et si le framework est trop gros, il est souvent possible de le faire maigrir. Symfony, puisqu'on en parle ici, permet tout à fait d'être recalibré au minimum de ce que l'on souhaite en n'intégrant que les éléments que l'on veut. Ca demande un peu de boulot mais c'est possible.

  11. #11
    Membre averti
    Inscrit en
    novembre 2008
    Messages
    289
    Détails du profil
    Informations forums :
    Inscription : novembre 2008
    Messages : 289
    Points : 379
    Points
    379

    Par défaut

    Citation Envoyé par zecreator Voir le message
    On a 30 Mo de fichiers à déployer, pour seulement 4 pages web qui pourraient tenir sur moins de 1Mo
    Si ton appli ne fait que 4 pages, c'est sûr que le framework ne sert pas à grand chose.
    Si par contre, s'il y en a plusieurs dizaines avec des tas de listes, de tableaux, de formulaires, ce n'est plus le même tonneau.
    Or, de très nombreuses applications de gestion (stocks, clients, fournisseurs, commandes) ne se contentent pas d'une base de 3 tables à gérer facilement. Celle que je développe actuellement dépasse la centaine et franchement, sans framework, ce serait pénible.

    Sans parler de la sécurité qui est un vrai casse tête quand tout doit être fait à la main. Certes, au début, c'est intéressant mais après, ça finit par devenir franchement laborieux.

    Citation Envoyé par zecreator Voir le message
    On laisse de coté son métier de développeur en ayant une confiance aveugle dans le framework, parce que c'est celui qui est utilisé partout, et que c'est obligé.
    Pas forcément. Des frameworks, il y en a plein. Il suffit de les comparer soi-même ou de lire des comparatifs faits par d'autres. Qui plus est, sans faire une confiance "aveugle", je pense que des types qui se consacrent depuis des années à un ORM ont de grandes changes d'être meilleurs que moi dans ce domaine, des types qui se consacrent à un moteur de template depuis des années ont de grandes changes d'être meilleurs que moi dans ce domaine, des types qui se consacrent à assembler différentes briques au sein d'un framework depuis des années ont de grandes changes d'être meilleurs que moi dans ce domaine. De mon côté, me consacrant depuis des années à traduire du métier en applications, je pense que ma valeur ajoutée se trouve plutôt là.
    Dans un développement, il y a normalement aussi beaucoup de code métier qui fait appel à des compétences de développement. Le "vrai" développeur n'est pas forcément celui qui a développé 250 fois un tri à bulles.
    Le développement, c'est comme la médecine, ça se fragmente en plein de spécialités difficiles (voire impossible) à maîtriser toutes.
    Peut-être que simplement tu n'es pas fait pour faire du développement d'applis de gestion web...
    Je doute que dans l'embarqué, ils utilisent des frameworks de plusieurs dizaines de Mo.

    Citation Envoyé par zecreator Voir le message
    Je me demande juste ce qu'il reste aujourd'hui du métier de développeur. Ceux que l'on tag de développeur "à la papa" et qui refusent le conformisme des frameworks pour privilégier leur épanouissement technique, sans vouloir être élitistes. Ceux qui souhaitent pratiquer leur métier avec le vrai plaisir de le faire. Sont-ils vraiment devenus ringards et inutiles ? Le contexte du métier tourne t-il définitivement autour de la productivité et de la rentabilité ?
    Je ne comprends pas cette remarque. Un framework n'empêche pas de développer. Il n'enlève pas la technique, ni le "vrai plaisir" de développer. Il déplace les bornes, c'est tout. Le métier de développeur évolue, les outils aussi (le framework en fait partie, au même titre que l'IDE, le gestionnaire de version ou les outils de tests unitaires), comme celui de dentiste dont la pratique n'a plus grand chose à voir avec celle de nos grands parents. En informatique, le changement est seulement 10 ou 20 fois plus rapide.
    Et le framework ne fait pas tout, autour d'une application, il peut rester pas mal de développement à réaliser dans un simple éditeur de texte avec quelques centaines de lignes et quelques objets. Par exemple un petit générateur de code pour générer des classes bâties sur un même modèle en fonction de données récupérées dans le dictionnaire d'une base, ou une macro dans tel ou tel logiciel pour importer ou exporter des méta données (je pense à MySQL Workbench qui se programme facilement en python).

Discussions similaires

  1. Les Freelances sont ils recherchées ou pas ?
    Par VinceF dans le forum Freelance
    Réponses: 30
    Dernier message: 05/01/2009, 12h46
  2. Réponses: 2
    Dernier message: 06/05/2007, 22h37
  3. Réponses: 1
    Dernier message: 04/04/2007, 13h43
  4. Les événement sont-ils synchrones ?
    Par fregolo52 dans le forum Framework .NET
    Réponses: 1
    Dernier message: 27/09/2006, 16h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo