Bonjour,
je viens demandez vos avis Svp.
Le métier de Développeur de logiciel, a t-il un meilleur avenir que le métier de développeur web ?
Car il y a de + en + d'agence web avec aucune compétence en codage Back-End, qui font des Wordpress à la chaine… Et qui font donc concurrence à des vrais codeurs en cassant les prix…
Je me suis formé (et je me forme tout les jours) au métier de développeur web (avec PHP comme langage Back-End). Je devrai bientôt commencer mon 1er CDD. Et les week-end et soir après le taf, j'aimerai bien aussi apprendre un autre langage de programmation.
J'hésite apprendre un autre langage avec lequel on peut développeur des applications web, pour améliorer mes compétence en développement web (donc Ruby avec ROR par exemple).
Ou apprendre un langage avec lequel on peut développer des logiciel (C# par exemple).
Car il y a de + en + d'agence web avec aucune compétence en codage Back-End, qui font des Wordpress à la chaine… Et qui font donc concurrence à des vrais codeurs en cassant les prix…
Sauf que ces agences là ne sont pas là pour prendre le boulot des "vrais développeurs" comme tu dis. Du boulot en web, tu en trouveras autant quand applicatif. Et comme à peu près tous les langages modernes te permettent de faire du web et de l'applicatif et du mobile tu ne devrais pas être dérouté.
Bref, fais avant tout ce qu'il te plait. Ne te soucis pas des ouï dire. Ils sont tous faux.
Car il y a de + en + d'agence web avec aucune compétence en codage Back-End, qui font des Wordpress à la chaine… Et qui font donc concurrence à des vrais codeurs en cassant les prix…
J'aime pas du tout cette idée de "vrais codeurs", encore moins celle que les gens qui font du wordpress à la chaine ne sont pas de "vrais codeurs". Les agences qui font du wordpress ne se contentent pas de dézipper des plugins et des thèmes.
J'hésite apprendre un autre langage avec lequel on peut développeur des applications web, pour améliorer mes compétence en développement web (donc Ruby avec ROR par exemple).
Si tu apprends Ruby, tu peux faire des applications Desktop avec.
Ou apprendre un langage avec lequel on peut développer des logiciel (C# par exemple).
Si tu apprends C#, tu peux faire du web avec.
Si j'étais toi et que je voulais augmenter mes compétences de programmation, j'apprendrais un langage un peu ou beaucoup fonctionnel. Ca t'apprendra à penser différemment et ça fera de toi un meilleur programmeur.
Si j'étais toi et que je voulais augmenter mes compétences de programmation web, j'apprendrais JavaScript. JS est omniprésent sur le web, comme front-end et comme back-end. Tu as probablement des bases de JS, mais tu es certainement loin de maitriser JS.
Le truc dont on se rend compte après quelques années de pratique c'est qu'apprendre à maîtriser parfaitement un langage c'est très long. Par contre, lire et comprendre les concepts associés à un langage ça va plus vite et ça sert extrêmement souvent.
Si l'objectif est de devenir expert sur une techno, fonce vers le JS comme le dit victor, le langage a de l'avenir, il est maintenant utilisé côté client ET serveur, il évolue (enfin) et dans un sens plutôt intéressant et gracieux.
Si l'objectif est d'enrichir ta culture "web" sans forcément devenir un expert sur le sujet, va chercher une pile technologique (facilement abordable, donc pas Java EE par exemple) diamétralement opposée à ce que tu sais faire. Tu codes du PHP procédural ? Va fouiller du côté de Rails ou Django. Tu bouffes à longueur de temps du PHP+framework MVC ? Pas la peine d'aller voir Rails tu vas retrouver beaucoup de concepts communs, va voir du côté de nodejs, akka ou sinatra.
T'as besoin d'enrichir ta culture "client desktop" pour en connaître les enjeux (différents de ceux du web) ? Peut-être le couple C++/Qt va certainement t'en apprendre beaucoup.
Sois tu cherches à te spécialiser, sois tu cherches à te cultiver. A mon avis quand on débute vaut mieux essayer de se cultiver (créer un petit exemple de site web sans intérêt : Doodle/Framadate par exemple) et si tu es très emballé par la techno alors fonce et spécialise-toi.
En PHP je code en POO (j'aime pas le procédural).
J'ai (en je suis encore en train) de développer un Framework MVC avec du code maison, je fait aussi du Laravel 5 (Framework MVC open source).
ce sont des connaissances très précieuses que tu pourra réutiliser partout.
Non.
[EDIT] En fait mon message était un peu succinct. Il serait peut-être plus productif que je pose les questions suivantes :
Qu'est-ce qu'une bonne conception OO ?
En quoi cela constitue des connaissances "très précieuses" ?
En quoi est-ce réutilisable "partout" ?
Il connait déjà la base de l'OO. Il lui serait plus bénéfique de découvrir n'importe quoi de pas OO, par exemple un langage fonctionnel qui ne supporte pas l'OO. Est-ce qu'on peut s'accorder là-dessus (à défaut de s'accorder sur le fait que l'OO est une abomination) ?
Je saisis mal la différence entre un développeur web et un développeur "logiciel". Logiciel c'est devenu trop vaste.
Car il y a de + en + d'agence web avec aucune compétence en codage Back-End, qui font des Wordpress à la chaine… Et qui font donc concurrence à des vrais codeurs en cassant les prix…
Disons qu'elles réutilisent ce qui se fait déjà de mieux. C'est une pratique intelligente même si, on est d'accord, réduit le métier de développeur à "assembler des briques déjà faites".
Tu veux évoluer vers un autre domaine d'application que le développement web, c'est ça ?
Car pour moi un développeur d'applications web… Il est "dans le logiciel". Il développe une certaine logique ; même le développeur Front-End qui va chercher à agencer correctement son interface pour qu'elle soit jolie, intuitive, suive une certaine logique etc. Ça n'est que mon humble avis.
Vise le métier d'une boîte et ensuite vois si cette boîte utilise des outils et des langages en accord avec tes compétences. Ce sera je pense le meilleur moyen de t'épanouir.
Ensuite si tu veux ratisser large sur les offres, apprends un langage populaire (au hasard… Java ? Python ? C(++/#) ?) et ne démord pas de cet apprentissage.
(1) Une conception qui sémantiquement tient la route, ça passe notamment par le respect du LSP.
(2) Parce qu'utiliser correctement un outil disponible dans beaucoup de langages c'est précieux.
(3) Partout où l'on a de l'OO serait plus juste.
(4) Ou croit connaître. L'OO est globalement assez mal compris. En particulier les principes SOLID et la loi de Demeter sont globalement méconnus.
LOL.
Je ne dénigre pas le fait qu'il est très important de connaître le fonctionnel. Cela dit cette manie de ces adeptes de croire ce paradigme supérieur à tous les autres est fatiguant à la longue.
Je l'admets, ma phrase était un peu la phrase bateau sans justification. Je vais donc préciser mon point de vue ; je ne prétends pas avoir la vérité absolue et je ne parlerai pas de l'horreur ou non de l'OO, je n'ai pas le recul ni l'envie.
Pour moi, une bonne conception OO, c'est déjà le respect des principes SOLID et de la loi de Demeter. Je ne dis pas de les suivre aveuglément à la lettre de façon absolue, mais plutôt de les appliquer et ne pas le faire quand c'est adapté.
Et si c'est bien conçu, dans l'idée, ça ne doit pas être une plaie d'étendre le comportement de l'application. Alors oui, ça n'est pas lié spécifiquement à l'OO, mais tant qu'à en faire, autant que le PO apprenne à en faire proprement.
Des développeurs capables de concevoir un système propre et assez stable, tout en étant extensible, ça ne court pas les rues. Et pardonnez-moi du troll, mais encore moins en PHP. Des exemples de réalisations bien conçues et postées sur GH peuvent ainsi être une plus-value.
Partout, c'est peut-être un peu fort. Mais l'avantage de savoir concevoir correctement dans un langage OO, c'est de pouvoir se détacher du langage et appliquer les principes dans n'importe quel langage. Et suffit de regarder la plupart des offres d'emplois (même si ce n'est pas forcément le meilleur critère d'évaluation), y'a plein d'offres en PHP, en Java, en C#, autant de langages où on utilise beaucoup (voire pour certains exclusivement) l'OO.
On est bien d'accord, un crochet par un langage fonctionnel est quelque chose d'important (je suis moi-même sur Haskell).
Le web m'attire beaucoup, mais j'aimerai bien apprendre un autre langage de programmation (par passion, et aussi pour élargir mes compétences).
Mes compétences actuelles : HTML5, CSS3, un peu de JS, PHP5, SQL.
Mais j'ai débuté le codage Front en Octobre 2014, et le Back en février 2015. Donc j'ai encore beaucoup à apprendre.
(4) Ou croit connaître. L'OO est globalement assez mal compris. En particulier les principes SOLID et la loi de Demeter sont globalement méconnus.
Bof. Je maintiens qu'on peut connaitre la base de l'OO sans connaitre SOLID et la loi de Demeter.
Est-ce qu'on peut s'accorder là-dessus (à défaut de s'accorder sur le fait que l'OO est une abomination) ?
LOL.
Je ne dénigre pas le fait qu'il est très important de connaître le fonctionnel.
Cool.
Cela dit cette manie de ces adeptes de croire ce paradigme supérieur à tous les autres est fatiguant à la longue.
C'est drôle, parce que je ne suis pas particulièrement adepte de programmation fonctionnelle. J'aime bien, j'en utilise quand je peux, mais c'est tout. "J'en parsème mon JavaScript." Je ne fais pas une guerre de chapelle là. Je donne juste mon avis sur l'OO. J'ai le droit de dire que c'est un mauvais paradigme sans qu'on me classe comme fanatique d'un paradigme XYZ ? Ou de dire que l'OO est un mauvais paradigme sans qu'on me reproche de placer le paradigme XYZ au-dessus ?
Le truc fatiguant à la longue c'est les hommes de paille et les gens qui prennent mal qu'on n'aime pas les outils qu'ils utilisent.
Ben justement , l'idée est qu'ici on est plus dans le goût donc parler d'abomination est plutôt excessif.
Relativement bien, cela dit je ne l'utilise plus beaucoup en ce moment, juste à titre de pseudo-enseignement.
Un outil est un outil, il est fait pour un job et quand il est adapté, on l'utilise et le goût n'a pas franchement à voir là dedans. Il faut, objectivement, bien savoir utiliser les outils qu'on a disposition.
(1) Une conception qui sémantiquement tient la route, ça passe notamment par le respect du LSP.
Une conception OO basée sur le sous-typage. Mais d'une part, on sait aussi concevoir des programmes différemment, que ce soit sans objets ou même sans avoir besoin de sous-typage, et d'autre part, c'est bien beau d'avoir des principes à respecter, mais si c'est pour faire passer discrètement à côté comme tu le fais dans ton message suivant des âneries du style « le sous-typage, c'est l'héritage », c'est pas la peine.
(2) Parce qu'utiliser correctement un outil disponible dans beaucoup de langages c'est précieux.
(3) Partout où l'on a de l'OO serait plus juste.
Je crois que c'est en partie ce que victor voulait dire. Cette manie des adeptes de la POO de croire que ce paradigme est omniprésent est fatiguante à la longue.
(4) Ou croit connaître. L'OO est globalement assez mal compris. En particulier les principes SOLID et la loi de Demeter sont globalement méconnus.
La plupart des gens qui vantent les sacro-saints principes de l'orienté objet n'ont de toute façon pas la moindre idée de ce que sont la covariance et la contravariance. Qu'est-ce qu'on peut en conclure, selon toi ?
Je ne dénigre pas le fait qu'il est très important de connaître le fonctionnel. Cela dit cette manie de ces adeptes de croire ce paradigme supérieur à tous les autres est fatiguant à la longue.
Il ne s'agit pas de ça. Il s'agit de savoir si, oui ou non, l'orienté objet est une méthodologie intéressante pour programmer, que ce soit pour structurer un programme ou pour l'implémenter. Et il se trouve que, dans la plupart des cas, elle conduit à faire des choses très nettement plus complexes qu'avec un style fonctionnel fortement typé, pour un apport nul.
Ben justement , l'idée est qu'ici on est plus dans le goût donc parler d'abomination est plutôt excessif.
C'est excessif. J'aurais dû m'en tenir à dire que l'OO est une mauvaise idée. Surtout l'OO à base de classes. (Je précise ça parce que je connais pas de langage OO class-less qui souffre des mêmes problèmes Java/Cpp et cie.)
Un outil est un outil, il est fait pour un job et quand il est adapté, on l'utilise et le goût n'a pas franchement à voir là dedans. Il faut, objectivement, bien savoir utiliser les outils qu'on a disposition.
Mon point c'est justement que l'OO c'est (presque) jamais adapté. (T'as vu, j'ai modéré mon propos. ) L'OO encourage l'over-engineering.
Enfin, je sais pas comment on peut justifier des trucs comme l'héritage par exemple. Alors que l'OO décourage l'héritage. Alors qu'il y a le Circle-ellipse problem.
(1) J'aurai plus vu dans le sens "pour éviter de se tirer une balle dans le pied avec l'héritage, mieux vaut que ce soit un sous-typage" mais si tu as des pointeurs vers d'autres règles, fait péter. Comme je l'ai dit je connais relativement bien l'OO, j'ai jamais dit être un cador.
(2) Est ce que j'ai dit qu'on ne pouvait pas concevoir autrement qu'en manipulant du sous typage (note, je t'entend : hors de l'OO, à ma connaissance dans l'OO ça sent le désastre à plein nez).
Donc "beaucoup" = "omniprésent". Amusant. Ou alors, c'est qu'il n'y a pas "beaucoup" de langages implémentant l'OO.
Que l'enseignement ne fait pas son boulot ?
Pour bosser sur une grosse plateforme fonctionnelle actuellement, on est loin d'être dans le monde des bisounours où tout est beau et pratique.
Pour bosser sur une grosse plateforme fonctionnelle actuellement, on est loin d'être dans le monde des bisounours où tout est beau et pratique.
Maintenant prends cette plateforme, pour chaque type ajoute 5 classes/interfaces parentes, ajoute des designs patterns partout, multiplie par 7.2 le nombre de fichiers du repo et par 4.3 le nombre de lignes de code. Bienvenue dans l'OO façon Java.
C'est pas très bisounours, mais c'est probablement moins pire.
(1) J'aurai plus vu dans le sens "pour éviter de se tirer une balle dans le pied avec l'héritage, mieux vaut que ce soit un sous-typage" mais si tu as des pointeurs vers d'autres règles, fait péter. Comme je l'ai dit je connais relativement bien l'OO, j'ai jamais dit être un cador.
La bonne question à se poser, ce n'est pas « est-ce qu'il vaut mieux que l'héritage soit un sous-typage ? », mais plutôt « est-ce qu'on doit confondre les deux notions », comme c'est fait dans à peu près tous les langages OO mainstream. Et la réponse est non : l'héritage, c'est la réutilisation de code. On n'en a pas besoin pour faire du polymorphisme, ni pour faire du sous-typage.
Ceci étant dit, selon ton système de types, une relation d'héritage entre deux classes implique a priori d'une façon ou d'une autre un sous-typage entre deux types plus ou moins liés à ces classes. Mais confondre systématiquement les deux est une erreur (très répandue).
Pour bosser sur une grosse plateforme fonctionnelle actuellement, on est loin d'être dans le monde des bisounours où tout est beau et pratique.
Et alors ? Je ne sais pas comment il faut comprendre ce que tu dis : est-ce que ça veut dire que c'est les pratiques industrielles qui doivent faire référence quand on parle de langages de programmation, ou est-ce que ça veut dire que puisque les industriels programment n'importe comment, il n'est pas possible de coder proprement ?
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte