IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un tribunal ordonne à GitHub de produire des informations d'identification sur l'auteur de la fuite du code source de Twitter,
L'on ignore toujours ce qu'Elon Musk compte faire de ces informations

Le , par Bill Fassinou

8PARTAGES

4  0 
Le tribunal de première instance du district du nord de la Californie a répondu favorablement à la demande d'Elon Musk d'obliger GitHub à lui révéler l'identité de l'auteur de la fuite de certaines parties du code source de Twitter. Il a obtenu une assignation à comparaître obligeant GitHub à produire toutes les informations d'identification associées au compte "FreeSpeechEnthusiast" d'ici le 3 avril. En outre, GitHub est également invité à démasquer les personnes ayant téléchargé les morceaux de code publiés sur sa plateforme par FreeSpeechEnthusiast. Jusque-là, Musk est resté muet sur le traitement qu'il réserve à toutes ces personnes.

Selon les documents déposés par Twitter le 24 mars devant le tribunal de district du nord de la Californie, "divers extraits" du code source de sa plateforme de médias sociaux ont été publiés sur GitHub. Une demande de retrait adressée à GitHub en vertu de la loi américaine DCMA indique que le matériel divulgué contient le code source propriétaire de la plateforme et des outils internes de Twitter. On ne sait pas si le code source utilisé pour recommander des tweets fait partie de la fuite. La plateforme d'hébergement de code source, propriété de Microsoft, a déclaré vendredi avoir supprimé les morceaux de code source conformément à la demande de retrait.

Les documents judiciaires désignent l'utilisateur de GitHub "FreeSpeechEnthusiast" comme responsable de la fuite des parties du code source de Twitter. Elon Musk et les siens ont joint aux documents judiciaires une citation à comparaître pour obliger GitHub à faire tout ce qui est en son pouvoir afin de retrouver l'identité réelle de l'individu qui se cache derrière le pseudonyme FreeSpeechEnthusiast. Vendredi, GitHub n'a pas dit s'il entendait se conformer à la demande Twitter, mais ce mercredi, le tribunal a signé l'assignation à comparaître. GitHub a donc jusqu'au 3 avril pour dévoiler plus d'informations sur le propriétaire du compte FreeSpeechEnthusiast.


Ces informations d'identification comprennent : le(s) nom(s), adresse(s), numéro(s) de téléphone, adresse(s) électronique(s), données de profil de médias sociaux, et adresse(s) IP, pour le(s) utilisateur(s) associé(s) au compte FreeSpeechEnthusiast. GitHub a également reçu l'ordre de fournir le même type d'informations sur tous les utilisateurs qui ont posté, téléchargé ou modifié les données dans le dépôt de code affiché par FreeSpeechEnthusiast. En outre, selon les termes de l'assignation, les informations devront également inclure toutes les informations d'identification fournies ultérieurement à des fins de facturation ou d'administration.

L'on ignore depuis combien de temps exactement le code source de Twitter a été publié sur GitHub. Mais certains rapports, publiés la semaine dernière, indiquent que le code était apparemment sur GitHub depuis des mois avant que les dirigeants de Twitter ne soient informés de la fuite. Un article paru dimanche dans le New York Times cite des sources indiquant que les dirigeants de Twitter craignent "que le code comporte des failles de sécurité qui pourraient donner à des pirates ou à d'autres parties motivées les moyens d'extraire des données d'utilisateurs ou de mettre le site hors service". Un problème qui pourrait enfoncer davantage la plateforme.

De même, Twitter pense que la source de la fuite pourrait être un ingénieur qui a quitté le bureau de San Francisco l'année dernière. En effet, des personnes au fait de l'affaire ont rapporté vendredi que Twitter a ouvert une enquête sur la fuie et les cadres chargés de l'affaire supposent que le responsable avait quitté la société l'année dernière, notamment dans les vagues de licenciements massifs orchestrés par Musk. Depuis qu'il a racheté Twitter pour 44 milliards de dollars fin octobre, environ 75 % des 7 500 employés de l'entreprise ont été licenciés ou ont démissionné. Musk, qui est très actif sur Twitter, n'a pas commenté publiquement la fuite.

