Wie kann ich meinen Chef (höflich) bitten, seinen Code zu kommentieren?

Ich werde von meinem Chef unterrichtet (ich habe gerade die Schule beendet und er wollte jemanden mit ein wenig Programmiererfahrung, deshalb hat er mich ausgewählt, um mich in den Spezialgebieten dieser Firma zu schulen) und fing an, mit ASP.NET MVC- Anwendungen, etwas HTML und CSS zu arbeiten . Mir geht es gut mit dem Webdesign, das er mir gibt (es ist ziemlich einfach zu verstehen, ohne es zu klären).

Aber zum Beispiel gibt er mir eine Aufgabe, die mit ASP.NET MVC zu tun hat, er erklärt es wirklich gut. Aber er erklärt nichts in dem Code, den er mir gerade gegeben hat. (In Visual Studio 2013 verwenden wir die Quellcodeverwaltung. ) Es handelt sich also buchstäblich um Hunderte von Codezeilen, ohne Hintergrundinformationen zu den beabsichtigten Aktionen. Die Art von Code, die ich sehe, ist Code, den ich noch nie zuvor gesehen habe. Es ist also wirklich schwierig, dies herauszufinden.

Ich würde versuchen, ihm mehr Fragen zu stellen, aber er arbeitet immer (es ist seine eigene Angelegenheit), und ich habe das Gefühl, dass er sich über all diese Fragen, die ich in meinen Händen habe, ärgern könnte.

Also nur etwas, das mir hilft, bis ich die Dinge in den Griff bekomme. Wie kann ich meinen Chef bitten, Kommentare in seinen Code zu schreiben, den er mir gibt, aber höflich?

Sie befinden sich am "tiefen Ende" und meiner Meinung nach ist dies der beste Weg, um zu lernen. Nicht, weil Sie Dinge suchen, von denen Sie keine Ahnung haben, sondern weil Sie einfallsreicher werden und herausfinden müssen, welche Komponenten in einem System, in dem Sie neu sind, welche Rolle spielen.

Es hilft nicht, dass Ihr Chef zu beschäftigt ist, um mit jemandem umzugehen, der neugierig ist (und Sie haben vollkommen das Recht, neugierig zu sein; Sie möchten unbedingt lernen, was gut ist). Aber leider kann es sein, dass Sie Ihren Senior nicht darum bitten, seinen Stil und seine Herangehensweise zu ändern, um zu lernen, dass Sie es mit jemandem zu tun haben, von dem Sie sagen, dass er beschäftigt ist.

Vor Tausenden von Codezeilen zu sitzen, mit denen Sie nicht vertraut sind, ist die Norm. Sie können es nicht immer in Schwarzweiß mit Kommentaren erklären lassen. Wenn Sie jedoch das Gefühl haben, dass Sie ihn auf jeden Fall um Kommentare bitten müssen, erklären Sie ihm vielleicht, warum. Erklären Sie, dass Sie ihn nicht mit Fragen belästigen möchten, da er oft beschäftigt ist. Dies kommt nicht nur viel weniger so rüber, als würden Sie ihm sagen, dass er etwas tun soll, sondern eröffnet auch den Raum für Diskussionen darüber, wie er es stattdessen vorziehen könnte, Fragen zeitlich beiseite zu legen.

Erstens ist jedes Softwareprojekt von Anfang an überall durch Tausende von Zeilen unbekannten Codes zu kriechen und sich verloren zu fühlen .

Der größte Unterschied zwischen Ihnen und einem erfahrenen Programmierer besteht darin, dass Sie nicht daran gewöhnt sind.

Ein paar Punkte zu beachten:

1. Mit genügend Aufwand ist jedes Codebit verständlich. Viele Menschen sind frustriert, wenn sie nicht innerhalb weniger Minuten etwas herausfinden können. Sei geduldiger.

2. Ein guter Chef ist so offen wie möglich für Unterbrechungen und Fragen. Ein guter Mitarbeiter ist bemüht, Unterbrechungen und Fragen so gering wie möglich zu halten. Sei dir dessen bewusst.

3. Unterbrechungen sind teurer als Fragen. Sie können Ihre Zeit und die Ihres Chefs besser nutzen, indem Sie Ihre Diskussionen konsolidieren und ein Gespräch, das Sie nie zu Ende bringen, immer verwirrt halten.

