c'est une façon d'interpréter les choses donc de manière subjective.Envoyé par mermich
Qui a écrit s'estimer être un bon développeur ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
c'est une façon d'interpréter les choses donc de manière subjective.
Qui a écrit s'estimer être un bon développeur ?
Passer aux archis micro services c'est le moyen le plus efficace pour :
- ne plus avoir besoin d'experts pour coder (se limiter a coder des choses ultra simples etant a la portee de quiconque a l'aide de simples modeles)
- codage simplifier pour la grosse partie (les parties plus complexes type orchestration de services sont a la charge d'experts techniques/fonctionnels - on classifie les devs et on valorise enfin les experts - souvent oubliés dans les structures d'entreprise).
- ne plus avoir de problemes pour trouver des 'bras' (bac + 2 etc sont largement suffisants)
- tres simple a externaliser en off shore (sans risque)
- adapté au devops
- les devs font se qu'ils preferent, du code technique en jouant avec les technos/outils du moment
- reduire les couts et les delais (generation de code auto inclus les tests / deploiement est postulat de base dans ces archis)
- permet de donner de l'emploi a des gens debutants
- reduit le besoin de remunerer des experts a des tarifs prohibitifs (et se rendre dependant d'eux)
- Meilleure tracabilité et visibilité dans l'etape de dev (fini l'effet tunnel)
J'ai l'impression d'entendre un manager ... Pas etonnant que les jeunes talents `fuient` la France avec ce genre de discours!
Non je suis architecte dans cette nouvelle organisation - et je fais du dev sur les parties framework et orchestration de services; maintenant oui ca peut surprendre ce que j'ecris mais c'est juste le simple constat de la realité de beaucoup d'entreprises; la realité c'est que de plus en plus de projets passent dans ces archis et elles sont redoutables (mais n'ont pas que du - ce qui semble - negatif).
Certains nouveaux devs sont tres contents car ils arrivent a intégrer des equipes et a se former sur le tas en se basant sur bonnes pratiques.
Meme s'ils commencent tres simplement au debut. Les plus brillants (les jeunes talents comme tu dis) generalement se font remarquer rapidement et sont exfiltrés pour travailler sur des taches plus nobles.
Tout le monde en dev ne veut pas forcement se prendre la tete. Pour certains c'est un boulot comme les autres ou ils deroulent.
Ca fait gagner enormement de temps pour tout le monde. Fini le developpeur qui se forme ou qui grenouille dans son coin en reinventant la roue carree.
Tout le monde y trouve sa place et y trouve son compte au final.
Essayer c'est l'adopter.
On est en train d'essayer de faire ça chez moi mais j'ai du mal à croire qu'un dev lambda surtout formé en bootcamp puisse implémenter efficacement les règles métiers et surtout maintenir le truc surtout sur des vieilles applis qui nécessitent pas mal de connaissance transverse (BDD, système, etc.)
Je ne suis pas sure que ce genre d'architecture soit très performante. Et quelle en est le cout pour le client, au final? parce si il faut des fermes de serveurs pour que ça tourne a peu prêt
.
Et un développeur, c'est pas un mollusque qui pisse du code à l'heure. A un moment, il faut comprendre ce qu'on fait, pourquoi on le fait, et si c'est pertinent de le faire.
Parce que dans ton descriptif, je ne vois pas ou se situe l'analyse fonctionnelle
Pourtant, c'est la mode le micro service et à peu près pour les raisons cités.
Le principe du micro service, c'est un peu comme le principe d'origine des commandes UNIX: chaque commande ne fait qu'une chose mais elle le fait bien.
non pas forcement de ferme de serveurs mais je parle d'appli d'entreprise (quelques serveurs redondés en l'occurence suffit), pas d'une simple appli desktop qui tourne sur un PC.Je ne suis pas sure que ce genre d'architecture soit très performante. Et quelle en est le cout pour le client, au final
Et un développeur, c'est pas un mollusque qui pisse du code à l'heure. A un moment, il faut comprendre ce qu'on fait, pourquoi on le fait, et si c'est pertinent de le faire.
Parce que dans ton descriptif, je ne vois pas ou se situe l'analyse fonctionnelle
Ben si justement avec les micro services, le boulot de dev se cantonne a coder des choses tres simples.
Tres facile a externaliser en offshore pour cette raison egalement. Le dev en inde ne voit qu'une partie sans savoir exactement a quoi elle sert.
Je crois que ca les arrange aussi car souvent les devs se focalisent sur la technique et les outils et le fonctionnel ne les passionne pas plus que ca (ils s'en foutent puisque rien ne garantit qu'ils changeront pas de projets a la fin de son petit dev. On a un bureau d'etude d'un millier d'indiens (tres bons techniquement) donc on peut pas lutter financierement (avec des salaires /4 a /8 minimum selon le profil par rapport a nos salaires en france). Quand bien meme ils mettent plus de temps a comprendre le peu de fonctionnel, avec un tel ratio (4 ou 8), ils continuent a etre peu cher et en quantité.
Oui je suis persuadé que le metier de developpeur sera tot ou tard ubérisé; les archis micro services s'y pretent idealement.
Il n'a pas besoin de connaitre le fonctionnel de l'ensemble mais juste de coder les briques autonomes qu'on lui demande de coder.
Visiblement tu n'as jamais pratiqué; tu es encore visiblement dans une vision d'il y a quelques années du developpeur tout puissant dont on attend tout.
Ce n'est plus indispensable dans le monde d'aujourd'hui. Le code sans plus value peut etre delégué a de simples dev; le code avec plus de valeur ajouté est valorisé a sa juste valeur; ceux qui sortent du lot en tirent partie.
L'analyse fonctionnelle et expressions des besoins est initiée puis evolue au fur et a mesure du projet (mode agile) - rien de nouveau la dedans.
Comme la complexité se deplace plutot sur la partie orchestration et n'impacte que tres peu les devs de base; pour ces travaux d'orchestration on ne met pas de simples developpeurs.
Aucun interet a ce que tout le monde soit expert en tout; qu'ils fassent 1ou 2 choses mais sans fautes.
Ca a toujours été l'argument depuis le début des années 2000, mais nombre de projets en Inde se sont cassé la gueule.
La plupart du temps, quand je suis en contact avec des indiens, ils sont un enième maillon d'une chaine pour des fiches anomalies.
Par exemple ils dispatchent les anomalies, et parfois sans grande intelligence, exemple en France je suis fournisseur de données à une appli nommée ABS basée dans notre structure en Suisse, qui digère les données, et les restitue en reporting à mes utilisateurs dans le bureau d'à côté. Quand ils ont une anomalie, ils ouvrent un ticket, et le ticket choit chez moi, jusque là c'est normal. Parfois, c'est moi qui ouvre un ticket, et comme ils voient "France" et "ABC", ils m'assignent le ticket. Je précise bien que je suis l'emetteur, et que si je pose une question à un business analyst c'est que j'ai besoin d'une réponse, mais le ticket revient invariablement chez moi ^^
Parfois, la logique binaire ne semble pas correspondre. Pour la même appli, un des fichiers contenant un type de produit XYZ n'est pas généré car la banque a décidé de ne plus utiliser ce type de produit. On attend donc un fichier qui bloque la chaîne. Je renvoie donc un fichier uniquement avec l'en-tête. Là on me dit que ça bugue parce que ça n'a pas de ligne. Je renvoie donc le mail validé du DG qui confirme qu'on en fait plus de produit. Mais rien à faire, ping pong de ticket me disant de renvoyer un fichier avec au moins une ligne de données
Quelques années auparavant, quand j'ai eu à bosser avec des Indiens en off-shore, ça a donné des trucs pharaoniques comme :
- le chef de projet indien se barre du jour au lendemain, pas de passation de connaissances
- les Indiens disent toujours oui, sont à 99% d'avancement, et la veille de la première mise en recette, les développeurs ne fournissent pas une seule ligne de code, "promis, le mois prochain"
- On leur envoie une maquette d'un écran HTML en entourant de rouge sous paint une list box pour attirer l'attention du point de règles et ils... développent en HTML en dur l'ovale rouge autour de la list box désespérement vide.
Aujourd'hui, en tout cas parmi les plus grosses sociétés, on vire de plus en plus les Business Analyst, ce sont les développeurs (prestas et internes) qui sont en contact direct avec les utilisateurs, les chefs de projet (internes) n'étant là que pour jouer de la balalaïka et récolter les lauriers sans qu'ils aient rien compris (c'était le cas sur mes deux précédentes missions, là sur cette mission mon CP connait parfaitement les enjeux et m'explique même du business mais il n'empêche que je suis en contact direct avec les utilisateurs).
Donc les Indiens à des milliers de kilomètres et plus quelques fuseaux horaires, qui reçoivent des specs par téléphone, j'y crois plus trop, là.
(par contre les Espagnols, les Portugais...)
- So.... what exactly is preventing us from doing this?
- Geometry.
- Just ignore it !!
****
"The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
***
Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019
Ha oui ? Ce n'est plus tendance le business analyst ?
De mon expérience c'est toujours un épic fail de mettre en relation un dev' et un end user. Je comprends bien que ça coûte de rajouter une couche mais c'est quand même efficace.
Sinon les indiens de la SoGé étaient bons quand je les fréquentais. (Ils étaient internes et leurs business anlyst presta)
On est en accord pour ce genre de cas, mais ici, ce n'est pas du "micro service"...
ça me rappele bien des ssii...
il y a pourtant bon nombre de cas que ça fonctionne assez bien de nombreux cas sont documenter dans THE HANDBOOK OF GLOBAL OUTSOURCING AND OFFSHORING, des systèmes à plusieurs dizaines de millions de $$$ jusqu'à des centaines... comme dans tout faut bien sélectionner son entreprise... et ne pas avoir peur de faire affaire avec un intermédiaire à se niveau... quitte à économiser moins d'argent dans un premier temps
ensuite faut penser à avoir des spécifications béton et non floue ce que j'ai rarement vu.... autant en france qu'au québec
les projets les plus réussis auquel j'ai pu travailler étaient ceux auquel les spécifications étaient très très détaillés, limite jusqu'à la classe... tu pouvais attribuer cela à n'importe quel développeur sans problème... l'effort est alors mis majoritairement du côté de l'analyse/conception au lieu du développement.
C'est la recette pour se retrouver avec un fatras de frameworks empilés les uns sur les autres, des performances dignes d'un 8086 sur un Xeon 8 cores... et des années de maintenance assurées derrière... J'ai déjà vu ce genre de résultat dans des entreprises (et pas dans des petites)...
Si un mec me présente un truc comme ça, je le passe directement par la fenêtre du sixième étage... (j'ai droit à 7% de pertes)
quelques lignes avec spring boot... pas besoin d'expert pour ça... seulement quelqu'un qui maîtrise le technique et qui sait ce qu'il fait
Pour l'an 2000 (et l'euro), pleins de gars (et de filles aussi) ayant fait un temps soit peu de science se sont vu offrir des postes en informatiques.La démocratisation du codage et des formations en informatique va-t-elle ruiner le marché de l'emploi IT de demain ?
Depuis on les a perdu
Apprendre le développement aux enfants, pourquoi pas, mais ça n'en fera pas forcément des informaticiens. En tout cas, je ne suis pas devenu mathématicien ou physicien, moi !!!
C'est peut être ce qu'espère quelques grosses boites. Mais elles vont vites déchanter si il ne sort pas plus d'informaticiens que ça des écoles.
Et puis les clients sont de plus en plus exigent. On peut plus refourguer un gugusse qui trainait dans le couloir, ou jouer aux chaises musicales.
D'après les descriptions que j'ai eu de quelques fac/formation payantes dans le domaine informatique, par des anciens étudiants et stagiaires,
je peux affirmer que celui qui a un BTS ou un DUT ou un diplôme d'une école d'ingénieurs "à l'ancienne", aura toujours l'avantage.
Même on ne lui enseigne pas la dernière techno à la mode, il aura au moins les bases théoriques et techniques pour apprendre et évoluer tout le long de sa carrière.
En entretien technique on repère assez vite, pour la grande majorité des profils, ceux qui ont une vrai formation en informatique de ceux qui ont juste eu quelques semaines de cours... Il y a beaucoup de théories à maitriser pour être efficace. Aujourd'hui on trouve beaucoup de développeurs qui ne s'intéressent pas réellement au développement: c'est un boulot alimentaire où la paye est un peu mieux qu'ailleurs...
Penser qu'avec 3 mois de cours on fabrique un développeur est illusoire: la majorité d'entre eux pourront faire des devs de bases (GUI, ou changer un format de date) mais ne pourront pas intervenir sur de l'algo complexe. Après le bug de l'an 2000 et le passage à l'euro beacoup de dev issus des bootcamps ont finit au chômage...
Dusse-ma modestie en souffrir, ceux qui restent sont très bons. C'est une sélection sur le tas, sur le tard, mais qui fonctionne.
Y a pas que la modestie qui souffre, l'orthographe prend une bonne baffe aussi
Il y a quand même une supposition intéressante sur la compétence, que "le motivé est sur DVP"… Ailleurs, certains estiment que les "compétents" sont sur Stack ou autre communautés anglophones, mais pas les francophones…
Je ne suis pas en train de faire un jugement de valeur (hep, j'y suis bien…*) mais c'est plus compliqué que ça.
De plus, "motivé" et "meilleur" sont à mon sens sans relation. J'en ai connu des gens très "motivés" mais très incompétents…
D'un autre coté, c'est la majorité de la force de travail nécessaire aux boites de service. La majorité des jobs est dans l'info de gestion ne nécessite pas beaucoup plus que d'extraire des données d'une base, appliquer 3 règles de gestion et mettre tout ça en forme. À notre époque, le matériel est peu cher, donc on n'a pas trop besoin de cadors.
En fait il fallait comprendre la remarque comme "les bons cherchent à être meilleurs".
On voit bien dans le public des MooC : ceux qui les suivent sont déjà bons, instruits, et cherchent à l'être encore plus. Qu'on cherche à être meilleur sur developpez.net, SO, ou autre, peu importe au fond.
Les mecs qui n'ont jamais lu un tuto par curiosité, jamais lu un article de veille, jamais été au courant de l'actualité, ils peuvent faire un job correct voire bon (si c'est très cadré), ils risquent quand même la péremption à moyen terme.
Répondre avec citation
Partager