Le code source propriétaire fait souvent partie des secrets commerciaux les mieux gardés d'une entreprise. Le rendre public risque de révéler les vulnérabilités de son logiciel à des attaquants potentiels, et peut également donner un avantage à ses concurrents en leur permettant de voir des fonctionnements internes non publics. Le code source a été une cible fréquente pour les pirates informatiques dans le passé, notamment lors d'attaques contre Microsoft et le développeur de Cyberpunk 2077, CD Projekt Red. Twitter fait déjà face à d'innombrables problèmes et une cyberattaque massive liée à cette fuite pourrait plonger la plateforme dans les abysses.

Peut-être que le milliardaire est simplement furieux que quelqu'un l'ait devancé. En fait, Musk a révélé sur Twitter au début du mois (ce n'est toutefois pas la première fois qu'il fait une telle annonce) que l'algorithme de recommandation de l'entreprise dans son code source serait ouvert à partir du 31 mars. Bien que Twitter et Musk n'aient pas indiqué qu'ils allaient rendre l'ensemble du code source accessible au public, il a déclaré que "ce premier coup d'œil derrière le rideau serait embarrassant au début" et qu'il s'agissait d'une tentative pour que Twitter gagne la confiance de ses utilisateurs. Une confiance rudement mise à mal depuis des mois.


Depuis qu'il a racheté le réseau social, Musk fait la une des journaux en raison des licenciements massifs répétés, des licenciements aléatoires de départements entiers de Twitter, et même des plaintes concernant la valeur de l'entreprise, qui selon les propres dires de Musk, a baissé de plus de 20 milliards de dollars. En outre, notons que le pseudonyme FreeSpeechEnthusiast pourrait être une autre façon pour l'auteur de la divulgation de narguer encore plus Musk. Le pseudonyme peut se traduire littéralement par "adepte de la liberté d'expression", ce qui rappelle la façon dont Musk a l'habitude de se décrire sur les réseaux sociaux et dans les médias.

Quant à l'assignation à comparaître adressée à GitHub, certaines sources rapportent qu'il ne semble pas très difficile d'obtenir une citation à comparaître en vertu de la DMCA (Digital Millennium Copyright Act - une loi votée en 1998) si elle concerne quelqu'un qui a directement publié un contenu illicite. Le texte de la DMCA stipule que si une notification d'infraction satisfait aux dispositions de la loi, et si "l'assignation proposée est en bonne et due forme, et la déclaration qui l'accompagne est correctement exécutée, le greffier émet et signe rapidement l'assignation proposée et la renvoie au demandeur pour qu'il la remette au fournisseur de services".

En théorie, GitHub peut toujours contester les demandes d'assignation. « Alors que les citations à comparaître en vertu de la DMCA sont censées fournir une voie légale rapide pour révéler l'identité d'un contrefacteur présumé, les plateformes qui reçoivent une citation à comparaître peuvent toujours la contester devant un tribunal, en particulier si elles estiment qu'elle implique les droits de liberté d'expression de l'utilisateur », rapporte Bloomberg. Toutes les demandes d'assignation à comparaître liées au droit d'auteur ne sont pas toujours faciles à traiter. Des assignations à comparaître visent régulièrement les plateformes comme Reddit et Google.

Par exemple, ce mois-ci, Marvel a demandé au tribunal du district nord de Californie d'assigner Reddit et Google pour obtenir l'identité des personnes prétendument impliquées dans la fuite de dialogues d'Ant-Man et la Guêpe avant la sortie du film : Quantumania. Le tribunal a approuvé l'assignation à comparaître de Google et de Reddit quelques jours après la demande de Marvel.

Source : document de justice (PDF)

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de la décision du tribunal ?
Selon vous, que pourrait faire Elon Musk de ces informations ?
Pensez-vous que GitHub se conformera à l'assignation à comparaître ?

Voir aussi

Des parties du code source de Twitter ont été divulguées sur GitHub et Elon Musk tente activement d'identifier le coupable, cet incident vient s'ajouter aux nombreux problèmes de l'entreprise

Musk a déclaré que Twitter ouvrirait son algorithme, puis aurait licencié les personnes qui pouvaient le faire

Les licenciements sur Twitter se poursuivent en 2023 : Elon Musk aurait licencié le personnel de modération du contenu en Irlande et à Singapour, Twitter a perdu environ 5000 sur ses 7500 travailleurs

