Qu'est-ce que je suis content de ne plus en faire

Après, pas trop testé le 4 encore.. Mais j'suis pas pressé

Qu'est-ce que je suis content de ne plus en faire

Après, pas trop testé le 4 encore.. Mais j'suis pas pressé

Perso j'ai toujours passé bien plus de temps de sueur et de larmes sur des gros refactorings pour s'adapter à des trucs non anticipés. Prévoir un design un peu plus générique que nécessaire ça coûte peu comparativement. Sur 10 design 'trop' génériques a priori si un seul t'épargne un gros refactoring a posteriori t'es déjà rentable.

un soft est basé sur des assomptions. Certaines tiennent dans le temps, d'autres non, et c'est assez imprédictible. Et on a eu beaucoup de hit and miss dans les deux sens (anticiper des trucs qui ne sont jamais arrivés, et donc on a du se trimbaler la complexité d'un truc inutile, ou des trucs non anticipés qui se sont avérés très chiants à migrer).

Moi je veux bien en parler de complexité de design...

Je viens de modifier 27 fichiers pour ajouter 1 propriété dans 2 entités... sous Symfony... j'ai envie de tuer des gens.

Qu'est-ce que je suis content de ne plus en faire

Après, pas trop testé le 4 encore.. Mais j'suis pas pressé

Same.

J'ai adoré Symfony. Mais je peux tellement plus blairer ça, ou même PHP aujourd'hui.

Perso j'ai toujours passé bien plus de temps de sueur et de larmes sur des gros refactorings pour s'adapter à des trucs non anticipés. Prévoir un design un peu plus générique que nécessaire ça coûte peu comparativement. Sur 10 design 'trop' génériques a priori si un seul t'épargne un gros refactoring a posteriori t'es déjà rentable.

vous voulez faire du Java et de l'Angular, tas de cons ?
c'est pas des gens que j'ai envie de tuer moi, mais des chatons

 
Expérience inverse ici, tous les projets sur lesquels je suis passés étaient bourrés de code "au cas où" et ça n'a pas aidé, au contraire.
Je ne te parle même pas des cas où le métier change d'avis plus tard, enterre la feature ou veut un truc entière différent.
 
Garder le logiciel facile à modifier, s'est s'en tenir à des règles de design ouvert et simple, pas de faire des hypothèses supplémentaires qui sont pour la plupart foireuses. Or ici, tu fais une hypothèse. Tu n'as aucune idée de savoir si ta relation va devenir du N-N, donc tu décides de complexifier le design au pif.
Pas une bonne idée du tout, si on ne sait pas on fait au plus simple.
 
Et la migration de données ne semble pas complexe du tout, si jamais faire ce genre de choses est un obstacle majeur au projet, c'est pas un souci de YAGNI, c'est que le processus de livraison est pourri.

 
Ah non mais c'est pas Symfony le problème... c'est la boite qui a fait le dev à l'origine
 
Mais sinon Symfo 4 c'est bonheur.
 
C'est juste que là, pour un truc tout con, je suis obligé des *Command, des *CommandHandler, des Entity/MyEntity, des DTO/MyEntityDTO, la config XML des entités, les migrations, des CreatedEvent etc.
 
 
Edit: à la base je précisais "sous Symfony" justement pour souligner que "normalement", ça aurait demandé la modif de 4 fichiers quoi

Expérience inverse ici, tous les projets sur lesquels je suis passés étaient bourrés de code "au cas où" et ça n'a pas aidé, au contraire.
Je ne te parle même pas des cas où le métier change d'avis plus tard, enterre la feature ou veut un truc entière différent.
 
Garder le logiciel facile à modifier, s'est s'en tenir à des règles de design ouvert et simple, pas de faire des hypothèses supplémentaires qui sont pour la plupart foireuses. Or ici, tu fais une hypothèse. Tu n'as aucune idée de savoir si ta relation va devenir du N-N, donc tu décides de complexifier le design au pif.
Pas une bonne idée du tout, si on ne sait pas on fait au plus simple.
 
Et la migration de données ne semble pas complexe du tout, si jamais faire ce genre de choses est un obstacle majeur au projet, c'est pas un souci de YAGNI, c'est que le processus de livraison est pourri.

vous voulez faire du Java et de l'Angular, tas de cons ?
c'est pas des gens que j'ai envie de tuer moi, mais des chatons

 
Expérience inverse ici, tous les projets sur lesquels je suis passés étaient bourrés de code "au cas où" et ça n'a pas aidé, au contraire.
Je ne te parle même pas des cas où le métier change d'avis plus tard, enterre la feature ou veut un truc entière différent.
 
Garder le logiciel facile à modifier, s'est s'en tenir à des règles de design ouvert et simple, pas de faire des hypothèses supplémentaires qui sont pour la plupart foireuses. Or ici, tu fais une hypothèse. Tu n'as aucune idée de savoir si ta relation va devenir du N-N, donc tu décides de complexifier le design au pif.
Pas une bonne idée du tout, si on ne sait pas on fait au plus simple.
 
Et la migration de données ne semble pas complexe du tout, si jamais faire ce genre de choses est un obstacle majeur au projet, c'est pas un souci de YAGNI, c'est que le processus de livraison est pourri.

Je commence à tâter le terrain pour construire une équipe commerciale pour vendre XCP-ng, avec un gars aux US et un en EMEA (je vais prendre un allemand probablement).

Concernant un profil de commercial aux US avec de l'XP sur la vente de techno IT comme la virtu, ça se trouverai à combien à votre avis ? J'ai l'air de voir autour de 100k$ mais je sais pas la proportion de fixe/variable là dedans

Ça me paraît léger 100k$ ... Pour un senior

C'pas facile postgres quand tu es habitué à MySQL quand même.

Généré des uuid automatique, c'est un peu un parcours. Pourtant, ça me semblait normal en 2019.

Ça me paraît léger 100k$ ... Pour un senior

le rapport Air Ethiopia est sorti : la version courte c'est que quand les pilotes ont coupé l'électricité du compensateur, ils ont pas réussi à compenser à la main. Y'avait déjà trop de forces sur les surfaces, ils avaient absolument besoin d'une assistance électrique. Ils ont remis l'électricité et le truc s'est remis à déconner.
 
https://www.youtube.com/watch?v=HBqDcUqJ5_Q

Il a pas dit où aux US.

Je commence à tâter le terrain pour construire une équipe commerciale pour vendre XCP-ng, avec un gars aux US et un en EMEA (je vais prendre un allemand probablement).

Concernant un profil de commercial aux US avec de l'XP sur la vente de techno IT comme la virtu, ça se trouverai à combien à votre avis ? J'ai l'air de voir autour de 100k$ mais je sais pas la proportion de fixe/variable là dedans

C'pas facile postgres quand tu es habitué à MySQL quand même.
 
Généré des uuid automatique, c'est un peu un parcours. Pourtant, ça me semblait normal en 2019.

Avec postrges, je te conseille d'utiliser des schema , et de ne pas mettre toutes tes tables dans public, surtout si tu veux utiliser Postgis (l'extension carto) , ça te simplifiera les montée de version

 
 
