Avec plusieurs développeurs qui soumettent des modifications à la même base de code (et ne sont pas toujours à jour les uns avec les autres), ces choses se produiront. Je suis moi-même développeur; il n'y a pas de quoi se raccrocher, cela nous arrivera à tous au moins une fois. Il y a cependant deux choses que vous pouvez faire pour réduire le risque que cela se reproduise.

D'après le contexte, il semble que vous ayez tout testé localement et que cela a bien fonctionné. Ce n'est que plus tard que quelque chose a mal tourné. Cela suggère que votre propre base de code était légèrement obsolète et / ou que quelqu'un d'autre avait du code obsolète lorsqu'il a commis ses propres modifications. La meilleure chose que vous puissiez faire, juste avant de valider votre code, est d'extraire toutes les modifications récentes de votre référentiel (ou peu importe comment vous l'appelez) afin que vous puissiez être sûr que vos modifications fonctionnent avec le code le plus à jour. Si tous vos tests réussissent, alors vous pouvez vous engager en toute conscience.

Je suggère également d'être un peu plus vocal avec vos collègues. Si vous apportez des modifications à un système critique, dites-leur-leur. Même s'il s'agit d'une simple requête comme "Je suis sur le point de changer cet élément important, avez-vous le temps de revoir le code?" . De cette façon, votre équipe ne passera pas des jours à trouver le problème, s'il y en a un, et vous pouvez être tranquille en sachant que vous ET vos collègues êtes confiants avec les changements. Certaines équipes de développement font des stand-ups quotidiens où elles expriment ce sur quoi elles travaillent; cela aide l'équipe à être plus consciente de ce sur quoi vous travaillez et s'il y a un risque que vos modifications entrent en conflit avec celles de quelqu'un d'autre.

Vous apprendrez en faisant. Si vous maîtrisez bien les langages comme C #, vous pourriez utiliser Java plus rapidement que vous ne le pensez!

Cette situation se produit de temps en temps - vous faites quelque chose qui a des effets d'entraînement imprévus sur quelque chose d'autre dont vous ne saviez pas auparavant.

Le fait que vous n'avez pas été renvoyé immédiatement ou mettre sur un PIP signifie que l'entreprise reconnaît que des erreurs se produisent, qu'elles sont résolues et que la vie évolue en conséquence.

Que pouvez-vous y faire? Renseignez-vous sur cette conséquence et voyez s'il y a autre chose que vous auriez dû prendre en compte ou toute autre équipe à laquelle vous auriez dû poser des questions sur les effets d'entraînement de la modification d'une API.

Tout cela fait partie de la construction expérience et cela ne devrait pas vous décourager d'aller de l'avant.

Le moyen d'éviter ce problème vous offre également la possibilité de contribuer de manière significative à votre nouvelle entreprise: la racine de ce problème est un test inadéquat, pas vous (sauf si vous avez fait preuve de négligence d'une manière qui n'apparaît pas dans votre message ).

Dans tous les environnements de développement, il devrait être possible de déterminer si le changement que vous avez effectué va provoquer un échec majeur avant l'enregistrement et de déterminer si le le code va casser la construction. S'il est vraiment embarrassant d'être celui qui trouve un tout aussi béant dans le processus de l'entreprise, vous pouvez maintenant être un leader en essayant d'établir un tel processus dans votre nouvelle entreprise.

Vous pouvez proposer que le l'équipe commence à rédiger des tests unitaires et à configurer un environnement d'intégration continue qui recompilerait le projet et exécuterait les tests unitaires à chaque fois que le code temporel est archivé, et où les tests peuvent être exécutés individuellement avant l'enregistrement. Les tests unitaires prendront engagement de l'équipe, mais un environnement CI de base peut être mis en place assez rapidement à partir de projets open source tant que vous pouvez y dédier une VM ou un serveur.

Modifier: les revues de code sont une autre bonne programmation pratique qui peut minimiser ce genre d'erreurs et qui est également assez facile à mettre en œuvre.

TL; DR profite de cette opportunité embarrassante pour moderniser les processus de développement de votre entreprise. Vous en sortirez avec une odeur de roses.

Le problème se pose que l'API est référencée dans un fichier de flux de travail BPMN qui ne s'affiche pas lorsque j'ai recherché les références ou le nom de l'API sous forme de texte dans l'EDI.

Qu'est-ce que la rétrospective des équipes sur cette surface d'incident? Quelles procédures départementales pourraient être mises en place pour que cela ne se répète pas? Qu'est-ce que l'équipe estime nécessaire lors de l'embarquement de nouveaux développeurs? Et quelles nouvelles procédures d'intégration faut-il développer?

P.S. Être proactif dans ce qui précède est un excellent moyen d'apprendre et de diriger.

Où étaient stockés les fichiers BPMN qu'ils n'étaient pas visibles lorsque vous recherchiez d'autres consommateurs d'API?

Le problème semble être que vous ne saviez pas / que vous n'aviez pas accès à tout des consommateurs d'API.

S'ils ne font pas partie de votre ensemble de travail de développement standard et pour une raison quelconque ne peuvent pas y être ajoutés, toutes les API qui sont consommées par alors doivent être documentées comme faisant ainsi dans les commentaires d'en-tête d'appel de méthode équivalents. Selon le degré de formalité de votre processus de révision, vérifier explicitement qu'ils ne sont pas affectés peut être un changement de processus valide.

Le problème de ne pas savoir tout ce qui se trouve en dehors de la base de code sur laquelle vous travaillez doit être vérifié les besoins soulevés lors de votre prochain stand-up / rétrospective par vous si vos collègues ne le font pas. Quelque chose de ce genre aurait dû être traité dans le cadre de votre intégration au projet.

Indépendamment de ce que vous ou quiconque fait pour minimiser les erreurs, les erreurs vont se produire.

Il existe, bien sûr, des bonnes pratiques techniques «cela aidera et oui, il y a toutes les platitudes sur l'apprentissage de ses erreurs. Mais tu as tout ça, il semble. Pourtant, vous vous sentez encore assez mal à propos de l'incident que vous avez pris le temps de l'écrire sur le lieu de travail.stackexchange.com?

Je pense qu'il y a quelque chose de tangible que vous pouvez faire qui vous aidera, vous et les autres, à vous sentir mieux dans tout cela.

La meilleure chose à faire est de prendre note de gentillesse et de générosité qui vous a été témoignée et exprimez votre gratitude pour cela .

Au lieu de vous excuser encore plus abondamment et de faire des promesses de "plus jamais" bientôt oubliées, prenez le temps de REMERCIER personnellement les personnes qui ont aidé à résoudre le problème et celles que vous avez gênées. Si c'est approprié, apportez une boîte de beignets (par exemple) au bureau et complétez vos collègues.

Et puis, la prochaine fois que quelque chose se passe et que quelqu'un d'autre fait une erreur, soyez gentil avec eux, aidez-les et rendez-leur la gentillesse qui vous a été donnée . C'est ça. Vous serez une meilleure équipe grâce à des choses comme ça.

Vous devez changer votre état d'esprit.

Vous n'avez pas commis "d'erreur critique". Vous avez travaillé au mieux de vos capacités; vous étiez ouvert à travailler dans un environnement inconnu; vous étiez transparent sur vos connaissances et tout le reste, avant et après; vous avez travaillé avec les autres gars pour résoudre le problème, vous n'avez probablement pas fait de colère dans le bureau. Après la débâcle, vous venez ici et essayez de vous améliorer encore plus.

En bref: je me lècherais les doigts pour avoir plus d'employés comme vous.

Pour répondre à votre question:

1. Vous ne pouvez pas personnellement éviter de telles choses, en général. L'erreur technique était complètement hors de votre portée. Si vous souhaitez être sûr à 100%, vous vous arrêterez. Vous ne pouvez pas vérifier les parties d'un système dont vous ne savez rien.
2. Les systèmes (y compris les ordinateurs et les humains) ne peuvent pas non plus être construits pour éviter de telles choses, dès qu'elles deviennent suffisamment complexes.
3. Une façon d'aborder ce problème est l'approche DevOps / Agile consistant à inviter l'échec et l'échec brutal et rapide. C'est ce que tout le CI et spécialement les CD. Vous déployez si fréquemment et rapidement que vous échouerez très souvent; et chaque fois que vous corrigez la raison particulière avec la plus grande priorité (en utilisant les techniques habituelles - tests automatisés et manuels, annulation indolore de petits commits, déploiements bleu-vert avec basculement en arrière instantané, etc.). Cela conduit logiquement à rendre l'ensemble du processus plus robuste très rapidement. Idéalement, vous faites cela à partir du jour 0. Facile? Non. Peut être amélioré pièce par pièce? Oui.

Faites vos commits aussi petits que possible, et si vous pouvez construire à partir du serveur de build après chaque push. (S'il ne se construit pas souvent, vous voudrez peut-être aussi construire avant votre push!)

Cela ne vous aidera pas à ne pas faire d'erreurs, mais cela les rendra beaucoup moins critiques. Si vous savez quel commit / groupe de commits a causé la rupture de la compilation, il est trivial de le restaurer pendant que vous travaillez sur le problème, et si les commits sont aussi petits que possible, il est plus facile de localiser la source du problème.

Si vous utilisez git, il existe même une commande pour vous aider: git-bisect, qui vous permettra de faire une recherche binaire dans un groupe de commits pour trouver celui qui cause le problème.