4. Ihr Chef ist ein besserer Programmierer als Sie. (Wahrscheinlich.) Das soll nicht heißen, dass man in einigen Bereichen nicht stärker sein kann, aber insgesamt ist sein Fachwissen größer. Stellen Sie sicher, dass Sie so viel wie möglich von seinem Fachwissen lernen, bis Sie eine Menge Erfahrung haben.

5. Wenn Sie sicher sind, dass mehr Kommentare den Code erheblich verbessern würden, fragen Sie Ihren Chef. "Es ist schwierig für mich zu verstehen, was an manchen Orten vor sich geht. Wenn ich Dinge herausfinde, macht es Ihnen etwas aus, wenn ich Kommentare hinzufüge?" Vielleicht hasst er Kommentare. Vielleicht wird er es lieben. Vielleicht ist er gleichgültig.

Am Ende ist es jedoch möglich, dass Sie sich in ein paar Monaten daran erinnern werden, dies gefragt zu haben und zu denken: "Hm, ich frage mich, womit ich ein Problem hatte? Das ist nicht so schlimm. Hm, na ja, egal."

Wenn Ihr Chef keine Zeit hat, alle Ihre Fragen zu beantworten, warum wird er Ihrer Meinung nach Zeit haben, seinen Legacy-Code zu kommentieren? Und außerdem, was lässt Sie denken, dass seine Kommentare wirklich die Teile beschreiben, die Sie im Moment nicht verstehen? Meiner Erfahrung nach funktioniert es nicht, wenn Sie versuchen, den Programmierstil Ihres Chefs zu ändern, indem Sie ihn nur fragen.

Das Beste, was Sie in einer solchen Situation tun können: Kommentieren Sie die Teile des Codes, die Sie verstehen müssen, um Ihre Arbeit selbst zu erledigen - Sobald Sie diese Teile verstanden haben, und nachdem Sie von Ihrem Chef die Zusage erhalten haben, dass dies in Ordnung ist. Wenn Sie oder Ihr Chef befürchten, Sie könnten etwas kaputtmachen, indem Sie Kommentare hinzufügen, fügen Sie diese in einem separaten Zweig hinzu und fragen Sie Ihren Chef, ob er sich die Zeit nehmen wird, Ihre Kommentare zu überprüfen, bevor sie in den Stamm aufgenommen werden. Da Ihr Chef nur über ein begrenztes Zeitbudget verfügt, sollten Sie zunächst selbst herausfinden, was ein bestimmter Teil tut, indem Sie eine angemessene Menge Zeit investieren. Wenn Sie wirklich nicht weiterkommen, schreiben Sie Ihre Frage in eine Liste und fragen Sie Ihren Chef beispielsweise einmal am Tag, anstatt ihn 30 Minuten lang zu stören. Meiner Erfahrung nach funktioniert dieser Ansatz mit den meisten Menschen, auch wenn sie sehr beschäftigt sind, solange sie bereit sind, Ihnen zu helfen - was in Ihrer Situation sicherlich der Fall ist.

Auf diese Weise sind Sie sicher, dass Sie die Kommentare erhalten, die Sie benötigen, und Ihr Chef wird sehen, wo Sie zusätzliche Informationen benötigen und ob Sie die Dinge richtig verstanden haben. Und solange Sie sich darauf beschränken, nur die nicht offensichtlichen Dinge zu kommentieren, besteht eine gute Chance, dass Ihre Kommentare die Gesamtqualität der Codebasis verbessern, was möglicherweise nicht nur Ihnen, sondern auch allen anderen Vorteile bringt muss sich mit dem Code befassen, einschließlich Ihres Chefs.

Lassen Sie sich als erstes ein Beispiel geben, um Ihren Code richtig zu kommentieren, Grashüpfer!

Dann muss ich das die ganze Zeit tun. Ich habe meine lokale Kopie ausgecheckt und gehe sie durch und kommentiere sie selbst. (Ich kann sie alle wieder ausziehen, wenn ich sie wieder einchecken will - oder sie drin lassen, wenn es niemandem etwas ausmacht.) Wenn ich dann wirklich nicht weiter sehen kann, kann ich jemanden fragen, hier, glaube ich das (was ich kommentiert habe), habe ich recht? Sie haben vielleicht das eigentliche Kommentieren durchgeführt, aber es ist erledigt und das ist der Punkt.

