it-swarm.com.de

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, also hat er mich ausgewählt, um mich in dem zu schulen, worauf sich das Unternehmen spezialisiert hat) und begann mit ASP.NET MVC zu arbeiten = Anwendungen, etwas HTML und CSS. Ich bin in Ordnung 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. (Wir verwenden die Quellcodeverwaltung in Visual Studio 201 ), also sind es buchstäblich Hunderte von Codezeilen, ohne Hintergrundinformationen darüber, was sie tun sollen. Die Art von Code, die ich sehe, ist Code, den ich noch nie gesehen habe, daher ist es wirklich schwierig, es herauszufinden.

Ich würde versuchen, ihm weitere Fragen zu stellen, aber er arbeitet immer (es ist seine Sache), und ich habe das Gefühl, dass er sich über alle ärgern könnte Diese Fragen habe ich in meinen Händen.

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

72
Aidan Quinn

Du bist am "tiefen Ende" und meiner Meinung nach ist das der beste Weg zu lernen. Nicht weil Sie sich Dinge ansehen, von denen Sie keine Ahnung haben, sondern weil Sie dadurch gezwungen sind, einfallsreicher zu sein und herauszufinden, welche Komponenten welche Rolle in einem System spielen, für das Sie neu sind.

Es hilft nicht, dass Ihr Chef zu beschäftigt ist, um mit jemandem umzugehen, der neugierig ist (und Sie haben das Recht, neugierig zu sein; Sie möchten unbedingt lernen, was gut ist). Leider kommt es möglicherweise nicht gut an, wenn Sie Ihren Senior bitten, seinen Stil und seine Herangehensweise zu ändern, um zu lernen, insbesondere weil Sie 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 unbedingt um Kommentare bitten müssen, um zu lernen, während Sie neu darin sind, erklären Sie vielleicht, warum. Erklären Sie, dass Sie ihn nicht mit Fragen belästigen möchten, da er oft beschäftigt ist. Dies wird nicht nur viel weniger rüberkommen, als wenn Sie ihm sagen, dass er etwas tun soll, sondern es öffnet auch das Wort für Diskussionen darüber, wie er es vorziehen könnte, die Zeit für Fragen beiseite zu legen.

130
JᴀʏMᴇᴇ

Erstens ist das Kriechen durch Tausende von Zeilen unbekannten Codes und das Gefühl verloren zu sein, wie jedes Softwareprojekt von Anfang an überall ist.

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 Stück Code verständlich. Viele Menschen sind frustriert, wenn sie nicht innerhalb weniger Minuten etwas herausfinden können. Sei geduldiger als das.

  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 verwirrtes Gespräch niemals beenden.

  4. Ihr Chef ist ein besserer Programmierer als Sie. (Wahrscheinlich.) Das heißt nicht, 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 viel Erfahrung haben.

  5. Wenn Sie sicher sind, dass weitere Kommentare den Code erheblich verbessern würden, fragen Sie Ihren Chef. "Es ist schwierig für mich zu verstehen, was an einigen Stellen vor sich geht. Wenn ich etwas 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, dies gefragt zu haben und denken: "Huh, ich frage mich, womit ich ein Problem hatte? Das ist nicht so schlimm. Hm, na ja, egal."

75
Paul Draper

Wenn Ihr Chef keine Zeit hat, alle Ihre Fragen zu beantworten, warum hat er dann wohl Zeit, seinen alten Code zu kommentieren? Und was lässt Sie darüber hinaus denken, dass seine Kommentare wirklich die Teile beschreiben würden, die Sie im Moment nicht verstehen? Meiner Erfahrung nach wird der Versuch, den Programmierstil Ihres Chefs zu ändern, indem Sie ihn nur fragen, nicht funktionieren, höflich oder nicht.

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 zu erledigen selbst - wenn Sie diese Teile verstanden haben, natürlich und nachdem Sie eine Zusage von erhalten haben Ihr Chef, dass dies in Ordnung sein wird. Wenn Sie oder Ihr Chef befürchten, dass Sie durch Hinzufügen von Kommentaren etwas kaputt machen könnten, 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 Trunk übernommen werden. Da Ihr Chef nur über ein begrenztes Zeitbudget verfügt, versuchen Sie, selbst herauszufinden, was ein bestimmter Teil zuerst tut, indem Sie eine angemessene Menge Zeit investieren. Wenn Sie wirklich stecken bleiben, schreiben Sie Ihre Frage auf eine Liste und fragen Sie Ihren Chef zum Beispiel einmal am Tag, anstatt ihn 30 Minuten lang zu stören. Meiner Erfahrung nach funktioniert dieser Ansatz bei 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 erhalten Sie sicher die Kommentare, die Sie benötigen, und Ihr Chef wird sehen, wo Sie zusätzliche Informationen benötigen und ob Sie alles richtig gemacht 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, die dies tun, Vorteile bringt muss sich mit dem Code befassen, einschließlich Ihres Chefs.