J'ai rien compris à ton message.
 
J'pense que ça veut dire que je dois me taper de la doc. Moi j'veux juste stocker des choses simples, le projet est pas super gros, j'dois avoir 5/6 tables. Rien de fou. Un MySQL aurait largement fait le taff, mais je voulais changer pour découvrir un peu.

 
 
J'ai rien compris à ton message.
 
J'pense que ça veut dire que je dois me taper de la doc. Moi j'veux juste stocker des choses simples, le projet est pas super gros, j'dois avoir 5/6 tables. Rien de fou. Un MySQL aurait largement fait le taff, mais je voulais changer pour découvrir un peu.

tu peux grouper tes tables dans des schemas.

Ensuite au lieu de faire select * from user, tu vas faire select * from auth.user

Ce n'est pas obligatoire, mais j'ai toujours trouvé que c'était une bonne pratique, plutôt que les prefixes de tables

 
T'as le CV pour pas faire des projets de merde.
Tu fais des projets de merde.
A un moment tu cherches un peu non ?

 
J'ai fais presque 1 an d'AngularJs.

c'est sans doute propre à chaque équipe, mais données à l'appui, c'était pas du tout le cas chez nous.
On a eu des gros refactorings qui nous ont fait salement bouffer le grenouille sur 2-3 projets (300k estimé, réel à 1.3M, et 500k estimé, réel à 4M), mais à chaque fois aucun refactoring n'aurait empeché ça. Par contre je me suis pris une tripoté d'optimisations à coup de 50jh par ci, 100jh par là, qui au final n'empechaient pas de prendre des surcouts de 50/100 jours parce que l'optimisation avait rien empeché en fait.