Elon Musk indique que l'algorithme de recommandations de Twitter pourrait être publié en open source « la semaine prochaine », après avoir soutenu l'idée pendant des mois

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de HaryRoseAndMac
Membre extrêmement actif https://www.developpez.com
Le 30/03/2023 à 20:22
Le mec qui a fait fuité le code de twitter à mon avis doit avoir perdu 10kg de goutes de sueur tombées du front depuis la plainte.
0  0 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 30/03/2023 à 22:49
Citation Envoyé par HaryRoseAndMac Voir le message
Le mec qui a fait fuité le code de twitter à mon avis doit avoir perdu 10kg de goutes de sueur tombées du front depuis la plainte.
a mon avis quand tu vole un code et que tu le publie en libre acces, tu fait ce qu'il faut pour te proteger.
Et vu que ca ne concerne pas la sécurité nationale, je doute qu'ils aient acces a toutes les sources d'information pour enqueter..
0  0 
Avatar de HaryRoseAndMac
Membre extrêmement actif https://www.developpez.com
Le 30/03/2023 à 23:02
Citation Envoyé par Aiekick Voir le message
a mon avis quand tu vole un code et que tu le publie en libre acces, tu fait ce qu'il faut pour te proteger.
Et vu que ca ne concerne pas la sécurité nationale, je doute qu'ils aient acces a toutes les sources d'information pour enqueter..
Sauf qu'il l'a publié sur Github.
Donc il suffit d'une seule fois ou l'individu ne ne soit pas connecté à travers un VPN ou autre moyen pour ne pas diffuser son IP pour s'authentifier, pour que l'individu soit fini.

Github depuis le rachat par Microsoft log tout de chez tout.

Il aura beau avoir pris des précautions, poster du code sur Github quand on veut être anonyme, c'est aussi intelligent que croire qu'échanger des informations sensibles sur gmail est sans risques.
0  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 31/03/2023 à 8:07
Citation Envoyé par HaryRoseAndMac Voir le message
Sauf qu'il l'a publié sur Github.
Donc il suffit d'une seule fois ou l'individu ne ne soit pas connecté à travers un VPN ou autre moyen pour ne pas diffuser son IP pour s'authentifier, pour que l'individu soit fini.
On peut supposer qu'il a utilisé un compte Github créé pour l’occasion est qu'il n'a pas utilisé sa connexion perso (voire même pas son ordinateur perso). Ça me parait le strict minimum quand on fait ce genre de chose.
0  0 
Avatar de HaryRoseAndMac
Membre extrêmement actif https://www.developpez.com
Le 31/03/2023 à 21:59
Citation Envoyé par Uther Voir le message
On peut supposer qu'il a utilisé un compte Github créé pour l’occasion est qu'il n'a pas utilisé sa connexion perso (voire même pas son ordinateur perso). Ça me parait le strict minimum quand on fait ce genre de chose.
Ben ...
Espérons pour lui lol
0  0 
Avatar de binarygirl
Membre chevronné https://www.developpez.com
Le 02/04/2023 à 1:02
Sûrement, je dois faire partie des amateurs puisque je commente un peu le code.
Je suis d'accord que le code bien conçu parle de lui-même, mais le contexte n'est pas forcément obvious. Le "comment" est clair et il doit l'être, ce qui n'est pas forcément toujours clair, c'est le "pourquoi". Et il y aussi des connaissances business relatives à l'implémentation qu'on ne connaît pas forcément. A fortiori quand on reprend le code de quelqu'un d'autre.

Les commentaires permettent aussi de générer de la documentation, par exemple Sphinx avec les docstrings.
A moins que vous considériez la documentation comme inutile ?

Je rajoute que sur certains projets nous sommes plusieurs à travailler. S'il faut reprendre le travail de quelqu'un c'est bien de savoir ce qu'il pensait quand il a codé tel ou tel truc, quand le code à lui seul ne suffit pas à restituer le contexte.
Même moi, je ne suis pas sûre de ce que je pensais il y 5 ans...
Sur certains projets, l'historique remonte à 10 ans voire plus, et évidemment il y des développeurs qui sont partis depuis longtemps, d'autres sont arrivés.
Il y a eu plusieurs générations qui se sont succédé, avec chaque fois une perte de connaissance et de savoir-faire. Et tout n'est pas dans la doc interne, le wiki...

Je considère que reprendre le code d'un autre est rarement un cadeau, alors je m'efforce à rendre le mien pas trop pénible