18
Doc Brown

Lassen Sie sich zunächst ein Beispiel geben, um Ihren Code richtig zu kommentieren, Grasshopper!

Dann muss ich das die ganze Zeit machen. 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 werde - oder sie lassen, wenn es niemandem etwas ausmacht.) Wenn ich dann wirklich nicht weiter sehen kann, kann ich jemanden fragen, hier denke ich, dass es das tut das (was ich kommentiert habe), habe ich recht? Sie haben vielleicht das eigentliche Kommentieren gemacht, aber es ist geschafft und das ist der Punkt.

8
RedSonja

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 hohem Niveau durchgehen. Damit sollten Sie loslegen. Ich würde ein paar Stunden bis vielleicht einen halben Tag erwarten, 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. Dies hilft Ihnen, ihn zu verstehen, ohne ihn zu beeinflussen. Möglicherweise finden Sie auch einige Fehler!
  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 direkt geschrieben ist, sollte er nach einigen Tagen verständlich sein.

Erwarten Sie auch nicht, alles zu verstehen. Es ist besser, sich zuerst auf Schlüsselbereiche zu konzentrieren und dann das Wissen über die Codebasis nach Bedarf zu erweitern.

5
Jon Raynor

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 zutreffender Rat. Wenn Sie versuchen, die Codebasis zu rätseln, schreiben Sie die Kommentare, die Sie gerne gesehen hätten , nach besten Kräften und legen Sie sie anschließend fest von Ihrem Chef überprüft werden. Vorteile:

  • Sie sind proaktiv, anstatt zu nörgeln.
  • Sie geben ein gutes Beispiel. Im besten Fall wird Ihr Chef/Team die Vorteile erkennen und nachziehen.
  • In einigen Kommentaren heißt es wahrscheinlich /* Mystery parameter 3 */ Oder /* 2015-02-09 AidanQuinn: Is this code ever called? */ - dies sind Möglichkeiten für Ihre Kollegen, den Code entweder ordnungsgemäß 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 Umgestalten, und die Einführung von Kommentaren sollte nahezu risikofrei sein. Wenn Sie etwas neu schreiben, behalten Sie diese Änderungen als separate Commits bei.

(Bevor Sie jedoch mit diesem Projekt beginnen, stellen Sie sicher, dass Ihre Erwartungen an Kommentare angemessen sind. Wenn Ihre Vorstellung von gut kommentiertem Code außerhalb der Norm liegt ( Beispiel 1 , Beispiel 2 ), dann machst du dich nur zum Narren.)

5
200_success

Ich war vor ungefähr einem Jahr in einer sehr ähnlichen Situation wie Sie. Ich begann mit wenig Programmiererfahrung zu arbeiten (obwohl ich ein bisschen OO und einige andere Sprachen am Anfang) kannte und die eine Person, die mich unterrichtete, sehr wenig Zeit hatte. Er war immer hilfreich, aber ich Ich hatte das Gefühl, ich würde nicht jede einzelne Frage stellen wollen, die ich hatte.

