FUUUUUUUUUUU UUUUUUUUUU UUUUUUUUUUU UUUUUUUUUUUUU - Page 2

Kevin Kofler (./29) :
Bah, pourquoi pas 1. faire un revert et 2. écrire un mail au stagiaire que son commit était foireux et a donc été inversé et que par conséquent il doit tout refaire de zéro le lendemain (vu qu'il ne sera probablement pas capable de consulter l'historique, vu sa manière incompétente d'utiliser le SCM)? Ça lui apprendra…

c'est complètement à l'opposé de la philosophie du truc... c'est un merge qu'il faut faire, sinon c'est comme si tu travaillais tout seul dans ton coin avec un backup pour un rollback de ci de là...

c'est svn ou git ? Sur svn on ne peut pas pousser les fichiers qui n'ont pas la même version mais je suppose qu'il a updaté et qu'il a un IDE qui ne recharge pas les fichiers et donc il a tout écrasé tes modifs. Faut le prévenir qu'il doit updater ces fichiers en ayant aucun fichier ouvert sinon tu risques de retrouver le problème.

C'est svn et Visual Studio, qui prévient qu'il y a des modifs externes.
Je pense qu'il a simplement écrasé avec une sauvegarde externe.
Cela dit, il utilise aussi notepad++, possible que ça vienne de là.
Merci pour la suggestion, en tout cas !

svn refuse le commit si ta wc n'est pas updatée.
git refuse le pull si ta wc est en conflit avec les modifs pullées.

donc non

Mmmm ?
Ma théorie, c'est qu'il a en effet mis à jour sa copie locale, et seulement ensuite repris sa sauvegarde manuelle.

non pas rapport a quoi ? la sauvegarde externe ? ça pour moi ce n'est pas possible il a simplement pas recharger les fichiers dans les éditeurs et resauvegarder le tout. Donc dans le référentiel en local les fichiers sont à jours mais ces fichiers non.

après, y'a la solution : "tout écraser sans demander" au moment du merge ou sinon : dév offline, ctrl+a, ctrl+c, update, ctrl+a, ctrl+v, commit

grincheux (./36) :
la sauvegarde externe ? ça pour moi ce n'est pas possible

Pourquoi ?

Pen^2 (./30) :
Je devais modifier un truc qui dépendait directement du code effacé.On doit livrer une version intermédiaire demain soir.

Dommage. Ce n'est pas normal que tu passes ton temps à réparer les erreurs de quelqu'un d'autre.

vince (./31) :

Kevin Kofler (./29) :
Bah, pourquoi pas 1. faire un revert et 2. écrire un mail au stagiaire que son commit était foireux et a donc été inversé et que par conséquent il doit tout refaire de zéro le lendemain (vu qu'il ne sera probablement pas capable de consulter l'historique, vu sa manière incompétente d'utiliser le SCM)? Ça lui apprendra…

c'est complètement à l'opposé de la philosophie du truc...

C'est le stagiaire qui n'a pas utilisé correctement l'outil, inverser son commit ne serait que la manière la plus simple de réparer les dégâts qu'il a causés.

Kevin Kofler (./39) :
Dommage. Ce n'est pas normal que tu passes ton temps à réparer les erreurs de quelqu'un d'autre.

Ouep, je t'avoue que j'étais *un peu* énervé (surtout vu le contexte du projet, mais bref )

squalyl (./34) :
svn refuse le commit si ta wc n'est pas updatée.
git refuse le pull si ta wc est en conflit avec les modifs pullées.

donc non

WC: updated?


WC en conflit avec d'autres outils ?

owi

Kevin Kofler (./39) :
C'est le stagiaire qui n'a pas utilisé correctement l'outil, inverser son commit ne serait que la manière la plus simple de réparer les dégâts qu'il a causés.

Tiens, c'est exactement ce que j'aurais fait (s'il n'y a pas eu de commit par un tiers après, bien sûr... là, ça serait plus problématique pour démêler les ficelles), mais en envoyant un petit mail juste assez poli pour lui expliquer la situation et lui indiquer comment récupérer son boulot.

(oué, mais là, on avait une deadline )

Et la nuit, ça sert à quoi ?

à exploser la tête du stagiaire.

Nil (./46) :
Et la nuit, ça sert à quoi ?

Pen^2 (./30) :
23:37

%'(

awww

En plus je ne suis pas habitué à veiller

Chuis sûr que c'est un challenger de plptp qui a soudoyé le stagiaire !

(Au fait, il a un anus comment, maintenant, ledit stagiaire ?)

ne mélange pas Pen^2 et bearbecue

(Je lui demanderai de ta part )

Pen^2 (./45) :
(oué, mais là, on avait une deadline )

Tant pis, ce serait son travail qui aurait raté la deadline, pas le tien.

(Cela dit, on aurait peut-être eu droit à une histoire sur The Daily WTF au sujet du méchant "vieux" qui sabote le travail d'un pauvre stagiaire. )

Ben, si, puisqu'il avait justement viré mon code, et que je devais encore ajuster des choses
EDIT : ah oui, si, en revertant, OK... Mais bon, le client, c'est pas vraiment son problème.

()

cette après midi en ayant une nouvelle fonctionnalité à implémenter, on a vu des trucs étranges dans le code à modifier, donc on a voulu faire un peu de ménage dans le code, démarré par moi il y a 3 ans, puis confié à une collègue (partie depuis) pour qu'elle le reprenne et le continue:

class chose {
  private int fvalue;
    public void setvalue(int value) {
    value = value;
  }
}

une classe remplie, en gros de :

class chose {
  private int fvalue;
    public void setvalue(int value) {
    fvalue = value;
    autreclasse.setvalue(value);
  }
  etc etc
}

des chaines d'appels qui enchainent les conversions entre byte[] et String à coup de bin2hex et hex2bin, au moins 4 à la suite à travers les différents appels. Et bien sûr, sans test de nullité nulle part.

une réimplémentation d'une méthode bin2hex bien optimale à coup d'appels à la classe Formatter

en inlinant du code de classes inutiles, on a réussi à générer un stack overflow à cause un getinstance() de sigleton dont le constructeur privé fait appel à un autre getinstance dans un autre singleton, lui même faisant appel au premier. C'était masqué à cause d'une instruction indispensable mais commentée (on comprend pourquoi).

On a plein de form générées par netbeans et remplies de code correspondant aux évènements, et puis j'ai découvert tout un tas d'appels à des classes machinchouettecontroller qui ne font que forwarder des appels

et le mieux, notre produit a des plugins, qui reposent sur une api à base d'interfaces dont les implémentations se trouvent dans le code principal. Eh bien quand elle a eu besoin de nouvelles fonctionnalités, au lieu d'ajouter des entrées dans l'interface, elle a juste fait une méthode getotherfunctions() qui renvoie directement une implémentation de ces fonctions (implémentation stockée dans le projet API directement, pas dans le code principal) ce qui lui a demandé des tonnes de classes proxies mal écrites, et des modifs cheloues un peu partout.

Et bien entendu, quand elle a fait tout ça, elle ne m'a posé aucune question d'architecture, en me disant "oui oui" chaque fois que je lui demandais si elle s'en sortait avec l'architecture de ce que j'avais écrit avant.

Résultat, j'ai l'impression de voir un tapis volant qui cache un gros tas de merde et que mon projet a été amélioré graphiquement, mais niqué en interne. Je précise que là où on bosse on a chacun un projet, on est censés être indépendants, et que personne n'a de relation de garde chiourme avec les autres développeurs. On lui a fait confiance après qu'elle aie réussi quelques trucs corrects, mais non, ce truc là, elle l'a bien foiré, et elle s'est surtout posé aucune question quant a la complexité et à la torducité de ce qu'elle écrivait.

Résultat, 2h de refactoring cette aprem pour virer un tas de classes inutiles, bon c'est pas perdu, ça a permis au nouveau collègue de bien comprendre le genre d'archi du code qu'on attend, et ce qu'il faut pas faire Lui est bien plus compétent, je sens en codant en tandem qu'il comprend ce qu'il voit, c'est marrant, c'est la première fois que je codais en live binome avec quelqu'un sans m'engueuler avec lui parce qu'il comprend pas

FUUUUUUUUUUUUUUUU

Classe.

.class, même.

^^

Ça me rappelle mon ancien boulot... ils avaient confié une partie du code à un gars dont ils se sont aperçus plus tard qu'il était complètement incompétent... et pareil, ils ne demandait rien, il disait "oui oui" mais faisait n'importe quoi. Des mois après son départ (pas vraiment volontaire ^^), on ramassait encore les morceaux, et chaque découverte d'une nouvelle partie de son code était une occasion de facepalm