Dies ist mehr als nur eine persönliche Anfrage. Sie versuchen, Gewohnheiten / Kultur zu ändern, und das ist nicht einfach. Es ist sicherlich nicht etwas, das durch ein Flurgespräch oder eine E-Mail erreicht werden kann. Es wird einige Anstrengungen von Ihrer Seite erfordern.

Sei die Veränderung, die du in der Welt sehen möchtest.

Das Zitat kann fälschlicherweise Mahatma Gandhi zugeschrieben werden, aber es ist ein anwendbarer Ratschlag. Schreiben Sie beim Herausfinden der Codebasis die Kommentare, die Sie gerne gesehen hätten, so gut es geht, und legen Sie sie fest, nachdem Sie von Ihrem Chef überprüft wurden. Vorteile:

• Sie sind proaktiv, anstatt zu nörgeln.
• Sie geben ein gutes Beispiel. Im besten Fall wird Ihr Chef / Team die Vorteile erkennen und dem Beispiel folgen.
• In einigen Kommentaren steht wahrscheinlich /* Mystery parameter 3 */oder /* 2015-02-09 AidanQuinn: Is this code ever called? */-, dies ist eine Möglichkeit für Ihre Kollegen, entweder den Code richtig zu dokumentieren oder latente Fehler zu beheben.
• Wenn bei der Überprüfung vor dem Festschreiben festgestellt wird, dass ein von Ihnen geschriebener Kommentar ungenau ist, wissen Ihre Kollegen jetzt, dass der Code unklar war.

Unterlassen Sie dabei jegliches Umschreiben oder Refactoring, und die Einführung von Kommentaren sollte nahezu risikofrei sein. Wenn Sie etwas umschreiben, bewahren Sie diese Änderungen als separate Commits auf.

(Bevor Sie sich jedoch mit diesem Projekt befassen, stellen Sie sicher, dass Ihre Erwartungen an Kommentare angemessen sind. Wenn Ihre Vorstellung von gut kommentiertem Code nicht der Norm entspricht ( Beispiel 1 , Beispiel 2 ), werden Sie sich nur lächerlich machen dich selber.)

Ich würde nicht um zusätzliche Kommentare bitten, aber hier sind einige Ideen für Sie:

1. Vereinbaren Sie einen Termin mit Ihrem Chef und lassen Sie ihn den Code auf hoher Ebene durchgehen. Dies sollte Ihnen den Einstieg erleichtern. Ich würde ein paar Stunden bis vielleicht einen halben Tag einplanen, damit Sie sich auf den neuesten Stand bringen können. Dies sollte das Gesamtdesign, die verwendeten Muster usw. umfassen.
2. Erstellen Sie ein Testprojekt und schreiben Sie Komponententests für den Code. Auf diese Weise können Sie den Code besser verstehen, ohne ihn zu beeinflussen. Möglicherweise finden Sie auch einige Bugs!
3. Debuggen Sie den Code nach Bedarf, um bestimmte Bereiche zu verstehen.
4. Nehmen Sie eine Verbesserung oder einen Fehler aus dem Rückstand und arbeiten Sie daran.

Kommentare sind in Ordnung, aber wenn der Code einfach geschrieben ist, sollte er nach ein paar Tagen verständlich sein.

Erwarten Sie auch nicht, dass Sie alles verstehen. Es ist besser, sich zuerst auf wichtige Bereiche zu konzentrieren und dann das Code-Basiswissen nach Bedarf zu erweitern.

Ich war vor ungefähr einem Jahr in einer sehr ähnlichen Situation wie Sie. Ich fing an, mit wenig Programmiererfahrung zu arbeiten (obwohl ich ein bisschen OO und ein paar andere Sprachen kannte) und die eine Person, die mich unterrichtete, hatte sehr wenig Zeit. Er war immer hilfsbereit, aber ich hatte das Gefühl, dass ich nicht jede einzelne Frage stellen wollte, die ich hatte.