Sur des assumptions techniques ça tient la route (par ex si tu sais que tu fais +20% de croissance par an, tu peux te planter à un an près, mais tu sais que ton app va taper une limite et que tu peux l'anticiper, tu le fais), mais les assumptions sur le fonctionnel je suis pas d'accord une seconde : c'est beaucoup trop imprédictible.

Expérience inverse ici, tous les projets sur lesquels je suis passés étaient bourrés de code "au cas où" et ça n'a pas aidé, au contraire.
Je ne te parle même pas des cas où le métier change d'avis plus tard, enterre la feature ou veut un truc entière différent.

Garder le logiciel facile à modifier, s'est s'en tenir à des règles de design ouvert et simple, pas de faire des hypothèses supplémentaires qui sont pour la plupart foireuses. Or ici, tu fais une hypothèse. Tu n'as aucune idée de savoir si ta relation va devenir du N-N, donc tu décides de complexifier le design au pif.
Pas une bonne idée du tout, si on ne sait pas on fait au plus simple.

Et la migration de données ne semble pas complexe du tout, si jamais faire ce genre de choses est un obstacle majeur au projet, c'est pas un souci de YAGNI, c'est que le processus de livraison est pourri.

 
je t'envoie un MP dans la matinée

Je suis curieux de connaître la longévité de vos bases de code du coup Parce que sur du one shot ou des durées courtes de maintenance genre 3-4 ans je veux bien qu'on s'en tienne au plus simple et qu'on avise sur le moment, mais ici sur une base de code en évolution constante depuis 14 ans ça a payé plus d'une fois dans le dev d'une feature d'avoir rendu le design souple et évolutif 4-5 ans plus tôt même si rien ne le requerrait à l'époque. En tout cas bien plus que "tiens cette sur-généricité nous gêne pour faire évoluer le code merde"

Bah justement, nos clients sont bien éparpillés aux US, alors son emplacement à lui ça compte peu

Après ouais, j'imagine plutôt en fixe, reste à voir la part variable. Mais là je marche dans une zone que je connais peu, je fais en sorte de m'entourer mais c'est découverte totale sinon

L'ecommerce a été créé en 2010, et je l'ai géré de 2012 a 2015. Il tapait sur un ERP maison avec du code de début 2000 (Procedures stockees Oracle et UI en Magic).
Et pour te donner une idée, on devait avoir 15 dev back, une dizaine de dev intégration, et 80+ en Java (Hybrid), et 5 en front (web). La base de code bougeait dans tous les sens, j'avais 14MCHF de budget annuel pour les projets.
Donc je pense qu'on rentrait pas dans la catégorie "appli pépère"

 
Je suis curieux de connaître la longévité de vos bases de code du coup   Parce que sur du one shot ou des durées courtes de maintenance genre 3-4 ans je veux bien qu'on s'en tienne au plus simple et qu'on avise sur le moment, mais ici sur une base de code en évolution constante depuis 14 ans ça a payé plus d'une fois dans le dev d'une feature d'avoir rendu le design souple et évolutif 4-5 ans plus tôt même si rien ne le requerrait à l'époque. En tout cas bien plus que "tiens cette sur-généricité nous gêne pour faire évoluer le code merde"

80 dev java pour du ecommerce

 
Y'a des gens qui font des trucs un peu plus sérieux que vendre des bouquins hein

Perso j'ai toujours passé bien plus de temps de sueur et de larmes sur des gros refactorings pour s'adapter à des trucs non anticipés. Prévoir un design un peu plus générique que nécessaire ça coûte peu comparativement. Sur 10 design 'trop' génériques a priori si un seul t'épargne un gros refactoring a posteriori t'es déjà rentable.