Es ist eine sehr häufige Situation, die am Arbeitsplatz auftritt - der allwissende Superheld ist jetzt verschwunden (aus guten oder schlechten Gründen und aus welchen Gründen auch immer), und das Team von normalen Menschen im Alltag muss abholen und Machen Sie weiter.

Schritt 1. Sprechen Sie mit Ihrem Management und teilen Sie ihm die Fakten mit. Beschuldigen, beurteilen oder kritisieren Sie nicht. Erklären Sie einfach, dass es für Sie und das Team sehr schwierig ist, die Software zu befolgen, und dass es zusätzliche Zeit in Anspruch nimmt, sich mit den vorhandenen Funktionen vertraut zu machen. Neue Arbeiten werden daher für einen bestimmten Zeitraum langsamer.

Schritt 2. Teilen und Erobern. Teilen Sie die Software als Team auf eine Weise auf, die Sie vereinbaren können on und jeder von Ihnen verpflichtet sich, der Teamexperte für Ihren Teil des Codes zu werden. Tauchen Sie ein. Nehmen Sie kleine Änderungen vor, versuchen Sie, die Ergebnisse vorherzusagen, erstellen Sie sie neu und prüfen Sie, ob Sie sie richtig vorhergesagt haben. Geben Sie sich eine Frist (vielleicht 1 oder 2 Wochen). Erstellen Sie selbst eine Dokumentation.

Schritt 3. Bringen Sie sich gegenseitig Ihre Ergebnisse bei. Treffen Sie sich regelmäßig, um zu besprechen, was Sie finden. Halten Sie sich gegenseitig für die Erstellung einer guten Dokumentation verantwortlich, die zu einer Art Handbuch kombiniert werden kann. Senden Sie die Dokumentation an Ihr Management, damit diese sehen kann, dass Sie Fortschritte machen.

Schritt 4. Wiederholen Sie diesen Vorgang, bis Sie kompetent sind.

In Schritt 2 werden Sie Dies könnte beinhalten, dass die eigentliche Arbeit erledigt wird, um herauszufinden, wie alles funktioniert.

Es ist eine Lüge, dass der Guru für den Job überqualifiziert wurde. Was tatsächlich passiert ist, ist, dass Sie und der Rest des Teams ihm erlaubt haben, alles zu übernehmen, und Sie haben sich nicht darauf konzentriert, das System so zu lernen, wie Sie es hätten tun sollen. Es könnte die am schlechtesten gestaltete Software aller Zeiten sein, oder es könnte ein Kunstwerk sein. Aber Sie werden es nie erfahren, bis Sie es beruflich und emotional in Besitz nehmen.

Scheint einfach genug. Sagen Sie Ihrem neuen Chef, es ist ein Problem, dessen er sich bewusst sein muss. Und je früher, desto besser, da dies schnell zu einem sehr ernsten Problem für das Unternehmen werden kann, wenn dringende Arbeiten erforderlich sind und niemand weiß, wo er anfangen soll.

Erklären Sie dem neuen Chef im Grunde, was Sie uns gerade gesagt haben und dann lass ihn damit umgehen. Mit etwas Glück erhalten Sie möglicherweise sogar eine bezahlte Schulung, mit der Sie sich auf Kosten des Unternehmens weiterbilden können.

Es ist immer am besten, eine Lösung im Auge zu haben, wenn Sie mit einem Chef über Probleme sprechen. In diesem Fall ist eine Weiterbildung eine Option, die ich ansprechen würde, was eine Auszeit von anderen Aufgaben bedeuten würde, damit Sie oder ein anderer Entwickler sich besser konzentrieren können.

Eine andere mögliche Lösung ist ein Berater, der kurzfristig hinzugezogen werden muss Arbeiten Sie mit den Entwicklern zusammen.

Lassen Sie dann den Chef seinen Job machen und treffen Sie seine Entscheidungen.

What you need is an overview of the architecture, and the best person to give it is the consultant. If talking to him is is not leading anywhere, let him prepare diagrams, how everything is linked together, on a high level.

With this information, look at the code, try to identify things or where you would make changes. Then in a second round, let him describe in more detail the things you want to change and where to do that.

You give him a list of features A-F and for each feature he tells you the file and maybe function name. Then you try to implement your changes. Try to involve him as little as possible, so you better understand where your deficits are and what you have to learn.

Don't try to directly migrate things to your known languages. There is a reason he was brought in and his language might be better. Try to learn it, so you can make an eductated decission which parts to keep maintaining and which parts to move to a familiar language, or a completely different one.

Also try to figure out which parts of his code are standard for that language and which one he has just hacked together. Try to switch to standard solutions where you see fit. That makes future maintenance a lot easier and will reduce training for new coworkers who already know the language and the standard way of doing things.

Just out of curiosity, what technology are we talking about? :)

80% of the answer belongs into software development (probably programming.stackexchange).

The 20%: You need to tell your new manager or new boss as soon as possible what is happening. Probably the best way for him to fix the problem is hiring an experienced contractor for a month to assess that person's code (just because you think he was overqualified doesn't make it so; a highly qualified person would leave code that you can pick up).

After that month, the company needs to either decide that this person's code is just rubbish and cannot be salvaged, or to ask that contractor to stay for another few months, put the code into a shape that can be maintained, and train a few of you guys to be able to take on the work.

On the other hand, that assessment might be very quick: As an example, I write lots of code in Objective-C with blocks, and if you have never seen this, it looks frightening. It takes a week to learn it and two weeks to love it. So in that situation someone could come in and say "this is just ordinary Objective-C code, you just have to learn it" (would apply to any other language).

Refactoring ist der richtige Weg. Es kostet Zeit und Geld, und wahrscheinlich benötigen Sie einen spezialisierten Berater, um dies zu tun.

Das bedeutet, dass Sie den komplizierten und undurchdringlichen Code Schritt für Schritt ändern, vorzugsweise jedoch mithilfe von Tools auch von Hand und Regressionstests für jeden Schritt. Das Refactoring reicht von relativ einfachen Dingen wie dem Umbenennen von Variablen und Prozeduren über verständlichere Namen bis hin zur Umstrukturierung des Codes. Jeder einzelne Schritt ist überschaubar und ändert sich nicht zu den Ergebnissen des Codes. Natürlich behalten Sie den Originalcode separat bei, da dies Ihr Maßstab und Bezugspunkt ist.

Übrigens werden Sie dabei höchstwahrscheinlich Fehler im Originalcode entdecken, und es ist eine schwierige Entscheidung, wann Korrigieren Sie sie - während des Refactorings oder nach Abschluss -, denn wenn Sie sie zu früh reparieren, verlieren Sie möglicherweise die Option, die Ausgabe des refactored Codes mit der Ausgabe des Originalcodes zu vergleichen.

Viel Glück.

This is not uncommon. I have been in similar situations and it can feel overwhelming. Talk to your supervisor and explain the situation, as other people have said.

The first thing I would do is ask the former consultant if he would be willing to come back and explain his code. He might be amiable and do it for free. However, he might only come back if you pay him.

At this point the onus is on you and your development team to take copious notes and ask as many questions as possible. Learn as much as you can about how and why he wrote his code the way he did.

First check the style of coding. Did he use a framework? If so first check the framework documentation and try to understand the concept. A good code review is the next thing you have to do. A code review will reveal how and why a certain code is implemented. A special task force can be entrusted with the RAiligjrcaqampD and code review. Once they find coding flow it is a matter of starting from there.