Andere haben hier bereits äußerst hilfreiche Dinge vorgeschlagen (z. B. Unit-Tests schreiben, aber aus eigener Erfahrung wäre das für mich von Grund auf ein bisschen zu weit gegangen, oder Teile des Codes selbst zu kommentieren, aber das kann sein je nach dem ersten Punkt/der ersten Frage, die ich Ihnen in einer Minute stellen werde, schwierig sein). 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 benötigen. Das ist möglicherweise nicht 100% korrekt (ich glaube, es gibt Bereiche, in denen Kommentare definitiv helfen, z. B. reflexionsintensiver Code), aber im Wesentlichen ist dies der Fall. Wenn Sie wirklich 'sauberen Code' mit gut benannten Methoden und Variablen schreiben und viele kleine 'Codebisse' haben, sind diese 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 es tat, sehr unzufrieden mit der Art und Weise, wie es gemacht wurde, und dachte, es hätte durch gutes Refactoring von Anfang an viel klarer sein 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. Haben Sie immer noch Probleme mit der Sprache selbst oder verstehen Sie 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 tut. Daher ist es 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 lesen Sie die Dinge nach, 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 es nicht mehr viele Fragen gibt, sondern ein einzelnes Thema oder die am häufigsten verwendeten Konstrukte erklären, damit Sie kann in diesem Bereich schnell einen enormen "Schub" bekommen.

  • Parallel dazu habe ich versucht, mich mit 'sauberer Codierung' und bewährten allgemeinen Praktiken (nicht sprachspezifisch) vertraut zu machen. Dies wirkt sich möglicherweise nicht sofort aus, zahlt sich jedoch früher oder später aus, entweder wenn Sie vorhandene Inhalte 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 Designmustern vertraut. Sie erscheinen möglicherweise 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, fragen Sie sich möglicherweise, warum dies so gemacht wird, und es ist oft nicht so einfach, dies selbst herauszufinden.

Bitte nehmen Sie den obigen Text nicht, wenn ich Annahmen über Ihre "Fähigkeiten" mache. Ich wechsle oft versehentlich zwischen "über meine Erfahrungen sprechen" und "mit Ihnen". Es ist meistens gemeint als was mir begegnet ist und was ich getan habe . Wie andere gesagt haben, kann dies eine sehr gute Erfahrung sein und es ist so ziemlich der Standard im Job, Code zu lesen, der nicht Ihr eigener ist und über den Sie vorher nicht viel wissen. Aber es kann wirklich befriedigend sein, endlich zu verstehen, was dort vor sich geht, und zu erkennen, dass Sie in dieser besonderen „Fähigkeit“ besser werden. Nutzen Sie diese Gelegenheit, um in kürzester Zeit ein viel zu lernen, viel Glück! :) :)

2
InvisiblePanda

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

Sie können viele Fragen stellen und die Antworten aufschreiben.

Ich habe bei meinem letzten Job eine riesige Codebasis geerbt, wenig Dokumentation und wenige Kommentare. Also würde ich eine halbe Stunde lang versuchen, dasselbe Problem zu lösen. 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, einige gingen als Kommentare in den Code. Nach einem Jahr dort hatte ich praktisch einen großen Teil unserer Dokumentation geschrieben und wusste viel über die Codebasis.

Viel Glück!

1
Joshua Dance

Ich hatte das gleiche Problem. Ich bin ein Student des Phyzisten und habe gute Programmiererfahrung. Ich habe in vielen Sprachen programmiert, aber nichts für Premium-Anwendungen.

Ich habe mich für einen Job als Webentwickler beworben und sie haben mich sofort in das Backend der Webprogrammierung versetzt. Als Boss mir die Basis-API für die Node REST -Anwendung) zeigte, dachte ich, ich würde sie rauswerfen. Ich habe noch nie Funktionen mit Rückruf und so seltsamer Syntax gesehen. Und ich frage meinen Boss, ob ich eine habe Problem Wenn ich nichts im Code verstehe, ist er traurig, nein, er ist traurig, dass ich 1 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 ging zu der Zeit 1 Codezeile und googelte alles, was ich nicht wusste. Es verging also eine Woche und ich war mit dem Code so vertraut, dass ich mit Front Ender zusammenarbeiten konnte. Mein Code am Anfang war Mist, aber se 3 Monate danach! Ich programmiere besser und schneller als unser Software-Architekt!

Ich schlage vor, dass Sie nie aufhören zu lernen! Mein Moto -> Lerne weiter und bleib ruhig :) Verlasse dich nicht darauf, dass der Chef unabhängig ist und frage ihn direkt, sondern nur die schwierigsten Probleme. Weil Sie glücklich sein werden, nachdem Sie es von Ihrem eigenen Forscher 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 Ihren eigenen Standard setzen, blindes Tippen lernen, VIM oder VIM Plugin für Ihre IDE, Linux wmii) Sie würden also eines Tages über den Chef hinausgehen und besser sein als er!

