Posté par nazcafan .
En réponse au journal C++14.
Évalué à 5.
Mouais, j'ai eu droit à cette rhétorique il y a quelques années. La boîte utilisait alors un gcc 3.4.6, et ils ne voyaient pas l'intérêt de mettre à jour.
Un jour, j'ai écrit un truc du genre:
int*a=newint[LENGTH]();
j'ai mis un moment avant de comprendre que mon code déconnait sévère parce que le compilo refusait d'initialiser les valeurs à zéro, et encore un moment pour comprendre que je pouvais me brosser pour avoir un correctif.
Alors refuser les versions récentes sous prétexte que la qualité a un coup, OK, mais le risque est de se retrouver sur des versions obsolètes, non maintenues qui t'obligent à écrire des contournements qui n'ont pas lieu d'être.
Je préfère un modèle de mise à jour régulière et progressive de la toolchain (on est pas obligé de toujours mettre du bleeding edge, hein), avec une procédure de validation bien définie, voire automatique. D'une part on le fait souvent, du coup on intègre des bonnes pratiques et ça évite d'avoir la « peur du changement ». D'autre part, le manque de qualité a également un coût, et sur le long terme, une boîte qui traine une grosse dette technique se fera ramasser par ses concurrentes, simplement parce qu'elle sera incapable de faire des changements importants dans un laps de temps raisonnable.
[^] # Re: En entreprises...
Posté par nazcafan . En réponse au journal C++14. Évalué à 5.
Mouais, j'ai eu droit à cette rhétorique il y a quelques années. La boîte utilisait alors un gcc 3.4.6, et ils ne voyaient pas l'intérêt de mettre à jour.
Un jour, j'ai écrit un truc du genre:
j'ai mis un moment avant de comprendre que mon code déconnait sévère parce que le compilo refusait d'initialiser les valeurs à zéro, et encore un moment pour comprendre que je pouvais me brosser pour avoir un correctif.
Alors refuser les versions récentes sous prétexte que la qualité a un coup, OK, mais le risque est de se retrouver sur des versions obsolètes, non maintenues qui t'obligent à écrire des contournements qui n'ont pas lieu d'être.
Je préfère un modèle de mise à jour régulière et progressive de la toolchain (on est pas obligé de toujours mettre du bleeding edge, hein), avec une procédure de validation bien définie, voire automatique. D'une part on le fait souvent, du coup on intègre des bonnes pratiques et ça évite d'avoir la « peur du changement ». D'autre part, le manque de qualité a également un coût, et sur le long terme, une boîte qui traine une grosse dette technique se fera ramasser par ses concurrentes, simplement parce qu'elle sera incapable de faire des changements importants dans un laps de temps raisonnable.