Reprise du message précédent :

Non mais sérieux ils sont 2.
Parmi les collègues d'Harko ca doit probablement être un des meilleurs vu qu'ils ne sont pas en train de s'échanger des clés USB ou des zip par mail

Si tu fais le front, tu t'assoures d'avoir l'API qui est mockée et donc tu n'as pas à attendre le dev back.
Et comme l'as dit harko, le mec à d'autres trucs à faire entre temps.
 
En ce moments tous mes projets sont systématiquement mockés, soit c'est du MSW, soit du cypress avec tests E2E qui en découle. je ne peux plus coder sans une API mockée, car coder et attendre à chaque fois le chargement de l'api, avoir le bon jdd qui va bien..., alors qu'avec une API mockée c'est du oneshot les retours sont fait en 1ms et avec du E2E les features avec des parcours et des formulaires à remplir sont vraiment plus facile à appréhander.

Ah mais j'ai pas arrêté de lui expliquer ! L'autre jour, il m'a fait un commit de fou avec des requêtes SQL directement dans le code en utilisant des JdbcTemplate (alors que j'ai une belle archi Spring, avec mappers, repositories et tout, de quoi éviter d'utiliser des JdbcTemplate)... J'ai du reverter le commit !
 
Et pire encore : il a carrément créé une migration Flyway de la base de données pour rajouter des données pour ses tests, sans se douter un seul instant que ces migrations seront jouées en prod (et en ignorant superbement mes TU sous base H2 pour tester ce qu'il voulait justement tester). Bon pour cette partie, il a fait ça "bien" en faisant une PR... que j'ai rejetée !
 
Et du coup, il a été vexé et recommitte à nouveau dans la branche dev...
 

Déjà fait : une PR, un rejet de ma part. Depuis il a arrêté les PR
 

J'ai contacté l'admin du repo ce matin pour les lui enlever
 

Justement je voudrais éviter de gueuler... juste en dernier recours
 

skeye te confirmera que ça marche pas trop comme ça ici
 

Je l'attendais celle ci
 

Même pas... le endpoint était prêt depuis longtemps et fonctionnait très bien (validé par les TU)... Mais il l'a modifié je sais pas pourquoi, et il n'a même pas modifié les TU en conséquence...

 
Perdu ! Same player shoot again

 
Han le tocard, et si leur truc marche et qu'ils se retrouvent à devoir servir 100M requêtes par seconde, ils seront bien contents d'avoir conçu un truc qui passe à l'échelle !
 
Mais sérieusement, okay on peut commencer par discuter, mais je crois pas qu'il y ait de limite basse pour automatiser les tests et la mise en prod, c'est utile dés 1, il y a des solutions low tech.

 
Putain heureusement que non

 
Si seulement

Non mais j’ai une CI de résident.

Non mais sors de chez moi, genre pour aller m’acheter un seau de sirop de liège tout ça

Début?

   
 
codeowners + règles pour imposer une review par les codeowners si t’en es pas, comme ça il peut faire ses trucs dans le front dans son coin, mais il doit valider pour le back

Tester c’est douter

Message de lolCollegue sur le chat interne :
 

 
(soupir....)

this.

pipeline sur les MR/PR : si ton code est couvert (et le mapping java <-> json ça devrait être le cas), le pipeline pète.
Et branches dev/main protégées of course.

ouais comme ça le dev front débile fait écvoluer son mock sans considération pour ce qui est fait côté back, et quand on met tout ensemble ça marche bien

(en fait l'API mockée pour le front c'est bien, mais ça empêchera pas un crétin de se torcher avec le contrat d'interface)

Quelle horreur

Elle a quoi mon archi

Explicitez

 
L'arthrose.

Tu connais quand même son employeur, tu sais bien que dans ce milieu la même appli est développée et instanciée 70 fois, on fonctionne encore comme sous napoleon

T'as pas des servants on demand ?

Pardon c'est ma faute, masse forcément ça prête à confusion. Parlons de noyau    

Faut que tu changes un peu d'état d'esprit là, le problème doit probablement être réglable avec un ticket Jira  

 
Si tu fais du CRUD moisax comme sur 90% des projets, ça passe large.

 
ah ok ... genre l'equivalent d'une carte de séjour en FR.

J'ai pas ça dans mes fiches, c'est qui ?

l'université de bordeaux ou quelque chose du genre.

@Mapping(target = "evaluations", ignore = true)
...

 
Pour commencer, je promouvrais la code review, avec une protection des branches pour forcer la review de x personnes.
C'est plutôt sain, et ça permet d'accompagner les personnes dans leurs propositions de changement plutôt que de rentrer en guerre contre elles.
 
Dans un second temps, si ce n'est pas déjà fait, une CI et des tests. Et refuser ensuite toute proposition de PR qui ne met pas à jour les tests.
 
 
edit : ah, y avait une page de plus, je suis ultra burned évidemment

 
Non mais si on doit commencer a discuter
 

 
Ne pas avoir la fibre c'est quand meme moche
 
 

 
Sur github tu peux simplement lui donner des droits de lecture sans écriture par exemple ?
 
 
Je pars du principe qu'a partir du moment ou il fou pas le bordel tu seras content

C'est risqué d'exposer son serveur critique tout court.
Et là tu exposes directement le point d'entrée sur le serveur, même s'il y a une authentification, tu es pas à l'abri d'une vulnérabilité qui te bypass celui-ci.

Il faut réduire la surface d'attaque, donc moins tu exposes, mieux c'est.
Pour ça aussi qu'on utilise des reverse proxy, ainsi tu exposes que ce qui est nécessaire pour le service (http par exemple), puis ton serveur application est dans un réseau privé.

Une piste de changement serait de tenter de changer la façon de percevoir les erreurs. C'est notre job de produire des bugs, de casser les trucs, on doit s'attendre à ça, ce n'est pas un échec.
On se défend de nos erreurs, avec les PRs, les tests, les mise en prod progressives. À aucun moment on ne demande aux gens d'arrêter d'en commettre.

L'Univ locale
 
Sinon oh oh oh
 
 
 

Améliorer la sécurité par de l'opacité, ça c'est de la stratégie gagnante  

Non, mais on peut supposer que les gens, après qu'on leur ait expliqué le principe des PR, des tests, de la nocivité de l'absence de communication et autres, aient retenu les explications et ne commettent plus les mêmes erreurs.
Aucun souci avec le principe de faire des erreurs, comme tu le dis, on en fait tous. Mais faire les mêmes erreurs quand on a eu toutes les billes et les explications pour ne plus les reproduire, c'est avec ça que j'ai du mal.

 
Un grand classique malheureusement…

 
Ce que je propose, même si je me doute que ça va aller nulle part, c'est d'aider à faire accepter les changements de mode de fonctionnement en changeant la façon dont ils sont présentés. Manifestement, vu sa réponse, le collègue pense que le problème c'est qu'il se soit trompé ; alors que fondamentalement, le problème c'est qu'il ait poussé un changement comme s'il était infaillible. Si tu arrives à convaincre tout le monde (même si tu n'en penses rien) qu'une PR rejetée ce n'est pas un jugement ni une sanction, et que restreindre les accès au dépôt c'est pour se protéger communément et pas contre certains en particulier, ce sera plus simple de changer les habitudes.
 
Maintenant ce qu'il va se passer si vous mettez ça en place, c'est que rapidement M. Mauvais réalisera que ses PRs mettent bien plus longtemps à être acceptées, et que ça le ralentit injustement. Il ne progressera sans doute pas significativement, et n'acceptera jamais l'utilité d'un tel procédé. N'empêche que les extraits que tu as cités montrent qu'il y a un truc à faire avec la culture de l'équipe, même si le cas du collègue est sans doute désespéré.

En même temps c’est 95kloc de C++, la vraie solution c’est de tout supprimer mais je présume qu’il y en a qui sont réfractaires au changement

En parlant de Java, j'ai donc débarqué sur une grosse application SpringBoot et disons qu'après 15 ans de Python... Ca fait bizarre
 
Est ce que vous avez des ressources sous la main sur les "bonnes pratiques" pour structurer correctement ce type d'app, les trucs à faire ou ne pas faire, les libs recommandées ou à éviter etc ? (je cherche pas un tuto ou hello world, je cherche à comprendre si ce que je vois dans le code c'est la façon normale de faire dans une grosse app Java/Springboot ou si c'est une bouse sans nom)

 
fixed.
 

 
this.

Personne n'est dupe  

Déjà dis nous ce que c'est comme type d'application et ce que ça fait grossièrement ?

 
Sûrement une API "rest" en mode CRUD

 
Ben j'aime pas Spring Data, je trouve délirant d'avoir un MachinRepository et un TrucRepository pour faire du CRUD alors qu'un TheRepository avec des méthodes comme ça :
 

 
ca suffit à faire un CRUD pour toutes les entités avec un seul bean Spring, sans création de proxies au runtime, etc...
 
Et j'aime pas Spring Data, je trouve que le bordel ajouté au runtime pour faire du Spring Data ne compense pas le confort relatif de ne pas avoir à écrire des requêtes JPA.
 

Si tu dois chercher des entités via une property particulière ?
 
Tu vas les ajouter toute dans ton TheRepository ? Dans des @Service qui s'injectent le repository ?
 
 

 
Non, dans ce cas je fais une sous-classe dédiée. Mais l'idée c'est de la faire quand tu en a besoin, et pas par défaut.
PArce que quand t'as un gros modèle avec 50 entités, les 50 repostory dont seulement 3 ou 4 ont des méthodes dedans, je trouve ça inutile au possible.
 
Et casse couille quand tu composes des grosses grappes : si t'es oibligé de te faire injecter plusieurs repo, c'est moins joli que un seul (bon si tu tombes dans ce genre de cas t'as certainement un problème de conception de ton modèle en réalité)
 

 
C'est pas possible de faire un "findBy(criteria)" ?

 
Si bien sûr, mais si tu en a beaucoup à faire, ça peut vite devenir le bordel.
 
Idem si tu veux bien ranger ton modèle en sous-ensembles cohérents.
 
L'idée du "repo pseudo-unique", c'est de lui faire gérer le CRUD de toutes les entités qui n'ont pas d'autres opérations, pas plus.

Généralement pour de petites apps/microservices sur un seul domaine, j'utilise les layers classiques controller > service > repository.
 
Pour des apps plus grosses comme des monolith avec plusieurs domaines jaime bien l'approche de spring modulith (https://spring.io/projects/spring-modulith).
 
Ma stack généralement c'est Spring Boot + spring data (+ hibernate) + spring security + mapstruct (+ vavr et lombok).  
Pour la partir test Junit5 + assertJ + mockito + mockserver + instancio + archunit (pour check que les layers archi sont respectés justement l).

Ok donc tu crées des classes finalement, that's too bad. Ton raisonnement tombe à l'eau.
 
Je vois pas le concept d'avoir un repository trans entity, tu as entendu parler de single responsibility ? Ca doit être chiant à gérer maintenir et tester.