L'étape 1 est que vous devez provenir d'un état d'esprit que cela (la mise à jour casse d'autres choses) n'est pas normal. Votre mise à jour ne doit pas interrompre ni ralentir d'autres parties de l'application. Ce n'est pas bien, ce n'est pas normal et ce n'est pas la faute de l'utilisateur quand il s'en plaint. Vous devriez faire autant de tests que possible pour essayer de l'empêcher. Lorsque cela se produit, vous avez un problème urgent.
L'étape 2 est que vous devez savoir ce que vous avez fait. Votre système de contrôle des sources peut peut-être vous aider, ou une sorte de système de suivi du travail, mais vous devez être en mesure de dire la minute où vous recevez l'une de ces plaintes "ok, j'ai ajouté une colonne à ce tableau, modifié cette grille pour calculer les nouvelles taxes, a ajouté ces deux nouveaux rapports ... "et ainsi de suite.
L'étape 3 est que vous devez avoir de l'expérience pour trouver rapidement des problèmes de performance et des plantages, afin de savoir quelles sortes de choses sont susceptibles de les causer et que vous pouvez résoudre le problème immédiatement. Cette chose a été mise en ligne et vous devez trouver le problème rapidement et obtenir un patch. La modification d'un rapport ne peut pas ralentir une partie de l'application qui n'utilise pas le rapport. Vous êtes maintenant en mode d'urgence et devez déterminer où est l'erreur et que faire à ce sujet - sans interrompre une autre partie de l'application dans le processus.
L'étape 4 est pour chacune de ces misères, vous devriez apprendre une leçon que vous testerez pour la prochaine fois. Vous deviendrez "ce type" qui s'oppose à certaines constructions parce que "ce sera horrible quand il y aura 10 000 enregistrements".
Un peu plus sur le front "c'est normal". Je gère (parmi toutes les autres choses que nous avons en cours) un projet agile pour un client externe. Nous produisons environ toutes les 6 semaines depuis deux ou trois ans maintenant. Et oui, la sortie est prévue à la minute près. Nous en avons fait un à 8h hier. Et à peu près à chaque 4e ou 5e version (une ou deux fois par an, en d'autres termes), quelque chose se casse en direct, et nous passons à l'action et faisons les choses le plus rapidement possible. Même si nous testons et testons et testons avant la sortie. Ensuite, nous leur disons ce qui s'est passé. "Il y avait un petit bogue dans le déploiement de juin qui laissait ce champ vide, mais nous ne l'avons jamais remarqué parce que nous n'utilisions pas la valeur à ce moment-là. Ensuite, dans ce déploiement lorsque nous avons commencé à utiliser le champ, ceux qui étaient vides ont causé ce message d'erreur que vous avez vu. Nous J'ai corrigé le bogue afin qu'il ne puisse pas être vide, mis des valeurs dans les mauvais enregistrements et confirmé qu'il ne faisait plus exploser. Nos excuses. "Ou" Ce changement d'urgence que vous aviez demandé, deux jours seulement avant la libération, a eu des conséquences auxquelles nous n'avons pas pensé et que nous n'avons pas testés. Rappelez-vous pourquoi nous résistons aux changements d'urgence? "Je ne suis peut-être pas un mauvais programmeur pour avoir aggravé la situation avec la mise à jour, mais j'ai sûrement fait une mauvaise chose. Et je dois faire les choses correctement. Je ne suis peut-être pas un mauvais programmeur pour avoir aggravé la situation avec la mise à jour, mais j'ai sûrement fait une mauvaise chose. Et je dois faire les choses correctement. Je ne suis peut-être pas un mauvais programmeur pour avoir aggravé la situation avec la mise à jour, mais j'ai sûrement fait une mauvaise chose. Et je dois faire les choses correctement.