Reprise du message précédent :
 
 
Disons que la complexité métier / algo est plus souvent côté back que front. Surtout sur de l'entreprisey où l'UX/UI est du niveau Harkonnen
 
Par contre, je suis pas vraiment d'accord avec son premier point : avec des missions, on peut faire ça.

Front web, ouai : Angular / ReactJS / PHP (WP)

Mais j'ai de bonnes connaissances SQL. Je comprends pas pourquoi Java serait une tuerie à apprendre, surtout pour faire des RestAPI sous SpringBoot ( 80% des missions )

À moins que je rate quelque chose

 
J'attends encore de croiser un exemple de code dans la vraie vie (et j'ai vu défiler un paquet de trucs merdiques) où réutiliser une variable locale ou réassigner un paramètre de méthode a provoqué un bug.
A plus forte raison quand on trouve cette "finalite" aiguë dans des bases de code où les méthodes sont concises.

Pour moi il raconte de la merde. Ça doit forcement dépendre de ta stack. Perso j'étais back, je suis passé full front pendant 2/3 ans. Et actuellement je fais les deux dans ma boite, ainsi que pour mes projets externes. Je vois clairement pas le soucis.
Après ma stack est plus simple que les javaiste par exemple, et sur des projets plus petit, encore que... J'ai fais PHP/Symfony, maintenant Node/React.

Tout dépend du contexte, et de ton entreprise, dans les petites structures (comme celle par lequel je suis passé) on fait les 2 de fronts, et aucun des employées ne sort d'un école d'ingénieur...
 
