Ich bin ein Technical Support Engineer, der kürzlich entdeckt hat, wie viel Spaß Programmieren sein kann. Mein Chef bemerkte dieses Interesse und schlug vor, dass ich Ruby als erste Sprache lernen sollte, da das Unternehmen davon profitieren kann, es hat eine sehr elegante Syntax, und wir brauchen nicht mehr Java / C / C ++ - Programmierer.
Nun, ich habe mein erstes ziemlich großes Ruby-Skript geschrieben, das im Wesentlichen ein automatisierter Frontend-Client für unser Webanwendungsprodukt ist. Das Skript funktioniert .. Aber da es meine erste vollständige Anwendung ist, bin ich mir sicher, dass es viele Bugs gibt (die ich langsam quetsche), und ich bin mir sicher, dass ich es nicht so geschrieben habe, wie es geschrieben werden könnte.
Jetzt möchte mein Chef einen Code-Review machen - er ist Java-Programmierer und kennt überhaupt keinen Ruby. Er gibt zu, dass er Code-Reviews immer hasste, aber es ist ein notwendiges Übel.
Meine Frage ist:
Kann ein Programmierer, der in einer Sprache schreibt, einen hilfreichen / konstruktiven Code-Review einer anderen Sprache durchführen, von der er keine Kenntnis hat?
Die letzte Kritik, die wir hatten, war schrecklich, ich musste aus dem Gebäude gehen - weil seine Kritik mich nicht wirklich in irgendeine Richtung gelenkt hat, weil er keine spezifischen / besseren Wege vorschlug Dinge richtig zu machen "Ruby Weg".
Ich glaube nicht, aus genau den Gründen, auf die Sie am Ende Ihrer Frage hinweisen. Jemand, der Ruby nicht programmiert, wird Ihnen nicht im richtigen Ruby-Stil Ratschläge geben können. Am Ende schreibst du Java in Ruby.
Er könnte Ihnen vielleicht gute allgemeine Ratschläge zur Softwareentwicklung geben, aber ich glaube nicht, dass dies wirklich eine Code Überprüfung ist.
Nun, es gibt mehrere "Code-Gerüche", die ein erfahrener Programmierer selbst ohne Vorkenntnisse in der Sprache direkt bemerken kann. Dinge im Zusammenhang mit Software-Engineering im Allgemeinen. Aber wenn es um Ruby geht, vermute ich, dass er eine nützliche Syntaxüberprüfung geben kann, wenn er nie funktionale Programmierung vor oder zumindest etwas Code in modernen Sprachen wie Ruby wie Groovy, Scala oder Python gemacht hat.
Ein Code-Review von einem Nicht-Ruby-Ist könnte nützlich sein. Wie Sie sich selbst als Anfänger beschreiben, gibt es wahrscheinlich einige allgemeine, sprachunabhängige Software-Design-Prinzipien, die Ihnen nützlich sein werden ("Code Smells"). Ein paar Dinge von ganz oben -
Dies sind alles Dinge der "allgemeinen Praxis", aber auf lange Sicht wahrscheinlich wichtiger als die sprachspezifische Syntax.
Es gibt natürlich Dinge, die sich nicht so gut übersetzen lassen, z.B. Wegen Mixins gibt es viele Dinge, die Sie in Bezug auf Vererbung anders machen. Ein Java-Programmierer wird wahrscheinlich auch mit den Unterschieden beim Tippen unbehaglich sein.
Kann ein Programmierer, der in einer Sprache schreibt, effektiv einen hilfreichen / konstruktiven Code-Review einer anderen Sprache durchführen, von der er keine Kenntnis hat?
Ich denke schon, aber rate mal, es kommt auf den Programmierer an.
Er kann Fragen stellen wie:
Ein Grund für eine Codeüberprüfung könnte sein, dem Überprüfer zu helfen, zum Beispiel, wenn Sie nicht erreichbar sind und er für den Code verantwortlich sein muss; Manchmal ist die Richtung des Wissenstransfers von dir zu ihm und nicht nur von ihm zu dir.
Wenn er jedoch "Code-Reviews immer hasste", ist das ein Symptom, dass er / Sie es nicht richtig macht: und vielleicht sollte er / Sie mehr darüber herausfinden, wie man einen Code-Review erfolgreicher macht.
>Ich werde das als Code-Review diskutieren, der auch mit der Code-Inspektion zusammenhängt: Entwickler und Rezensent (e) sitzen im Raum und gehen über den Code. Ignoriere die Bits, die für deine Situation nicht relevant sind.
Versuchen Sie nicht, an eine Code-Überprüfung als Kritik an Ihrem Code zu denken. Wenn es so wird, machen sie es falsch.
Die Strategie sollte sein, dass sie durch den Code gehen und erklären, was sie tun. Wenn Sie falsch verstanden werden, können Sie anhalten oder erklären. Alle erkannten Probleme oder Probleme können kurz diskutiert und entweder als Fehler, Code-Kommentar (nicht sauber, geschweifte Klammern usw.) oder als Aktion - etwas, das untersucht werden soll - aufgeführt werden.
Beachten Sie, dass keines davon Kritikpunkte sind. Sie arbeiten alle für die gleiche Firma. Ihr Code wird zu ihrem Code und umgekehrt (wenn sie Code schreiben). Ziel ist es, a) einen soliden, wartbaren, korrekten Code zu erzeugen und b) daraus zu lernen. Sie werden überrascht sein, wie viel Sie lernen, den Code anderer zu lesen und Ihren Code überprüfen zu lassen. Ja, die Idee Code auszulesen ist PAINFUL, aber in der Praxis ist es eine großartige Bildungserfahrung, und es gibt Ihnen Ideen, worauf Sie in Zukunft achten sollten.
HINWEIS: Wenn die Probleme, die sie identifizieren, nicht hilfreich sind - "das ist dumm", "könnte dies viel besser gemacht werden", im Vergleich zu nützlicher - "wenn Sie dies umgestalten und das Aussehen ausrollen, können Sie es aus der Bestellung ändern O (n ^ 2), um O (n) zu bestellen "- dann achte darauf - achte vielleicht am Anfang darauf, den Autor oder den Code nicht anzugreifen, sondern zu helfen, dich zu verbessern. Das könnte sie sogar überraschen - sie haben vielleicht nicht bemerkt, dass sie in ihrer Kritik konfrontativ waren.
Auf die Frage der sprachübergreifenden Überprüfung - sicher. Die Codesyntax von einer Sprache zu einer anderen kann sich unterscheiden, aber so viele der gelernten Tricks, Algorithmen, Logikverläufe, häufige Fehler und mehr werden unabhängig von der Sprache gelernt und können als Erfahrung für zukünftige Reviews oder Codierungen verwendet werden.
>Ein Programmierer, der eine andere Sprache kennt, könnte vielleicht Bugs finden, aber Java und Ruby sind stilistisch so unterschiedlich, dass ich nicht sicher bin, ob er nützliche Stilpunkte geben wird. Auch wenn der andere Programmierer nur Java kennt, kann er vielleicht Ruby nicht gut genug lesen, um Fehler zu finden (Blöcke sind einem Java-Programmierer sehr fremd).
"aber es ist ein notwendiges Übel" ist bereits ein Hinweis, dass Sie und Ihr Chef und die Organisation einige Probleme haben.
Ich bezweifle, dass Sie von Code-Reviews profitieren werden - nicht weil Code-Reviews böse sind oder weil Leute, die keine Sprache beherrschen, Code überprüfen, aber weil Ihre Kultur es einfach nicht zulassen wird.
Sie alle müssen einige gute Methoden der Durchführung von Überprüfungen lernen. Werfen Sie alle Ihre Vorstellungen von dem, was sie sind, und entweder Hilfe mit ihnen oder lesen Sie etwas gutes Material.
Beginnen Sie mit sehr geringen Auswirkungen, informellen Bewertungen.
viel Glück
Eh, hast du eine Wahl? Ich dachte, er wäre dein Chef
?(in anderen Welten, gönne ihm - du wirst es irgendwann trotzdem :))
Ich denke, Sie sollten die Tatsache in Betracht ziehen, dass Ihre Ruby-Programme selbst für einen Nicht-Ruby-Programmierer lesbar und wartbar sein sollten. Ich denke, es ist fair, Ihren Chef sehen zu lassen, dass Sie solchen Code schreiben können. Der Code sollte jedem im Programmierteam "gehören".
Ich denke, dass es effektiv sein kann, aber ich glaube, um die größtmögliche Effektivität zu erreichen, müssen Sie einen Code-Review durchführen, der mehr von einem sprachunabhängigen Ansatz ausgeht. Ihr Chef kann nicht über den "Java-Weg" nachdenken, während Sie bei der Überprüfung an den "rubinroten Weg" denken. Sie müssen beide mehr in Pseudo-Code-Begriffen denken. Ihre letzte Aussage, dass Sie aus dem Gebäude gehen müssen, legt nahe, dass Ihr Chef vielleicht Rubin lernen sollte, besonders da er vorgeschlagen hat, Ruby zu lernen. Viel Glück!
Sie können es sein, aber deins wird es nicht sein, weil der Java-Typ nicht wie ein großartiger Programmierer klingt. Es gibt einige Dinge, die in vielen Sprachen üblich sind (z. B. Variablen im kleinstmöglichen Umfang deklarieren, Funktionen sollten eine Sache tun, lose Bindung und enge Kopplung, richtige Abstraktion, etc.).
Wenn das Review relativ hoch bleibt, kann es sehr konstruktiv sein. Solange er architektonische Fragen stellt, wie zum Beispiel warum Sie ein bestimmtes Muster oder einen bestimmten Algorithmus verwendet haben, sollte dies sehr hilfreich sein. Neue Programmierer benötigen normalerweise eine Anleitung, wie sie ihre Anwendungen auf einer höheren Ebene strukturieren können, und ich glaube, dass dies von jedem guten Softwareentwickler bereitgestellt werden kann.
Wenn er sich nur Gedanken über den Codierungsstil (Gehäuse, Einzug usw.) macht, wird dies weniger hilfreich sein. obwohl er in der Lage sein kann, darauf hinzuweisen, wo Sie inkonsistent sind.
Ich würde ja sagen, da ich ein paar verschiedene Möglichkeiten sehe, wie es funktionieren könnte:
Der Chef liest den Code selbst und spielt herum, um zu sehen, wie die Dinge im Allgemeinen funktionieren, und kommt dann zurück, um Sie durch verschiedene Teile zu führen, die geändert werden können, um Teile der Anwendung zu verbessern.
Der Chef führt eine Rezension durch, indem er sagt: "Ich möchte mich auf dieses Stück konzentrieren", und wo er etwas nicht versteht, erklärst du es, damit er verstehen kann, was du getan hast, während du auch nachdenkst verschiedene Ideen der "Gotchas", die möglicherweise universell sind, z Mülleingabe, Protokollierung und Ausnahmebehandlung.
In beiden Fällen ist etwas zu sagen, um gute Teile, schlechte Teile und was man tun kann, um die schlechten Teile zu reparieren, zu identifizieren. Sowohl die konstruktive Kritik als auch die Frage, was als nächstes und in welchem Zeitrahmen getan werden sollte, sind wichtige Punkte dafür. Zu sagen: "Das ist Mist, wiederhole alles jetzt", ist nicht gerade nützlich.
Vielleicht können Sie eine Design-Überprüfung von der Code-Überprüfung trennen.
Ein erfahrener Entwickler sollte in der Lage sein, effektiv an einer Design-Überprüfung einer Anwendung teilzunehmen und einen Mehrwert zu schaffen.
Der Unterschied wäre, dass Sie den tatsächlichen Code oder die Syntax dieses oder jenes Features nicht diskutieren oder überprüfen müssten, sondern von einer höheren Ebene aus, welche Algorithmen verwendet werden, wie Sie die Klassen angelegt haben und Verantwortungsbereiche usw.
Kann ein Programmierer, der in einer Sprache schreibt, effektiv einen hilfreichen / konstruktiven Code-Review einer anderen Sprache durchführen, von der er keine Kenntnis hat?
Sie mögen hier eine etwas übereilte Verallgemeinerung von Code-Reviewern machen, nämlich dass, wenn ein Programmierer kompetent in einer Sprache schreibt, dass er oder sie hilfreiche / konstruktive Code-Überprüfung durchführen wird, diese Sprache sündigen wird. Das ist oft nicht der Fall.
Um eine hilfreiche / konstruktive Codeüberprüfung in jeder Sprache zu ermöglichen, müssen Sie ein guter Lehrer sein und gute Programmierkenntnisse (in einer bestimmten Sprache) haben. Ein sehr hoher Prozentsatz von Code-Review-Kommentaren (ohnehin die hilfreichsten) sind nicht spezifisch für die Syntax einer bestimmten Sprache, sondern befassen sich eher mit High-Level-Konzepten. So hat ein effektiver Gutachter in der Regel gute Kenntnisse über "Code Smells" und gängige Refactoring-Techniken.
Die kurze Antwort auf Ihre Frage lautet also "Ja". Aber sie müssen auch ein guter Lehrer sein.
Die letzte Kritik, die wir hatten, war schrecklich, ich musste aus dem Gebäude gehen - weil seine Kritik nicht wirklich war führe mich in irgendeine Richtung ...
Review Kommentare sollten nicht als Kritik gewertet werden (und sie sollten auch nicht auf diese Weise verteilt werden). Die Rezension ist eine Chance für den Autor und den Rezensent, etwas zu lernen. Die besten Code-Reviews haben mehr als einen Reviewer, bei dem eine Gruppendiskussion jeden zur besten Antwort führen kann. Der Code selbst ist fast nebensächlich für die Überprüfung. Die Überprüfung ist ein Erfolg, nicht wenn der Code festgelegt ist, sondern wenn die Teilnehmer eine bessere Methode zum Code lernen, die sie für zukünftige Bemühungen verwenden können.
Eines der Dinge, die ich in einem Code-Review als nützlich empfunden habe, unabhängig davon, was das Qualifikationsniveau des Rezensenten ist, ist die Möglichkeit zu erklären, was ich in Worten gemacht habe. Manchmal kann es einfach sein, wenn Sie das, was Sie getan haben, in eine Erklärung bringen, dass Sie (nicht der Prüfer) sehen, wo etwas unvollständig ist oder auf eine andere Art und Weise angesprochen werden könnte.
Das Wichtigste bei einem Code Review ist die Einstellung - Ihre Einstellung. Wenn Sie darauf eingehen und erwarten, dass es wertlos ist, dann wird es sein. Wenn Sie damit rechnen, beleidigt zu werden, dann werden Sie es sein. Wenn Sie mit einem offenen Geist und der Bereitschaft, es als Lernerfahrung oder die Möglichkeit, Bugs oder Probleme zu finden, bevor sie in die Produktion gehen und PROBLEME werden, gehen, dann ist das, was Sie finden werden.
Niemandes Code ist perfekt, es gibt mehrere Möglichkeiten, alles zu tun. Manchmal haben andere Leute einen Ansatz, an den Sie nicht gedacht haben, aber der vielleicht besser ist als der, den Sie gewählt haben. Selbst wenn Sie sich aus Zeitgründen dazu entschließen, diesen Ansatz nicht zu ändern, wird dies jetzt in Ihrem potenziellen Toolkit als ein Ansatz berücksichtigt.
Selbst wenn Sie erklären müssen, warum Ruby die Dinge anders macht als Java, werden Sie vermutlich mehr über Ruby (um Ihre Codierungsmöglichkeiten zu verteidigen) und etwas über Java (basierend auf den Dingen, die dem Java-Programmierer.) Ich nenne das einen Gewinn.
Und ja, ein erfahrener Programmierer kann normalerweise Dinge finden, auf die er in einem Code-Review hinweisen kann, auch wenn es nicht seine übliche Sprache ist.
Kommt darauf an, wie es gerahmt ist. Es gibt viele schlechte Möglichkeiten, es so zu gestalten, dass du am Ende missbraucht wirst.
Es kann nützlich sein, aber nicht so effizient wie jemand, der die Sprache kennt. Genauso wie der von einem Junior-Ruby-Programmierer überprüfte Code einen gewissen Nutzen haben könnte, wird eine erfahrene Person mehr helfen.
Der andere Aspekt ist, es so zu gestalten, dass die Java-Leute etwas Ruby lernen können. Rezensionen können in beide Richtungen gehen. Sie erhalten auch gute Erfahrungen bei der Präsentation Ihrer Arbeit.
Wie andere sagen, klingt es nicht so, als hätten Sie eine große Auswahl, und es kann wirklich nützlich sein.
Die ganze Zeit passiert es mir:
Ruby ist einfacher als Java, also tut es vielleicht nicht so weh, aber der Java-Typ wird versucht sein, ungewöhnliche Konzepte in Ruby anzuwenden.
Meiner Meinung nach ist es nahezu wertlos, dass Ihr Code überprüft wird von:
Tags und Links ruby java code-review