Andere haben hier bereits äußerst hilfreiche Vorschläge gemacht (z. B. Unit-Tests schreiben, aber aus eigener Erfahrung wäre das für mich von Grund auf zu weit gegangen oder Teile des Codes selbst zu kommentieren, aber das könnte sein Je nach erstem Punkt / Frage, die ich Ihnen in einer Minute stelle, wird es schwierig. Die folgenden Punkte fassen zusammen, was ich getan habe und was mir geholfen hat, aber es hängt sehr davon ab, wo genau Ihre Probleme liegen.

Außerdem muss ich @AK_ zustimmen, der sagte, dass Sie in C # keine Kommentare wirklich brauchen. Das mag nicht 100% richtig sein (ich glaube, es gibt Bereiche, in denen Kommentare definitiv helfen, z. B. reflexionsintensiver Code), aber im Wesentlichen ist es das. Wenn Sie wirklich "sauberen Code" mit gut benannten Methoden und Variablen schreiben und viele kleine "Bites" des Codes haben, sind sie fast völlig unnötig. Jedes Mal, wenn ich beim Lesen von Code das Bedürfnis nach Kommentaren verspürte, war ich, nachdem ich verstanden hatte, was er tat, sehr unzufrieden mit der Art und Weise, wie er gemacht wurde, und dachte, es hätte durch gutes Refactoring viel klarer werden können. Bearbeiten: Ich spreche hier speziell von C # -Kommentaren , nicht von Dokumentation (sei es separate Dokumentation oder XML-Kommentare), da ich denke, dass Dokumentation immer wichtig ist.

• Identifizieren Sie, was genau Ihre Probleme sind und ob Sie sie kategorisieren können. Das heißt, haben Sie immer noch Probleme mit der Sprache selbst oder verstehen eine bestimmte Syntax nicht (z. B. Lambda-Ausdrücke und LINQ im Allgemeinen oder Reflection)? Wenn Sie Codezeilen nicht verstehen, werden Sie nicht verstehen, was die gesamte Methode / der gesamte Block bewirkt. Es ist daher schwierig, sie selbst zu kommentieren. Holen Sie sich lieber ein gutes Buch ("C # in a Nutshell" war es für mich, aber ich habe gehört, dass "C # in Depth" auch spektakulär ist) und informieren Sie sich über die Dinge, denen Sie begegnen. Das vorherige Kategorisieren dieser Probleme erleichtert dies, da Sie "größere Lücken" sofort schließen oder sogar Ihren Chef danach fragen können, da nicht mehr viele Fragen gestellt werden, sondern nur ein einzelnes Thema oder die am häufigsten verwendeten Konstrukte erläutert werden kann einen enormen "Schub" bekommen

• Parallel dazu habe ich versucht, mich mit 'Clean Coding' und Best Practices (nicht sprachspezifisch) vertraut zu machen. Der Effekt ist vielleicht nicht sofort zu spüren, aber er wird sich früher oder später auszahlen, entweder wenn Sie vorhandene Sachen erweitern müssen oder wenn Sie sich fragen, warum jemand so viele kleine Methoden erstellt hat, anstatt eine, in der alles enthalten ist ;-)

• Machen Sie sich mit gängigen Entwurfsmustern vertraut. Möglicherweise erscheinen sie hier und da in dem Code, den Sie lesen, und wenn Sie sie erkennen, erhalten Sie sofort einen a-ha-Moment. Selbst wenn Sie verstehen, was der Code, den Sie dort sehen, bewirkt, dass Sie sich fragen, warum dies so gemacht wird, und es ist oft nicht so einfach, dies selbst herauszufinden.

Bitte nehmen Sie den obigen Text nicht als Voraussetzung für Ihre 'Fähigkeiten', ich wechsle oft versehentlich zwischen dem Sprechen über meine Erfahrungen und dem Sprechen mit Ihnen. Es ist meistens so gemeint, wie ich es erlebt habe und was ich getan habe . Wie andere gesagt haben, kann dies eine sehr gute Erfahrung sein, und es ist so ziemlich der Standard bei der Arbeit, Code zu lesen, der nicht Ihr eigener ist und von dem Sie vorher nicht viel wissen. Aber es kann wirklich befriedigend sein, endlich zu begreifen, was dort vor sich geht, und zu erkennen, dass Sie in dieser speziellen Fähigkeit besser werden. Nutzen Sie diese Gelegenheit, um in kürzester Zeit viel zu lernen, viel Glück! :)

Sie werden ihn wahrscheinlich nicht dazu bringen, seinen Stil zu ändern.

Was Sie tun können, ist, viele Fragen zu stellen und die Antworten aufzuschreiben.