1
user157581

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

  • Suchen Sie etwas im Code für die jeweilige Aufgabe. Normalerweise ist die Suche nach etwas, das der Benutzer am einfachsten sieht, wie die Beschriftung der Schaltfläche auf der GUI. Schreiben Sie auf, wo Sie es gefunden haben. Dies wird Ihr Ankerpunkt sein.
  • Suchen Sie nun einen Schritt entfernt nach Code und schreiben Sie diesen auf. Wer erstellt den Button? Welcher Code wird aufgerufen, wenn auf die Schaltfläche geklickt wird?
  • Die Quellcodeverwaltung ist oft nützlich, um Code zu finden, der nur einen Schritt entfernt ist. Finden Sie heraus, wann der angezeigte Code hinzugefügt oder geändert wurde, und sehen Sie sich an, was zur gleichen Zeit noch eingecheckt wurde und warum.
  • Wiederholen Sie diesen Vorgang, bis Sie gerade genug verstanden haben, um Ihre Änderung vorzunehmen, und eine Ebene tiefer, um sicherzustellen, dass Sie nichts verpassen.
  • Wenn Sie irgendwann stecken bleiben, müssen Sie jetzt eine ganz bestimmte Frage stellen. Beispiel: "Ich kann nicht herausfinden, woher diese Schaltfläche instanziiert wird."
0
Karl Bielefeldt

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

  1. Ihr Chef möchte vielleicht, dass Sie aus einem bestimmten Grund den schmutzigen Weg lernen (indem Sie durch den Code gehen, von dem Sie keine Ahnung haben). Auf diese Weise lernen wir in einem Monat bei der Arbeit mehr 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 sollen, wie Sie vorgehen sollen und worauf Sie sich konzentrieren sollen, 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 bringt Ihnen einige Punkte.

  3. Wenden Sie sich regelmäßig an Ihren Chef, um Feedback zu Ihrer Vorgehensweise zu erhalten. So erhalten Sie eine Vorstellung davon, wo Sie in Perzentilen stehen, vorausgesetzt, Ihr Chef hat eine gute Anzahl von Personen in derselben Situation gesehen und hat eine Vorstellung davon, wie sie es getan haben.

  4. Nutzen Sie diese Gelegenheit und fügen Sie, wenn Sie den Code besser verstehen, immer wieder Kommentare hinzu, die Sie ursprünglich von Ihrem Chef erwartet hatten.

0
Jay D

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 suchen, den Sie bearbeiten müssen, der wirklich einige Kommentare verwenden könnte (die meisten sind selbsterklärend), und die Frage zu stellen wie folgt "Ich habe mir diesen Code hier angesehen und versuche herauszufinden, [Problem, das Sie haben], und ich konnte keine Kommentare finden, um ihn zu erklären." Versuchen Sie grundsätzlich zu zeigen, dass Sie sich bemüht haben, es zu verstehen, und erklären Sie, warum Sie beide von Kommentaren profitieren können.

Wahrscheinlich benötigen 90% des gut geschriebenen Codes keine Kommentare. Sie möchten wirklich nur die Teile des Codes dokumentieren, die optimiert und ziemlich angespannt wurden. Ich habe einmal in einem Unternehmen gearbeitet, in dem Sie jeden Code dokumentieren mussten, den Sie geändert haben. Grundsätzlich waren die Kommentare für die Lesbarkeit des Codes aktiv schädlich, da sie sich häufig auf Code bezogen, der bis zur Unkenntlichkeit entfernt oder geändert wurde. Vorsicht vor schlechten Kommentaren Ich habe eine Woche damit verbracht, eine Funktion zu debuggen, und am Ende stellte ich fest, dass der Kommentar, den ich immer wieder ü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.

0
dkippers

Selbst wenn es eine Möglichkeit gibt, dies höflich zu fragen, gibt es zwei Möglichkeiten, was Ihr Chef über Kommentare in seinem Code denken wird:

  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 sehr gute Argumente dafür, dh der Code soll die Dokumentation sein und keine Dokumentation wird jemals etwas so genau und eindeutig festlegen wie der Code, der es tatsächlich tut,) dann wird nichts passieren.

