Frage:
Der IT-Berater ist gegangen und niemand kann seinen Programmierstil verstehen
Rose
2015-09-23 02:16:42 UTC
view on stackexchange narkive permalink

Es gibt eine kleine Gruppe von Programmierern, in denen ich arbeite. Vor einigen Jahren hat unser Chef einen Berater hinzugezogen, um uns bei der Umstellung auf eine neuere Programmiersprache zu helfen. Seitdem war unser Chef "zurückgetreten" und wir haben jetzt einen neuen Chef. Der Berater ist kürzlich gegangen und alles, woran er gearbeitet hat, wurde zwischen den vorhandenen Entwicklern aufgeteilt. Dieser Berater "arbeitete hauptsächlich alleine", während wir uns alle zurücklehnten und uns fragten, was er tat. Er übernahm die Richtung nur von dem Chef, der jetzt weg ist. Alle ihre Besprechungen schienen geheim zu sein, keiner der vorhandenen Entwickler hatte ein Mitspracherecht oder eine Eingabe.

Das Problem ist, dass keiner der vorhandenen Entwickler an dem neuen Code arbeiten kann, weil sie nicht verstehen, wie er funktioniert funktioniert. Der Berater war überqualifiziert. Seine fortschrittlichen Programmiermethoden haben uns in eine Situation gebracht, in der selbst die meisten einfachen Anforderungen nicht erfüllt werden können.

Wir müssen diese Ressource jetzt intern verwalten, haben jedoch nicht die Erfahrung oder das Wissen dazu erhalten. Wie können wir dieses Problem lösen?

Dies könnte eine Frage für http://programmers.stackexchange.com sein, da es mehr um das Entschlüsseln von Code als um den Arbeitsplatz geht. Können Sie den Berater jedoch für einen Tag dazu bringen, seinen Code zu erklären?
`Der Berater war überqualifiziert. Seine fortgeschrittenen Programmierweisen ... `Das klingt nicht nach einem * über * qualifizierten Individuum, sondern nach einem einsamen Wolf. Ein Programmierer, der komplizierten, schwer verständlichen Code erstellt, ist ** kein ** guter Programmierer, egal wie gut dieser Code funktioniert.
Ich stimme dafür, diese Frage als nicht zum Thema gehörend zu schließen, da es anscheinend nicht darum geht, am Arbeitsplatz zu navigieren, wie in der Hilfe definiert.
@Lilienthal Der Fragesteller hat ein Problem mit einem ehemaligen Mitarbeiter, der keine Übergabeinformationen zu einer Unternehmensressource bereitstellt. Dies ist in hohem Maße ein Problem am Arbeitsplatz
Nur eine Randnotiz: Das Lesen und Verstehen von schlechtem Code ist Teil Ihrer Arbeit als Programmierer. Der Code aller anderen ist scheiße. Sogar deine von vor ein paar Wochen ist scheiße. Der ganze Code ist scheiße. Erwarten Sie niemals, dass es nicht saugt.
@JaneS - Ich denke, diese Frage könnte an beiden Orten funktionieren. Es gibt den Programmiereraspekt, wie sie es herausfinden. und es gibt den Workplace-Aspekt, wie sie ausbrechen und das Geschäftsproblem angehen, das sie haben.
Kommentare sind nicht für eine ausführliche Diskussion gedacht. Diese Konversation wurde [in den Chat verschoben] (http://chat.stackexchange.com/rooms/29462/discussion-on-question-by-rose-it-consultant-left-and-no-one-can-understand- seine).
Sieben antworten:
Kent A.
2015-09-23 02:53:20 UTC
view on stackexchange narkive permalink

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.

Gute Antwort. Ich möchte nur hinzufügen, dass es überall Ressourcen für so ziemlich jede Sprache gibt, es sei denn, der Berater hat eine neue Sprache erfunden. Ich verstehe nicht, warum Ihr Team die neue Sprache nicht gründlich gelernt hat oder zumindest nicht genug, um eine einfache Verwaltung und Änderung durchzuführen. Wenn ich es verstehe, war er jahrelang dort, aber am Ende des Tages war er Berater. Was hat Ihr Team / Chef gedacht? Färbe mich verblüfft. Ich denke, es ist eine Lernerfahrung, tun Sie, was Kent gesagt hat, und erklären Sie es Ihrem Chef so gut Sie können.
Stellen Sie nur fest, dass es keine Voraussetzung dafür gibt, dass der Codierer super schlau ist, um seinen Code nicht zu verstehen. Sie können super dumm sein und die Leute werden den Code auch nicht verstehen.
Für # 2 schlage ich vor, dass Sie auch herausfinden, wie Sie Tests hinzufügen (oder die vorhandenen ausführen), damit Sie beim Ändern von Dingen wissen, ob Sie etwas kaputt gemacht haben, wenn Sie auf dem neuesten Stand sind und Änderungen vornehmen. Wenn Sie diese Testinfrastruktur schreiben, lernen Sie auch, wie sie funktioniert. Dies hilft Ihnen, Vertrauen in die Codebasis zu gewinnen.
Ich habe das in beide Richtungen gesehen. Programmierer, die sich für super klug hielten und ein übermäßig komplexes Durcheinander verursachten, und Programmierer, die geschlagen wurden, weil sie versucht hatten, aktuelle Techniken in einem Geschäft anzuwenden, das in der Vergangenheit feststeckte. Für einige Geschäfte sehen Abhängigkeitsinjektion und funktionale Programmierung wie Martian aus.
Ich würde einen Schritt 5 hinzufügen, um festzustellen, ob die Pflege des ursprünglichen Codes die Zeit / die Fähigkeiten eines neuen Entwicklers wert ist. Es kann kostengünstiger sein, den Code im Laufe der Zeit umzugestalten / zu ersetzen.
Es könnte sich lohnen, die Wichtigkeit hervorzuheben, ehrlich zu sein, wenn es an Fähigkeiten im Team mangelt. Wenn es sich um eine neue Sprache oder einen neuen Codierungsstil handelt, kann es für die Benutzer schwierig sein, diese zu erlernen. Sie haben den Hintergrund zu sagen, dass wir nie viel Zeit hatten, um mit dem Berater oder Code zu interagieren, sodass es eine Wissenslücke gibt. Wenn Sie bereit sind zu lernen, bitten Sie um Zeit und / oder Training, um zu helfen. Wenn dies nicht der Fall ist, markieren Sie die Notwendigkeit eines neuen Teammitglieds mit anderen Fähigkeiten.
@kevincline: Und umgekehrt habe ich noch nie jemanden gesehen, der wegen der Verwendung von zu einfachem Code beschimpft wurde :) Er kann bei Bedarf immer optimiert werden.
@kevincline, Bei einem früheren Job wurde mir einmal gesagt, ich solle die Verwendung von Zeigern einschränken und keine Zeigerarithmetik in meinem C-Code verwenden, da dies meinen Code "schwer verständlich" machte. Weil Zeiger schwer sind. Oder so.
@kevincline Ich habe genau das gesehen, außer dass der Programmierer Inversion of Control anstelle der Abhängigkeitsinjektion verwendet hat. Niemand verstand seinen Code und er konnte keine Managementunterstützung erhalten, also ging er und es dauerte Jahre und 50 +% Managementumsatz, bis wir, die Entwicklungsabteilung, diese modernen Programmierparadigmen erneut in Angriff nahmen. Aber als wir das gemacht haben, haben wir es zusammen gemacht.
@Juha: bedeutet meiner Erfahrung nach "einfach" oft "Kopieren-Einfügen, Zeile für Zeile leicht verständlich, aber nicht getestet, nicht testbar, nicht wartbar".
Kilisi
2015-09-23 02:30:40 UTC
view on stackexchange narkive permalink

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.