Oui et non, j'ai beaucoup progresse avec des projets persos mais pacque je n'étais pas seul à faire le cahier des charges et donc je sortais régulièrement de ma zone de confort (requête SQL de l'espace par exemple ^^)...
Ça doit être possible tout seul mais faut une sacré discipline et des exigences assez haute ! ^^
 
Comme dit plus haute le front ça peut aussi être chaud (ergonomie, responsivité, optimisation, etc. d'autant que les efforts ne se voient pas forcément au niveau client / marketing), par contre au niveau du backoffice il y'a le problème de la sécurité, et là l'impact est énorme donc ça met quand même pas mal de pression...

 
C'est surtout un gros con visiblement
Tu peux absolument passer de l'un à l'autre.  
Front-end plus simple je ne pense pas. C'est pas les mêmes problématiques. Ne serait-ce que gérer la jungle des browsers/devices c'est complexe.  
Gérer l'ui/ux, le 60fps...

 
Je me rappelle plus, t'as du passage par const ref en java ou pas ?

 
bah..  
 
Quand tu commences à parler performance, volumétrie, persistance de grappes un peu complexes, etc.. fatalement, tu as des problèmes que tu n'a que très peu de chances d'avoir rencontré en front.

Regardez les chiffres traditionnels de la webperf pour voir où le temps est passé. Vous verrez que l'enjeu majeur c'est le front (faut pas avoir une équipe backend qui fait n'importe quoi non plus).
Fullstack ftw.

Ma théorie c'est que le front a une courbe d'apprentissage bien plus douce, de par la flexibilité de l'environnement. Du coup c'est possible de produire quelque chose qui fait le job sans gros efforts/talent. Le corollaire c'est qu'il y a beaucoup de buses qui font du front-end, parce que c'est la seule chose qu'ils peuvent faire. Mais quand il s'agit d'écrire du code lisible, maintenable et performant, la flexibilité devient rapidement un défaut, et les bons développeurs front-end n'ont rien à envier à leur homologues back-end. Les bons développeurs front-end que je connais n'ont pas la moindre difficulté à faire du back-end.

 
Je suis un peu rouillé sur la terminologie, mais en gros la référence d'un argument de méthode est local à la méthode, la réassigner n'a aucun effet de bord.
Par contre tu peux très bien modifier un objet passé en paramètre et déclarer final ce paramètre n'a aucun impact.

 
+1 là dessus, tant qu'on est sur du "vrai web". Sur un SI de gros client ancien, les vrais problèmes de perfs sont souvent sur la DB, les batches d'alimentation via un fichier CSV craché par un vieux SI en cobol ou un truc comme ça.
 
 

mouais, je sais pas. Il y a beaucoup de buses en back aussi.
 

 
+1.  
 

 
le Final s'applique à la référence, jamais à la valeur, tu veux dire?
 
 

 
Je t'avais dit que j'étais rouillé en terminologie

 
Ok j'ai ma réponse  

Saurez-vous retrouver les 3 lignes HT présentes dans l'image ?

J'aurais tendance à être d'accord avec fred et serge.

T'as pas de passage par ref tout court (les types ref c'est du passage de référence par valeur).

Ça s'applique à la valeur même, mais pas au référé (pointee) si cette valeur est une référence

 
Je n’en suis qu’au début. Cela m'encourage à continuer, merci.

Ptin ça y est, j'ai enfin mon n° de TVA intra \o/

Ouais, tu rates Spring, sa magie, ses fichiers XML qui nécessitent un écran 80" en portrait pour les afficher en une fois, et toute sa clique... Quand un framework (Spring) a besoin d'un autre framework pour générer tout son boilerplate d'initialisation (Spring Boot), tu sais que tu vas en chier. Une pure émanation de satan.  

 
Ou alors t'es nul

Mes collègues ont l'air d'apprécier Spring Boot

j'ai sacrifié des soirées pendant lesquelles j'aurais pu sexer et me vautrer dans la luxure pour apprendre tout ce bouzin, je t'interdis de dire que je suis nul

Bonne ou mauvaise idée le convertisseur interne IDE vers SATA
 
J'ai pas trop pensé au fait que mes parents avaient encore un DD en IDE quand je leur ai monté leur nouvelle config et ils aimeraient bien récupérer leurs données
 

Prend une mouise IDE to USB sinon

 
 
c'est vrai sur du web heavy.
 
Quand tu dois gérer une nuit batch qui prend 400 camions, et les éclate récursivement en un moteur un chassis une cabine, et récursivement chacun de ces éléments jusqu'à la pièce achetée / fabriquée la plus élémentaire, avec 80 systèmes qui se parlent à la chaine, le tout lancé depuis un terminal mainframe où tu as du faire F, G, espace plein de fois pour effacer une valeur, F2, taper dans tes mains et faire un tour sur ton siège, ton skill front compte peu.
Et le gros de ta complexité c'est de l'intégration de données, de l'ETL, des algos / requetes efficaces si tu gères de la masse de données, c'est super velu.
 
Mais quand tu vois la gueule d'un stack web de nos jours, et la gueule de l'outillage et du pipeline de prod, aller expliquer à un dev front que son job est simple c'est....intéressant
 
je pense que c'est une fausse dichotomie front/back, ce qui va le plus favoriser ton embauche sur un poste X c'est le fait de prouver "que tu l'as fait avant", et c'est casser ce cercle qui est difficile

bah évidemment, ça les dispense de dizaines d'heures de larmes et de tentatives de suicide pour initialiser un projet Spring et ses dépendances  

Tu veux dire qu'en plus d'être mal payé t'as loupé ta vie sexuelle à 20 ans ?  

Et encore, t'as pas vu Hadoop

 
vois le bon coté : ça a du t'éviter 2-3 pensions alimentaires. Si ça se trouve tu t'es enrichi, en somme, grâce à ça

 
Du coup de quoi te plains-tu ?

s'ta dire que si vous bossez chez plamcorp, le front c'est super compliqué, mais c'est absolument pas une complexité intrinsèque.
 
J'ai été explorer des algo de nesting en JS qui étaient plus faciles à comprendre.

 
Wat

une merde, une daube, un truc pas cher

Essaie de sortir du chemin balisé par Spring, et tu comprendras mes propos, jeune veau

vu comme ça

et c'est probablement un dev back qui t'as dis ça après avoir fait un peu de hello world

Le front aujourd'hui est , a mon avis plus complexe que le back, ne serait ce que parce que beaucoup de services back existent en managés  : utilise dynamodb, firestore, ou un truc équivalent, ajoute quelques lambdas et tu peux faire une application web world class sans gérer un seul serveur , pour un coût ridiculeet en restant dans des technos que tu connais en front

achete un adaptateur USB et balance ce disque collector, il sera lent et risque de mourir bientot
 
pour les clés, demande a rakuyten pou rune clé windows 10, ça coute moins de 10 brouzouf

ben je trouve qu'il y a autant de buses qui font du back, quand je vois la gueule du code et des algos

Bah là tu fais du back avec des technos habituellement vues en front, mais c'est du back.
Ou alors il faut commencer par défi or front et back.

Pour moi le front c'est essentiellement l'ihm (au sens large). Et le back ca va plus être là persistance, la cohérence de la donnée, etc..

Et osef de ou c'est exécuté au final (et de la techno)