Wenn Ihr Chef zufällig der Meinung ist, dass Kommentare in seinem Code eine gute Sache sind, besteht eine beträchtliche Wahrscheinlichkeit, dass er Sie auffordert, seinen Code zu studieren, zu verstehen, wie er funktioniert, und Kommentare zu seinem Code hinzuzufügen Code du selbst. (Auch dafür gibt es sehr gute Argumente, d. H. 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.

0
Mike Nakis

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

Wenn Sie den Code nicht verstehen können, warum denken Sie, dass die Kommentare Ihre Lösung sind?

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

Fragen Sie ihn besser nach der Programmarchitektur, und wenn Sie ihn um etwas bitten möchten, fordern Sie aussagekräftigere Namen für Funktionen an. das ist bequemer für ihn.

0
Ahmad

Wenn Sie möchten, dass Kommentare im Code verstehen, warum etwas geschrieben wurde, 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 in den Sinn kommt, ist die Paarprogrammierung. Sie sagen, Ihr Chef ist von Ihren Fortschritten beeindruckt, und Sie könnten vorschlagen, mit ihm zusammenzuarbeiten. Dies wird Ihnen beiden auf lange Sicht helfen. Ihr Chef muss Dinge erklären, die er für selbstverständlich hält, und Sie erfahren mehr über das Geschäft.

0

Hier sind meine $ 0,02 zu diesem Thema. 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 zeitaufwändig findet, einen Teil seines Codes zu kommentieren, als dies nicht zu tun.

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 Ihnen Kommentare aufschreibt oder diktiert, Sie darauf bestehen und ihn endlos belästigen usw.)

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. Stellen Sie sich nun einen vernünftigen Weg vor, wie Y Missverständnis es.
  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; Versuchen Sie, diesen Kommentar für ihn sichtbar zu machen - aber versuchen Sie es nicht zu sehr!
  5. Handeln Sie unter der Annahme von Y - und stellen Sie sicher fest, dass Ihr Chef Ihre Handlung bemerkt (damit Sie Ihre Zeit nicht lange mit einer falschen Annahme verschwenden).
  6. Der 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 Kommentar, den ich für mich selbst hinzugefügt habe, korrigieren. Nehmen Sie an, Sie könnten mir mit einer allgemeinen Beschreibung helfen." von diesem und jenem Code? Ich bin nicht erfahren genug, um die genaue Absicht herauszufinden, und ich bin nur ein paar Sätze würden den Trick tun. " Oder so..

Option 2

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

Option 3

Lassen Sie einen anderen Mitarbeiter nicht denselben Code wie Sie verstehen. Sie beide treten zu unterschiedlichen Zeiten an den Chef heran und stellen dieselben Fragen. Das ist ein sicherer Weg, um ihm klar zu machen, dass er etwas nicht tut ... aber nicht jeder hat den Luxus, hilfsbereite Mitarbeiter am selben Projekt zu haben.

0
einpoklum

Als 20-jähriger Softwareentwickler, 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 ein Zeichen für einen autodidaktischen Amateur-Programmierer, der nie gelernt hat, wie man die Arbeit richtig macht, oder für einen unerfahrenen Ingenieur. Oder vielleicht ein Ingenieur, der einfach nicht die Zeit hat - Fristen und Zweckmäßigkeit können schreckliche Dinge mit Ihrem Code anstellen! ;) Es ist definitiv ein Anti-Pattern für jeden kompetenten Software-Ingenieur.

Ihr Chef ist vielleicht ein sehr guter Programmierer, aber es hört sich so an, als wäre er kein guter Softwareentwickler. Ein Ingenieur nutzt kollektive Gruppenerfahrung, um die Fallstricke zu vermeiden, die andere Menschen bereits entdeckt haben. 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 zählt, ist jedoch flüssiger und es ist definitiv etwas, was man aus Erfahrung bekommt.

Das Grundlegendste ist, dass Kommentare nicht sagen sollten, was eine Codezeile tut. Es gibt Zeiten, in denen Kommentare, die angeben, was eine Funktion tut, ebenfalls ü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 Wichtige für Kommentare ist jedoch, dass sie sagen WARUM eine Codezeile oder eine Funktion macht das, was sie macht, 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 vergessen hat, etwas auf eine bestimmte Weise zu tun. Das Kommentieren ist nicht nur für andere Menschen gedacht, sondern auch, um Ihnen in Zukunft zu helfen.

Wenn Sie Ihren Chef nicht nerven 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). Es wird keinem guten Chef etwas ausmachen, Fragen zu stellen, wenn dies nicht die Art von Dingen ist, die Sie von R-ing TFM hätten finden können. Und es wird keinem guten Ingenieur etwas ausmachen, gebeten zu werden, etwas zu tun, das das Leben eines anderen Ingenieurs erheblich erleichtert, und das zu geringen Kosten für ihn. (Bitten Sie ihn nur nicht, Kommentare zur gesamten Codebasis nachzufüllen !;)

0
Graham Bartlett