Ich habe bei meinem letzten Job eine riesige Codebasis, wenig Dokumentation und ein paar Kommentare geerbt. Also würde ich eine halbe Stunde lang das gleiche Problem versuchen. Wenn ich es immer noch nicht herausfinden könnte, würde ich jemanden fragen, der es entweder geschrieben hat oder wusste, wie man es benutzt. Dann würde ich alle Dinge dokumentieren, die er mir erzählte. Die meisten gingen in unsere Dokumentation ein, einige gingen als Kommentare in den Code ein. Nach einem Jahr dort hatte ich praktisch einen großen Teil unserer Dokumentation geschrieben und wusste viel über die Codebasis.

Viel Glück!

Ich hatte das gleiche Problem. Ich bin ein Schüler von Phyzist und habe gute Programmiererfahrung. Ich habe in vielen Sprachen programmiert, aber nichts für Premium-Anwendungen.

Ich habe mich für eine Stelle als Webentwickler beworben und sie haben mich sofort zum Back-End der Webprogrammierung gebracht. Als der Chef mir die Basis-API für die Knoten-REST-Anwendung zeigte, dachte ich, dass ich sie rauswerfen würde. Ich habe noch nie Funktionen mit Callback und so komischer Syntax gesehen. Und ich frage meinen Chef, ob ich ein Problem habe, wenn ich nichts im Code verstehe. Er ist traurig, nein, er ist traurig, dass ich einen Monat Zeit habe, um es herauszufinden, und in der Zwischenzeit werde ich ein CMS erstellen, um mich mit einem anderen Frontender zu testen.

Nun, und ich habe zu der Zeit eine Codezeile gelesen und alles googelt, was ich nicht wusste. So war 1 Woche vergangen und ich war mit dem Code so vertraut, dass ich mit Front-Ender zusammenarbeiten konnte. Mein Code am Anfang war Mist, aber seht mich 3 Monate danach! Ich programmiere besser und schneller als unser Software-Architekt!

Ich empfehle, dass Sie nie aufhören zu lernen! Mein moto -> Lerne weiter und bleib ruhig :) Hänge nicht vom Chef ab, sei unabhängig und frage ihn direkt, sondern nur die schwierigsten Probleme. Weil Sie glücklich sein werden, nachdem Sie es durch Ihre eigene Forschung herausgefunden haben. Und denken Sie daran, wenn Sie aufhören, etwas Falsches zu lernen, lernen Sie jeden Tag, wie man ein guter Programmierer ist.

Wenn Sie vom Chef lernen, werden Sie nie besser als er sein, setzen Sie Ihren eigenen Standard, lernen Sie blindes Tippen, VIM oder VIM-Plugin für Ihre IDE, Linux wmii, damit Sie eines Tages über den Chef hinausgehen und besser als er sein können!

Als 20-jähriger Software-Ingenieur, der hauptsächlich an sicherheitsrelevanten Themen (SF-PD) arbeitet, muss ich sagen, dass Ihr Chef möglicherweise nicht die Person ist, die Sie als Vorbild haben möchten. Das Fehlen von Kommentaren ist entweder ein Zeichen für einen autodidaktischen Amateur-Programmierer, der nie gelernt hat, wie man den Job richtig macht, oder für einen unerfahrenen Ingenieur. Oder vielleicht ein Ingenieur, der einfach keine Zeit hat - Termine und Zweckmäßigkeit können schreckliche Dinge mit Ihrem Code anstellen! ;) Es ist definitiv ein Anti-Pattern für jeden kompetenten Softwareentwickler.

Ihr Chef ist vielleicht ein sehr guter Programmierer, aber es hört sich so an, als wäre er kein guter Softwareingenieur. Ein Ingenieur nutzt kollektive Gruppenerfahrung, um die Fallstricke zu vermeiden, von denen bereits andere Personen erfasst wurden. Effektives Kommentieren ist Teil dieser kollektiven Gruppenerfahrung für Software, ebenso wie die Spannungsanalyse Teil der kollektiven Gruppenerfahrung für den Maschinenbau ist. Was als effektives Kommentieren gilt, ist jedoch flüssiger und es ist definitiv etwas, was Sie aus Erfahrung erhalten.