Ich denke, dies ist eine schlechte Lösung, insbesondere für ein kleines Unternehmen, bei dem die Kosten einer solchen Gaffe nicht einfach absorbiert werden können.
es zu ignorieren ist eine schlechtere Lösung, ein Problem zu sehen, es zu beheben oder es zu jemandem zu bringen, der es kann, ist sowieso meine Politik. Besonders für ein kleines Unternehmen mit begrenzten Ressourcen. Und je früher, desto besser, wenn Sie die Kosten langfristig so niedrig wie möglich halten möchten.
@KentAnderson guter Punkt, ich hätte es besser formulieren können, ich meinte es eher mit "es ist ein Problem, dessen sich der Chef bewusst sein muss".
guest
2015-09-23 08:00:44 UTC
view on stackexchange narkive permalink

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? :)

gnasher729
2015-09-23 13:52:23 UTC
view on stackexchange narkive permalink

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).

Jonathan Rosenne
2015-09-23 13:17:04 UTC
view on stackexchange narkive permalink

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.

Dies scheint eine sehr intensive Lösung für den Codeteil dieses speziellen Problems zu sein, aber eine nette Erklärung für das Refactoring
Als Sie sagten: "* wahrscheinlich brauchen Sie dafür einen Fachberater *" Ich fand das lustig. Nicht sicher, war das ein Witz? Es scheint, dass alle es verpasst haben, auch Sie, wenn Sie es nicht als eines beabsichtigt haben!
Ich habe nur versucht höflich zu sein.
Keltari
2015-09-23 07:39:32 UTC
view on stackexchange narkive permalink

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.

MACMAN
2015-09-23 13:35:16 UTC
view on stackexchange narkive permalink

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.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...