Et quand vous travaillez sur des domaines plus particulier (un exemple parmi d'autres: sur un automate industriel), on peut se retrouver dans des situations où il y a plus de commentaires que de code, mais c'est justifié. Par exemple, on peut être amené à commenter les bits sur lesquels on travaille, ou expliquer pourquoi on limite la taille du buffer à tel endroit, c'est parce que il y a un composant électronique derrière, avec ses limitations techniques.... Mais tout ça on ne peut pas le deviner juste en regardant le code.

En réalité, le "bruit" ne gêne pas. Si on travaille proprement le code est typiquement structuré de telle sorte qu'on a un fichier par classe, voire par fonction. Les fichiers sont petits.. Et donc la lecture et le défilement du code n'est pas pénible. Les commentaires ne gênent pas la compréhension, au contraire (sauf évidemment quand ils induisent en erreur !)
Ce qui gêne, c'est le "bloat", les fonctions mal écrites, pas optimisées, buggées difficiles à lire. Un code non commenté n'est pas forcément du clean code, d'après mon expérience je dirais que c'est le contraire

Et je ne parle même pas de langages plus hardus comme l'assembleur mais il y a le Verilog, de nouveau il me paraît inenvisageable de ne pas commenter le code.

En réalité, le code non documenté est rare, car même si la fonction est constituée de code pur, il y a forcément un commentaire dans le git commit, qui est probablement lui-même lié à un issue dans Jira, Redmine ou autre.
0  0 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 06/04/2023 à 1:32
Citation Envoyé par HaryRoseAndMac Voir le message
Sauf qu'il l'a publié sur Github.
Donc il suffit d'une seule fois ou l'individu ne ne soit pas connecté à travers un VPN ou autre moyen pour ne pas diffuser son IP pour s'authentifier, pour que l'individu soit fini.

Github depuis le rachat par Microsoft log tout de chez tout.

Il aura beau avoir pris des précautions, poster du code sur Github quand on veut être anonyme, c'est aussi intelligent que croire qu'échanger des informations sensibles sur gmail est sans risques.
je vois en quoi ca annule ce que je dis. et un vpn n'est aucunement une securité.
car les societe de vpn ont tous les logs aussi.

ce faire un script d'upload, que tu declenche vite fait avec le wifi du mcdo bondé au heures de pointe sur un compte github cree pour l'occasion avec un telephone rooté ou tu auras bien viré tout les traceurs de google, changer 'ladresse mac. etc... je te laisse imaginer
0  0 
Avatar de HaryRoseAndMac
Membre extrêmement actif https://www.developpez.com
Le 01/04/2023 à 1:07
Citation Envoyé par foetus Voir le message
je ne fais que passer … mais cela c'est la définition THÉORIQUE du commentaire de la méthode agile (dans le manifeste ? dans les pratiques Extrem Programming (XP) ? autre ?, facile à trouver)

C'est la réaction à la conséquence de la réalité "la vraie vie de développeur" : lorsque tu commentes 1 "bout de code", il faut reprendre le commentaire à chaque modification (avec le temps que cela prend)
Et avec le temps, balec / 20 du commentaire et le commentaire ne correspond plus à ton "bout de code" … à moins que tu aies 1 équipe ultra disciplinée avec peut-être 1 revue de code/ commentaire à chaque "mise à jour".

C'est pour cela que dans les méthodes agiles, on préfère remplacer les commentaires [autant que faire se peut] soit par des "bouts de code" uni fonctionnels et petits ("self-documenting" soit par des tests unitaires (<- et les tests permettent de réfléchir à l'"algorithme".
Et à défaut, 1 bon commentaire, surtout si tu as 1 grosse formule, des nombres magiques … des "trucs" à expliquer vraiment.
Il y a du presque vrai et du faux dans ton propos.
Faux : Le fait que les développeurs depuis belle lurette ne mettent plus de commentaires dans le code source, ne vient pas de l'agile.
L'agile ce sont des méthodologies et non pas une méthode.
L'Agile n'a aucun rapport avec les bonnes pratiques du code, ce sont des modèles de gestion à adapter.

C'est le clean code, comme je l'ai indiqué, qui a formalisé le pourquoi, il est en réalité stupide, de commenter dans 95% des cas.
Quand l'entête de ta méthode indique que tu retourne un string, que ton typage indique que tu dois retourner un string, et que le code de la méthode indique que tu retourne un string, à un moment donné, il faut commencer à penser comme un développeur, c'est à dire comme quelqu'un d'intelligent et non pas comme un des nombreux attardés que l'on retrouve dans les ESN.

presque vrai : Dans 95% des cas, les commentaires dans le code sont inutile non pas, pour des raisons de maintenabilité, surtout que de nos jours, on a des outils qui génèrent et mettent à jour automatiquement les commentaires, mais tout simplement parce que c'est du bruit.
Ils ne servent littéralement à rien.
et la partie presque vrai de ton argument est qu'effectivement, le tdd est un très bon guide qui remplace les commentaires, mais aussi tout simplement l'architecture du logiciel.

Un logiciel découplé intelligemment, selon des principes d'une architecture propre, des principes SOLID, des principes du clean code et j'en passe, rends dans 95% des cas l'écritures des commentaires totalement stupide.

Mais bon, pour faire comprendre ça aux gens du forum dont la plupart bossent dans des ESN depuis qu'ils ont eu un premier job et donc, ont un niveau proche du néant et des capacités intellectuelles pour faire ce job aussi crédible qu'une huitre à qui l'ont demanderais de démontrer la conjecture de Poincaré, ou alors pire, sont des espèces de managers, le truc qui ne sert totalement à rien dans le monde du dev à part foutre en l'air des salaires et faire croire que ce type de poste est au dessus du métier de développeur, c'est bien la seule raison.
0  1 
Avatar de HaryRoseAndMac
Membre extrêmement actif https://www.developpez.com
Le 02/04/2023 à 4:40
Citation Envoyé par binarygirl Voir le message
Sûrement, je dois faire partie des amateurs puisque je commente un peu le code.
Je suis d'accord que le code bien conçu parle de lui-même, mais le contexte n'est pas forcément obvious. Le "comment" est clair et il doit l'être, ce qui n'est pas forcément toujours clair, c'est le "pourquoi". Et il y aussi des connaissances business relatives à l'implémentation qu'on ne connaît pas forcément. A fortiori quand on reprend le code de quelqu'un d'autre.

Les commentaires permettent aussi de générer de la documentation, par exemple Sphinx avec les docstrings.
A moins que vous considériez la documentation comme inutile ?

Je rajoute que sur certains projets nous sommes plusieurs à travailler. S'il faut reprendre le travail de quelqu'un c'est bien de savoir ce qu'il pensait quand il a codé tel ou tel truc, quand le code à lui seul ne suffit pas à restituer le contexte.
Même moi, je ne suis pas sûre de ce que je pensais il y 5 ans...
Sur certains projets, l'historique remonte à 10 ans voire plus, et évidemment il y des développeurs qui sont partis depuis longtemps, d'autres sont arrivés.
Il y a eu plusieurs générations qui se sont succédé, avec chaque fois une perte de connaissance et de savoir-faire. Et tout n'est pas dans la doc interne, le wiki...

Je considère que reprendre le code d'un autre est rarement un cadeau, alors je m'efforce à rendre le mien pas trop pénible

Et quand vous travaillez sur des domaines plus particulier (un exemple parmi d'autres: sur un automate industriel), on peut se retrouver dans des situations où il y a plus de commentaires que de code, mais c'est justifié. Par exemple, on peut être amené à commenter les bits sur lesquels on travaille, ou expliquer pourquoi on limite la taille du buffer à tel endroit, c'est parce que il y a un composant électronique derrière, avec ses limitations techniques.... Mais tout ça on ne peut pas le deviner juste en regardant le code.

En réalité, le "bruit" ne gêne pas. Si on travaille proprement le code est typiquement structuré de telle sorte qu'on a un fichier par classe, voire par fonction. Les fichiers sont petits.. Et donc la lecture et le défilement du code n'est pas pénible. Les commentaires ne gênent pas la compréhension, au contraire (sauf évidemment quand ils induisent en erreur !)
Ce qui gêne, c'est le "bloat", les fonctions mal écrites, pas optimisées, buggées difficiles à lire. Un code non commenté n'est pas forcément du clean code, d'après mon expérience je dirais que c'est le contraire

Et je ne parle même pas de langages plus hardus comme l'assembleur mais il y a le Verilog, de nouveau il me paraît inenvisageable de ne pas commenter le code.

En réalité, le code non documenté est rare, car même si la fonction est constituée de code pur, il y a forcément un commentaire dans le git commit, qui est probablement lui-même lié à un issue dans Jira, Redmine ou autre.
Attention je n'ai pas dit qu'il fallait 0 commentaires.
J'ai dit qu'un commentaire qui explique ce que fait une méthode = tu es un amateur.
Un commentaire qui dit que la méthode retourne un string = tu es un amateur.
...

Je t'invite à te renseigner sur la clean architecture, le clean code, ... et à passer encore 4 ou 5 ans à faire de l'architecture logicielle et tu comprendras pourquoi les commentaires ne servent à rien dans 95% des cas.

Tout ce que tu viens d'évoquer, ce sont des erreurs que font les développeurs juniors, moi en tête quand j'étais jeune et avant que je prenne au sérieux l'architecture et le code, donc il y a plus de 25 ans, et même encore aujourd'hui, ma boite travaille sur des outils industriels d'usine, et on a vu l'avant et après une architecture logicielle propre et l'avant après les réelles bonnes pratiques.

Surtout ta partie sur l'assembleur, puisque les machines d'usines sont soient en C, soit en assembleur.
Ca ne nous empêches pas d'avoir une architecture propre, pas de commentaire, ... en assembleur.

Commentaires = débutant.
Les commentaires doivent être là pour de rare cas bien spécifique, dans 95% des autres cas, ils ne sont pas justifiés et justifiables et ne démontre qu'une incapacité du développeur à être réellement pro et à connaitre les bonnes pratiques, à réellement découpler son code, à réellement réfléchir et comprendre des contextes (ce qu'on appel des bounded contexte), à réellement mettre en place des tests, et j'en passe.

Même sur des logiciels d'usine ou autre, les commentaires ne servent à rien, c'est une démonstration d'incompétence avant tout.
Et concernant ton propos sur Jira, là encore, ça démontre de l'amateurisme profond.

Ca fait des années que ceux qui font réellement de l'Agile ont mit Jira et consort à la poubelle et ont mis dans la poubelle toutes les pull requests et autres bullshit de devs juniors qui pensent le code comme une forme de sectarisme/evangelisme et non comme une matière scientifique en évolution constante qui ne doit pas reposer sur des dogmes mais sur de la compréhension profonde qui se base sur des faits, de l'utilité et de l'intelligence pure et dure.

Développeur c'est pas sysadmin.
Un développeur ne repose pas sur des certitudes avec des choses qu'on lance et qui marche, il repose sur de l'abstraction et de la compréhension.

Hors trop de gens ne comprennent pas qu'un développeur et un chercheur c'est exactement le même métier et qu'un développeur n'est pas un ingénieur.
Un ingénieur, ça applique des formules par coeur toute la journée, un chercheur ça les inventent.

Mais bon, va faire comprendre ça à un type qui bosse dans une ESN ...
C'est comme vouloir apprendre à courir à un estropié.
0  1 
Avatar de binarygirl
Membre chevronné https://www.developpez.com
Le 02/04/2023 à 16:38
Citation Envoyé par HaryRoseAndMac Voir le message

Ca ne nous empêches pas d'avoir une architecture propre, pas de commentaire, ... en assembleur.
Hâte de voir ça !
Citation Envoyé par HaryRoseAndMac Voir le message

Et concernant ton propos sur Jira, là encore, ça démontre de l'amateurisme profond.

Ca fait des années que ceux qui font réellement de l'Agile ont mit Jira et consort à la poubelle et ont mis dans la poubelle toutes les pull requests et autres bullshit de devs juniors qui pensent le code comme une forme de sectarisme/evangelisme et non comme une matière scientifique en évolution constante qui ne doit pas reposer sur des dogmes mais sur de la compréhension profonde qui se base sur des faits, de l'utilité et de l'intelligence pure et dure.
Les outils utilisés varient au gré de mes missions, mais je n'ai pas l'impression de travailler avec des amateurs.
Là où je bosse actuellement, les outils comme Jira sont utilisés pour faire le suivi des tâches à exécuter et planifier en fonction des ressources, et aussi faire le suivi des demandes des clients, en vue de facturer le travail accompli (qui est souvent facturé au nombre de jours, il faut un minimum de rigueur dans la comptabilisation des activités).

Mais à vous entendre, toutes les très grosses boîtes qui utilisent Jira sont des amateurs

Du coup, je me demande comment vous gérez vos ressources, la relation client, la facturation et tout ça. Un tableau Excel ?
Rassurez-moi vous avez un outil de versioning du code quand même ?
0  1