Das Grundlegendste ist, dass Kommentare nicht sagen sollten, was eine Codezeile tut. Es gibt Zeiten, in denen Kommentare zur Funktionsweise überflüssig sind (insbesondere in C #). Überkommentare können genauso unwirksam sein (und ein Hinweis auf mangelnde Erfahrung), da Sie die wichtigen Dinge in der Krätze nicht finden können. Als Anfänger arbeiten Sie möglicherweise noch daran, das "Was" des Codes herauszufinden, und dafür müssen Sie nur lesen und verstehen, was er getan hat.

Das Wichtigste für Kommentare ist jedoch, dass sie sagen, WARUM eine Codezeile oder eine Funktion das tut, was sie tut, wo dies möglicherweise nicht offensichtlich ist. Müssen Sie Modul X vor Modul Y einrichten? Ist es wichtig, einen Rückkehrcode zu überprüfen, um festzustellen, ob eine Datei bereits geöffnet war, oder ignorieren wir den Rückkehrcode bewusst, weil dieser an einer anderen Stelle überprüft wurde? Das "Warum" des Codes wird für jeden relevant sein, unabhängig von seiner Erfahrung - und es wird auch für ihn in 6 Monaten relevant sein, wenn er den guten Grund für eine bestimmte Vorgehensweise vergessen hat. Kommentieren ist nicht nur etwas für andere, sondern auch für die Zukunft.

Wenn Sie Ihren Chef nicht verärgern möchten, stellen Sie kluge Fragen. Konzentrieren Sie sich darauf, nach dem "Warum" zu fragen, und versuchen Sie, das "Was" selbst herauszufinden (es sei denn, es ist wirklich dunkel). Kein guter Chef hat etwas dagegen, wenn ihm Fragen gestellt werden, die Sie von R-ing TFM nicht hätten finden können. Und es wird keinem guten Ingenieur etwas ausmachen, wenn er gebeten wird, etwas zu tun, das das Leben eines anderen Ingenieurs bei geringen Kosten erheblich erleichtert. (Bitten Sie ihn nur nicht, Kommentare zur gesamten Codebasis zu ergänzen!)

Ich würde sagen, ich war in einer ähnlichen Situation

1. Ihr Chef möchte vielleicht, dass Sie den schmutzigen Weg erlernen (indem Sie den Code durchgehen, von dem Sie keine Ahnung haben), und zwar aus einem bestimmten Grund. Auf diese Weise lernen wir mehr in einem Monat auf der Arbeit als in einem Jahr am College, wie in anderen Antworten erwähnt.

2. Dies ist "die Norm", wie in anderen Antworten erwähnt. Sie sollten sich mehr Gedanken darüber machen, wo Sie anfangen und wie Sie vorgehen und worauf Sie sich konzentrieren sollten, als zu versuchen, jede Codezeile sofort zu verstehen. Fragen Sie Ihren Chef nach den richtigen Tools und Möglichkeiten zum Debuggen / Durchlaufen des Codes. Diese Art von Fragen verschafft Ihnen einige Punkte.

3. Wenden Sie sich regelmäßig an Ihren Chef, um Feedback zu erhalten, wie es Ihnen geht, damit Sie eine Vorstellung davon bekommen, wo Sie prozentual stehen, vorausgesetzt, Ihr Chef hat eine gute Anzahl von Menschen in der gleichen Situation gesehen und eine Vorstellung davon, wie sie es gemacht haben.

4. Nehmen Sie dies zum Anlass und wenn Sie den Code besser verstehen, fügen Sie immer wieder Kommentare hinzu, von denen Sie ursprünglich erwartet hatten, dass sie Ihren Chef fragen.

Wenn Sie wirklich versuchen möchten, ihn zu bitten, Kommentare in seinen Code einzufügen (ich empfehle es nicht), würde ich vorschlagen, Code zu finden, den Sie bearbeiten müssen, der wirklich einige Kommentare gebrauchen könnte (die meisten sind selbsterklärend) und die Frage zu stellen "Ich habe mir diesen Code hier angesehen und habe versucht, [Problem, das Sie haben] herauszufinden, und ich konnte keine Kommentare finden, um ihn zu erklären." Versuchen Sie im Grunde zu zeigen, dass Sie sich bemüht haben, es zu verstehen, und erklären Sie, warum Sie beide von Kommentaren profitieren könnten.

Wahrscheinlich benötigen 90% des gut geschriebenen Codes keine Kommentare. Sie wollen nur wirklich die Teile des Codes dokumentieren, die optimiert und ziemlich angespannt wurden. Ich habe einmal in einem Unternehmen gearbeitet, in dem Sie alle von Ihnen geänderten Code-Teile dokumentieren mussten. Die Kommentare waren letztendlich für die Lesbarkeit des Codes nachteilig, da sie sich oft auf Code bezogen, der bis zur Unkenntlichkeit entfernt oder geändert wurde. Vorsicht vor schlechten Kommentaren Ich verbrachte eine Woche damit, eine Funktion zu debuggen, und am Ende stellte ich fest, dass der Kommentar, den ich über das Setzen eines solchen und eines solchen Flags auf "falsch" las, tatsächlich das ganze Problem war, bei dem ich das Flag auf "wahr" setzte und alles funktionierte wie es sollte.

Wenn Sie Kommentare im Code wünschen, um zu verstehen, warum etwas geschrieben wurde, dann verstehen Sie höchstwahrscheinlich (wenn Sie neu sind) die geschäftlichen Anforderungen noch nicht. Ich bin sicher, Sie kennen die gesamte Syntax und können Code lesen, aber wenn Sie den Zweck eines Codes nicht kennen, werden Sie sich ein bisschen verloren fühlen.

Eine Sache, die mir einfällt, ist die Paarprogrammierung. Sie sagen, Ihr Chef ist beeindruckt von Ihren Fortschritten, also können Sie vorschlagen, mit ihm zusammenzuarbeiten. Dies wird Ihnen beiden langfristig helfen. Ihr Chef muss Ihnen dann erklären, was für ihn selbstverständlich ist, und Sie erfahren mehr über das Geschäft.

Wie andere bereits erwähnt haben, ist dies durchaus üblich, aber das bedeutet nicht, dass Sie es einfach aufsaugen und durchpflügen müssen. Sie müssen nicht so viel Code in der Tiefe verstehen, wie Sie denken, und es gibt konkrete Strategien, um das "tiefe Ende" viel flacher zu machen:

• Suchen Sie im Code etwas, das sich auf die jeweilige Aufgabe bezieht. Normalerweise ist die Suche am einfachsten, wenn ein Benutzer sichtbar ist, z. B. die Beschriftung der Schaltfläche auf der Benutzeroberfläche. Schreiben Sie auf, wo Sie es gefunden haben. Dies wird Ihr Ankerpunkt sein.
• Suchen Sie nun einen Schritt weiter nach Code und notieren Sie sich diesen. Wer erstellt den Button? Welcher Code wird aufgerufen, wenn auf die Schaltfläche geklickt wird?
• Die Quellcodeverwaltung ist häufig hilfreich, um Code zu finden, der nur einen Schritt entfernt ist. Finden Sie heraus, wann der von Ihnen angezeigte Code hinzugefügt oder geändert wurde, und prüfen Sie, was zur gleichen Zeit noch eingecheckt wurde und warum.
• Wiederholen Sie diesen Vorgang, bis Sie gerade genug verstanden haben, um Änderungen vorzunehmen, und eine Ebene tiefer, um sicherzustellen, dass Ihnen nichts entgeht.
• Wenn Sie irgendwann nicht weiterkommen, müssen Sie jetzt eine ganz bestimmte Frage stellen. Beispiel: "Ich kann nicht herausfinden, woher diese Schaltfläche stammt."

Hier sind meine $ 0,02 in der Sache. Ich schlage keine exklusive Antwort vor, vieles, was hier gesagt wurde, ist ziemlich relevant.

Ich würde ein bisschen Social Engineering versuchen, um die Dinge so zu arrangieren, dass Ihr Chef es einfacher / weniger zeitaufwendig findet, einen Teil seines Codes zu kommentieren, als nicht.

Nun, das kann ziemlich einfach sein, wenn Sie bereit wären, ein großes Risiko einzugehen und ihn zu ärgern - aber das wollen wir nicht. (Randnotiz: Sie könnten einfach nicht in der Lage sein, irgendetwas zu tun, ohne dass er es aufschreibt oder Ihnen Kommentare diktiert. Sie bestehen darauf und belästigen ihn endlos.)

Was ist dann die Alternative? Ein paar Ideen, je nach Umstand.

Option 1

1. Nehmen Sie sich Zeit, um einen Teil seines Codes als X zu verstehen.
2. Überlegen Sie sich jetzt einen vernünftigen Weg, wie Sie es missverstehen können.
3. Sagen Sie dem Chef (per E-Mail oder sagen Sie beim Frühstück oder was nicht), dass Sie gerade versuchen, es herauszufinden.
4. Fügen Sie einen Kommentar hinzu, der besagt, dass nicht klar ist, was der Code bedeutet, aber Sie verstehen ihn als Y; versuche diesen Kommentar für ihn sichtbar zu machen - aber versuche es nicht zu sehr!
5. Handeln Sie unter der Annahme von Y - und stellen Sie sicher , dass Ihr Chef Ihre Handlung bemerkt (damit Sie Ihre Zeitarbeit nicht lange mit einer falschen Annahme verschwenden).
6. Chef sollte die Initiative ergreifen, um Sie zu korrigieren. Sagen Sie ihm an dieser Stelle etwas wie "Ich wünschte wirklich, dieser Code hätte ein paar Kommentare, um zu verhindern, dass ich die falsche Annahme mache. Ich werde den von mir hinzugefügten Kommentar korrigieren. Nehmen Sie an, Sie könnten mir mit einer allgemeinen Beschreibung helfen." Ich bin nicht erfahren genug, um die genaue Absicht herauszufinden, und ich bin nur ein paar Sätze, die den Trick machen würden. " Oder so..

Option 2

Du bist im Training. Versuchen Sie, mit ihm ein (zusätzliches?) Wöchentliches Treffen mit fester Häufigkeit zu vereinbaren. Sehen Sie sich in diesem Meeting einen Code an - aber Sie müssen so vorbereitet sein, dass er nicht jede einzelne Zeile erklären muss. Irgendwann - hoffentlich - wird ihm klar, dass er die Besprechung überspringen kann, wenn er nur die Kommentare hinzufügt.

Option 3

Lassen Sie einen anderen Mitarbeiter denselben Code wie Sie nicht verstehen. Sie beide treten zu unterschiedlichen Zeiten an den Chef heran und stellen die gleichen Fragen. Das ist ein sicherer Weg, um ihm klar zu machen, dass er etwas versäumt ... aber nicht jeder hat den Luxus hilfsbereiter Mitarbeiter im selben Projekt.

Also nur etwas, das mir hilft, bis ich die Dinge in den Griff bekomme. Wie kann ich meinen Chef bitten, Kommentare in seinen Code zu schreiben, den er mir gibt, aber höflich?

Wenn Sie den Code nicht verstehen können, warum sind die Kommentare Ihrer Meinung nach Ihre Lösung?

Ich kenne seinen Programmierstil nicht, aber ich gebe zu, dass es sehr schwer ist, einen Code zu verstehen, wenn der Name von Funktionen und Variablen irreführend ist. Aber wenn Namen und Funktionen oder sogar die Organisation des Programms (Klassen, Methoden, Eigenschaften ...) so sind, dass der Code verständlich ist, spricht der Code tatsächlich von selbst mit Ihnen.

Sie sollten ihn nach der Programmarchitektur fragen, und wenn Sie ihn nach etwas fragen möchten, fragen Sie nach aussagekräftigeren Namen für Funktionen. das ist bequemer für ihn zu tun.

Auch wenn es eine Möglichkeit gibt, dies höflich zu erfragen, gibt es zwei Möglichkeiten, wie Ihr Chef Kommentare in seinem Code beurteilt:

1. Entweder wären diese Kommentare in seinem Code eine gute Sache, oder

2. Diese Kommentare in seinem Code wären nicht gut zu haben.

Wenn Ihr Chef der Meinung ist, dass Kommentare in seinem Code keine gute Sache sind (und es gibt dafür sehr gute Argumente, dh der Code soll die Dokumentation sein , und keine Dokumentation wird jemals etwas so genau und so eindeutig festlegen als code, der es tatsächlich tut , passiert dann nichts.

Wenn Ihr Chef nun zufällig der Meinung ist, dass Kommentare in seinem Code eine gute Sache sind, besteht eine beträchtliche Chance, dass er Sie auffordert, seinen Code zu studieren, seine Funktionsweise zu verstehen und Kommentare zu seinem Code hinzuzufügen Code dich . (Auch dafür gibt es sehr gute Argumente, dh Sie müssen lernen , und seine Zeit ist per Definition viel wertvoller als Ihre .)

Wenn Sie nicht bereit sind, dies zu tun, ist es möglicherweise besser, nichts zu sagen.