Wie würden Sie reagieren, wenn jemand Ihnen sagt, dass Ihr Code ein Durcheinander ist?

Ich bin ein guter Programmierer, dachte ich früher. Ich liebe es immer zu programmieren. Und ich möchte viel über das Programmieren lernen, um mich zu einem besseren Programmierer zu machen. Ich habe 1 Jahr Programmieren studiert und arbeite jetzt fast 2 Jahre als Programmierer. Kurz gesagt, ich habe fast 3 Jahre Programmiererfahrung.

Unser Team besteht aus 5 Programmierern und 4 von uns sind neu. 1 hat mehr als 3 Jahre Erfahrung. Wir arbeiten seit fast einem Jahr für ein Programm, und niemand hat jemals meinen Code überprüft, und ich bekam eine Seite, auf der ich arbeiten konnte. Wir hatten noch nie eine Codeüberprüfung und sind alle neu, sodass wir nicht wissen, wie ein sauberer Code aussieht. Ich denke, Programmierer lernen von selbst?

Wir haben unser Programm ohne gründliche Tests für das Programm bereitgestellt. Jetzt ist es eng und wir brauchen erst eine Genehmigung und Codeüberprüfung, bevor wir Änderungen am Code vornehmen. Zum ersten Mal überprüft jemand meinen Code und sagt, es sei ein Durcheinander.

Ich fühle mich so traurig und verletzt. Ich liebe es wirklich zu programmieren und sie dazu zu bringen, so etwas zu sagen, tut mir wirklich weh. Ich möchte mich wirklich verbessern. Aber ich bin anscheinend kein genialer Programmierer wie im Film. Können Sie mir einen Rat geben, wie ich besser werden kann? Haben Sie jemals etwas erlebt, das Ihren Code kritisiert, und Sie fühlen sich wirklich verletzt? Was machst du auf diesen Events?

Die Wahrheit ist, dass Sie wahrscheinlich in 2 Jahren, wenn Sie Ihren aktuellen Code sehen, zustimmen werden, dass es ein Durcheinander war. Programmieren lernen ist ein nie endender Prozess und es wird immer jemanden geben, der es besser kann als Sie.

Wenn also eine Person, die sagte, dass Ihr Code ein Durcheinander ist, nicht nur gemein ist und es sich nicht um einen weiteren Fall der bei Programmierern häufig vorkommenden Krankheit "Ich würde es besser machen" handelt, sollten Sie sie / ihn fragen, was genau mit Ihrem Code falsch ist und wie Sie das tun können Verbessere es.

Seien Sie nicht stolz darauf, wie gut Sie codieren. Seien Sie stolz darauf, wie gut Sie lernen. Wenn Sie dann erfahren, dass Ihr Code verbesserungsbedürftig ist, können Sie zeigen, wie gut Sie lernen, anstatt zu kritisieren, wie schlecht Sie als Programmierer sind.

Lesen Sie http://www.perlmonks.org/?node_id=270083, wenn Sie keine Ahnung haben, wovon ich spreche.

Nach mehr als 20 Jahren weiß ich, dass ein Teil meines eigenen Codes immer noch ein Chaos ist. Es kommt darauf an, eine Entscheidung zwischen dem Schreiben des bestmöglichen Codes und dem Schreiben der für die Erledigung der Aufgabe erforderlichen Elemente zu treffen. Die Erledigung der Arbeit innerhalb eines vereinbarten Zeitrahmens übertrifft jeden Tag das unendliche Streben nach technischer Perfektion.

Der Trick ist zu lernen, es zu akzeptieren. Lerne zu akzeptieren, dass du es besser machen könntest. Lerne mit den Fehlern zu leben. Lerne zu akzeptieren, dass du es dieses Mal und wahrscheinlich auch beim nächsten Mal nicht perfekt machen wirst und dass es eine bewusste Wahl ist, weil die Alternative nicht liefert. Und das ist noch schlimmer.

Haftungsausschluss: Nichts davon sollte als "fehlerhafter Code ist in Ordnung" gelesen werden.

Jeder Code ist ein Durcheinander und es gibt keine guten Programmierer.

Es gibt:

• Programmierer, die schnell versenden,
• Programmierer, die immer semantisch korrekten Code liefern,
• Programmierer, die immer die optimale Lösung und den schnellsten Algorithmus finden,
• Programmierer, deren Code das Auge schont.

Sie sind kaum, wenn überhaupt, dieselbe Person.

Und es gibt Butthurt-Programmierer, die erwachsen werden müssen und:

• frage was los ist,
• nimm keinen Kommentar persönlich, als Maß für ihren Wert als menschliches Wesen;
• Beachten Sie, dass es in Teams Syntaxrichtlinien gibt, die befolgt werden müssen und die willkürlich sind. Sie sind also nicht dazu gedacht, ad nauseam besprochen zu werden , da es keine optimale Lösung und kein endgültiges Wort gibt.
• Werden Sie besser darin, ihren Code zu kommentieren.
• Werden Sie besser darin, ihren Code zu kommentieren. (sic)
• einfacher zu debuggen, weniger klug, Lösungen für einfache, alltägliche Aufgaben zu finden;
• Nehmen Sie an einem SQL-Kurs teil
  (ich würde die Hälfte der Weltbevölkerung schicken, um an einem SQL-Kurs teilzunehmen, nur um auf der sicheren Seite zu sein)

Es ist keine Kunst, es ist ein Handwerk.
Wir gehen davon aus, dass Sie schlau sind: Sie programmieren Computer, verdammt noch mal.
Still AMD64und x86sind nicht durch die Kraft Ihrer Prosa gezwungen. Halte die Dinge einfach.

Nun, eine Person, die sagt, dass Ihr Code ein Durcheinander ist, ist nicht konstruktiv, auch wenn sie recht hat. Haben sie dir Gründe genannt, warum es ein Chaos ist? Wie, Methoden sind zu lang, Verantwortlichkeiten vermischt, zu viel Verzweigung, etc. Ehrlich gesagt, jeder Code, den ich vor einem Jahr schrieb, würde ich sagen, ist völliger Mist, weil ich seitdem eine Tonne gelernt habe. Fühle dich also nicht schlecht dabei. Ich wäre besorgter, wenn Sie den Code, den Sie vor langer Zeit geschrieben haben, immer noch gerne lesen würden.

Je sauberer Ihre Codebasis ist, desto weniger Zeit verbringen Sie damit, die Codebasis zu bekämpfen, um ein bestimmtes Problem zu lösen. Ein Jahr ist ein großartiger Anlass, da Sie die Qualen jeder Entwurfsentscheidung spüren können, die Sie zu Beginn des Projekts getroffen haben.

Bei meinem aktuellen Projekt haben wir einige Male überarbeitet, um uns mit unserem Technologie-Stack besser vertraut zu machen. Dies sollte gefördert werden, und Sie sollten sich Aufgaben merken, die aufgrund der vorhandenen Codebasis länger dauern als erwartet.

Haben Sie einige der älteren Teile des Codes durchgesehen, den Sie geschrieben haben? Sie können wahrscheinlich Dinge sehen, die Sie jetzt anders machen oder umgestalten möchten.

Auch wenn Sie einen Mangel an Tests erwähnen, ist dies immer etwas zu betrachten. In unserem Projekt gab es keine automatisierten Tests und daher viel hochgradig gekoppelten Code. Selbst wenn Sie Unit / Integration / Was auch immer-Tests nicht regelmäßig schreiben, werden Sie sich daran gewöhnen, Ihren Code modularer (und damit weniger chaotisch) zu gestalten, wenn Sie dies einige Zeit lang tun.

Ich fühle mich so traurig und verletzt. Ich liebe es wirklich zu programmieren und sie dazu zu bringen, so etwas zu sagen, tut mir wirklich weh. Ich möchte mich wirklich verbessern.

Das ist gut. Das ist viel besser, als eine Reaktion wie "Mein Rezensent hat keine Ahnung, wovon er spricht", "Mein Rezensent ist zu wählerisch" oder einfach "Mein Rezensent mag mich nicht" zu haben und sie zu ignorieren. Diese Einstellung ist eine gute Sache.

Aber ich bin anscheinend kein genialer Programmierer wie im Film.

Ich bin nicht sicher, welche Art von Filmen Sie sehen, aber 90% der Programmierer in den Filmen sind so gefälscht, dass ich am Ende der Sequenz Tränen habe.

Können Sie mir einen Rat geben, wie ich besser werden kann?

Lesen und üben. Lesen Sie Bücher wie Code Complete oder The Pragmatic Programmer . Suchen Sie bei Amazon nach ähnlichen Büchern.

Haben Sie jemals etwas erlebt, das Ihren Code kritisiert, und Sie fühlen sich wirklich verletzt? Was machst du auf diesen Events?

Warum fühlst du dich verletzt? Ich bin von mir selbst enttäuscht, dass ich so ein Idiot bin. Ich benutze diese Motivation, um meinen Code zu bereinigen und sicherzustellen, dass ich nicht noch einmal den gleichen Fehler mache . Das letzte was ich machen will ist nicht daraus zu lernen. Sie wurden einmal niedergeschlagen, lassen Sie es aus dem gleichen Grund nicht noch einmal geschehen.

Kein Programmierer ist perfekt geboren oder auch nur in der Nähe. Je mehr Code , Sie schreiben, desto mehr Bewertungen Sie erhalten und Bewertungen Sie bieten , werden Sie ein rundum besseren Programmierer.

Eines der besten Dinge für mich als Entwickler ist, dass jeder Tag ein Lernprozess ist. Es wird immer jemanden da draußen geben, der etwas nicht weiß, was Sie tun, und es wird immer jemanden geben, der etwas weiß, was Sie nicht wissen. Ich würde mich auf keinen Fall als Anfänger oder Junior bezeichnen, aber ich schätze jede Kritik, die ich bekommen kann, solange sie gerechtfertigt und respektvoll ist.

Eine möglicherweise zutreffende Analogie bezieht sich auf einen Zeitraum, in dem ich als Tutor für das Schreiben an einer Universität tätig war und an Kursen für kreatives Schreiben teilgenommen habe. Das Schreiben von Code ähnelt in jeder Hinsicht dem Schreiben eines Gedichts, eines Aufsatzes, einer Kurzgeschichte oder eines Romans. Jeder hat seine eigene Vorgehensweise, aber gleichzeitig machen auch die besten Autoren (oder in diesem Fall die Entwickler) Fehler oder lassen Dinge durch die Ritzen gleiten. Wir können diese Dinge oft übersehen, weil wir uns so an unsere eigene Stimme (oder in diesem Fall an den Code-Stil) gewöhnen.

Wie auf jedem Gebiet gibt es auch Experten. Wenn diese Leute nicht existieren würden, hätten wir niemanden, von dem wir lernen könnten. Unter der Annahme, dass diese Person wirklich ein Experte ist, würde ich auf das hören, was sie sagt, und fragen, was sie vorschlagen würde, um Ihren Code zu verbessern. Vergessen Sie jedoch niemals, dass er nicht der einzige ist, der seine Hilfe leisten kann. Wir haben das Glück, dass es eine Fülle von Ressourcen wie SE / SO gibt.

Chaos ist eher subjektiv. Das Beste, was Sie tun können, ist, diese Person (oder den Überprüfungsbericht) tatsächlich zu fragen: Warum ist es unordentlich? (aus ihrer Sicht, das heißt)

Sie werden Ihnen bestimmt antworten und Sie können entweder:

• Argument dagegen (wenn Sie einen guten Grund dazu haben, natürlich)
• Fühlen Sie sich sehr glücklich, denn Sie haben gerade etwas Neues gelernt und Ihr zukünftiger Code wird sicherlich noch besser, da Sie jetzt wissen, wie Sie ihn dank ihrer Ratschläge weniger chaotisch machen können.

Die Tatsache, dass Sie besorgt sind, ist ein gutes Zeichen. Fangen wir damit an. Sie erwähnen, dass Sie gerne programmieren, aber lieben Sie es, ein professioneller Programmierer zu sein? Es gibt einen großen Unterschied zwischen einem Enthusiasten und einem Profi. Als Fachmann werden Sie ständig auf Ihr Arbeitsprodukt überprüft.

Our team is composed of 5 programmers, and 4 of us are new

Die Tatsache, dass Sie zwei Jahre ohne Konfrontation gearbeitet haben, zeigt mir, dass Sie in einem sehr entspannten Job arbeiten, der nicht so gut ist, wenn Sie sich tatsächlich als Profi weiterentwickeln möchten. Wohlgemerkt, einige der besten Programmierer der Welt arbeiten für die Linux-Stiftung und seien Sie versichert, dass sie nicht freundlich behandelt werden, wenn sie marginale Fehler machen ... geschweige denn "chaotischen Code".

Die Linux Community Contributors Standards geben Ihnen einen Überblick über den Grad der Verantwortung, den Sie für Ihr Produkt anstreben müssen, um einen schnellen Überblick über einige recht standardmäßige Kodierungsrichtlinien zu erhalten . Siehe CODE RECHTS ERHALTEN.

Um diese Behauptung zu fördern, sollten Sie lernen, die Überprüfung zu akzeptieren, da die meisten guten Softwareprodukte gründlich überprüft werden. Dies unterstützt Linus 'Gesetz, das besagt ...

"Wenn es genügend Gutachter gibt, sind alle Probleme leicht zu lösen."

Persönlich habe ich gesehen, wie hochqualifizierte, verantwortungsbewusste und zuverlässige Entwickler die Axt für etwas erhalten, das so einfach ist wie das Vergessen, Kommentare zu hinterlassen. Refactoring. Es ist Teil des Gigs.

I feel so sad and hurt. 

Machen Sie eine Traurigkeits-Bewerbung, um festzustellen, wie verstört Sie sind, wenn Sie sich nicht bewerben.

Sie haben Ihr Problem beantwortet ... Sie testen nicht!

Nachdem Sie einen Kommentar gesehen haben, der besagt, dass Sie ein Java-Entwickler sind, war ich fast verärgert. Wenn ich Sie richtig verstehe, sagen Sie, dass Sie und Ihr Entwicklungsteam in einem Java-Shop arbeiten und kein Testframework für Ihre Anwendungen haben ...

Darin liegt die Unebenheit

"Wir haben unser Programm ohne gründliche Tests für das Programm bereitgestellt."

Cribbing UML Creator Grady Booch ...

Der Amateur-Softwareentwickler ist immer auf der Suche nach Magie, einer sensationellen Methode oder einem Werkzeug, deren Anwendung verspricht, die Softwareentwicklung trivial zu machen. Es ist das Markenzeichen des professionellen Software-Ingenieurs zu wissen, dass es kein solches Allheilmittel gibt.

Alistair Cockburn bietet auf seiner Website eine Fülle von Informationen zum Einsatz agiler Methoden zur Steigerung der Leistung und Qualität für Sie und Ihr Team.

Einer der wichtigsten Aspekte des Programmierens ist es, Ihre Stärken und Schwächen zu kennen. Wenn Sie nicht an Ihren Schwächen arbeiten, verfügen Sie nicht über umfassende Fähigkeiten.

Outro ... Du machst es gut - nur nicht jammern. Entwickle dein Handwerk weiter und lass dich von deiner Leidenschaft für das Programmieren inspirieren. Viel Glück :-)

Lassen Sie nicht zu, dass Ihre Emotionen der Verbesserung Ihres Codes im Wege stehen. Das Ziel einer Codeüberprüfung besteht darin, Probleme zu finden. Sie sollten sich also nicht wundern, wenn es welche gibt. Das heißt, sie sollten auch keine Coder-Bashing-Session sein.

Sie sollten auch nicht einfach "Ewwww" sagen und es dabei belassen. Es gibt immer einen Grund, warum etwas in der Programmierung nicht stimmt. Zum Beispiel ist es falsch, viele auskommentierte Codes überall zu hinterlassen, aber es ist falsch, weil es den Code überfüllt und das Lesen erschwert, nicht weil dies in einem Buch jemand gesagt hat.

Dein Code bist nicht du. Erinnere dich daran.

Ich werde der Schwanz hier sein und auf der Grundlage von .. na ja, dem Offensichtlichen raten. Offensichtlich ist Ihr Code ein Durcheinander oder die Frage, die Sie stellen würden, lautet: "WARUM sagt jemand, mein Code ist ein Durcheinander?" Aber Sie stellen die Vermutung nicht in Frage. Sie tun einfach nur weh und ehrlich gesagt kann es weinen, aber es gibt kein Gefühl, wenn es darum geht, die Programmierung zu rechtfertigen.

Aber wirklich, warum fragst du? Sie wissen, dass Ihr Code scheiße ist, oder Sie würden eine andere Frage stellen. Wenn mir jemand sagen würde, dass mein Back-End-Webcode stinkt, würde ich lachen und sagen: "Okay, was ist daran falsch?" Wenn sie mir sagen würden, dass mein JavaScript stinkt, gäbe ich ihnen das Äquivalent einer fetten Lippe als Social Programmer und würde sie nie um Rat fragen, wie sie reagieren sollen, weil die kleinen Hündinnen eindeutig falsch liegen!

Besitze, was du kannst. Und ich meine wirklich Verantwortung dafür zu übernehmen. weil es nur einen Trottel braucht, um dich zu erraten. Bitte nicht um Erlaubnis, gut zu sein. Kennen Sie einfach Ihre Sachen. Das Ende.

Denken Sie daran: Der schlechteste Code, den Sie jemals sehen werden, ist Ihr eigener!

Jeff Atwood von codinghorror.com hat viel zu diesem Thema geschrieben. Vielleicht möchten Sie hier beginnen: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

Wenn Sie sich verbessern möchten, lesen Sie etwas über Codierungsstil, Muster, Arbeitsabläufe, im Grunde alles, worauf Sie Ihre Finger legen können. Lernen Sie auch mehr Programmiersprachen und sehen Sie, wie diese Dinge tun. Wenn Sie OOP machen, lesen Sie dies: http://en.wikipedia.org/wiki/Design_Patterns

Sprechen Sie auch mit anderen Programmierern und programmieren Sie Paare oder sehen Sie sich den Code anderer an.

Fehler zu machen ist unvermeidlich, sie zu wiederholen ist.

Meistens sollten Sie der Person, die Ihnen das erzählt hat, "Danke" sagen.

Möglicherweise kümmern sie sich um ihren Beruf, sie kümmern sich um ihre Arbeit, sie kümmern sich um ihr Team und sie kümmern sich um Sie.

Es kann schwierig sein, Kritik zu üben. Sei nicht böse darüber. Denken Sie darüber nach, was sie Ihnen sagen wollen, und lassen Sie sich nicht von Ihren Emotionen überwältigen.

Ich programmiere seit langer Zeit (30 Jahre) und mein Stil und Code verbessern sich ständig (ich hoffe). Ich weiß nur, dass es sich verbessert, wenn andere es mir sagen oder wenn ich meinen Code noch einmal überprüfe.

Schauen Sie sich den Code an, den Sie zu Beginn Ihrer Karriere geschrieben haben. Wie sieht es für dich jetzt aus? Sieht es so gut aus, wie du es dir vorgestellt hast, als du es geschrieben hast?

Zuallererst müssen Sie verstehen, dass das Programmieren ein iterativer Prozess ist, ähnlich wie das Schreiben eines Artikels oder eines Buches. Zuerst schreiben Sie einen "groben Entwurf" Ihres Programms, um es zum Laufen zu bringen. In diesem Stadium wird Ihr Code ein Chaos sein. Sie überarbeiten also, um den Code sauber zu machen. Dann profilierst du und siehst, was du optimieren musst, um es schnell zu machen. Der Trick besteht darin, kontinuierlich umzugestalten, da sonst das Chaos zunimmt. Sie müssen Ihren Code regelmäßig säubern, genauso wie Sie Ihr Haus säubern müssen.

Code Reviews sind absolut notwendig. Sie müssen Ihren Code von mindestens einem weiteren Augenpaar betrachten lassen. Wenn Sie unzählige Stunden damit verbringen, Ihren Code zu betrachten, gewöhnen Sie sich daran und können leicht einen Fehler oder einen Codegeruch übersehen, den Ihr Mitarbeiter möglicherweise sofort bemerkt.

Das Erklären Ihres Codes für eine andere Person ist auch eine hervorragende Möglichkeit, um festzustellen, ob Sie etwas verpasst haben. Dies ist wie das Lesen einer Zeitung, die Sie laut schreiben. Ihr Gehirn verarbeitet Audio- und visuelle Informationen auf unterschiedliche Weise, und Sie können Fehler in Ihrer Argumentation finden, indem Sie die Modalität wechseln. Wenn Sie einer Mitarbeiterin Ihren Code erklären und etwas für sie nicht sinnvoll ist, ist dies ein guter Hinweis darauf, dass Sie Ihren Code überarbeiten sollten.

Bei einer Codeüberprüfung ist es sehr wichtig, dass sowohl der Autor als auch der Überprüfer ihr Ego an der Tür überprüfen. Das Ziel ist es, den Code besser zu machen. Der Rezensent muss also respektvoll sein, und der Autor muss offen sein. Denken Sie daran, Ihre Mitarbeiter sind diejenigen, die Ihren Code pflegen müssen, es muss ihnen also klar sein. Wenn der Prüfer nicht versteht, was eine Variable tut, benennen Sie sie um. Wenn der Prüfer nicht versteht, was ein Codeblock tut, zerlegen Sie ihn in eine Funktion mit einem beschreibenden Namen. Unabhängig davon, was Sie denken, ist es nicht gut, wenn Ihre Kollegen Ihren Code nicht verstehen können.

Apropos Refactoring: Sie müssen unbedingt über ein Unit-Test-Framework verfügen, da Sie ohne dieses Framework kein Refactoring durchführen können.

Schließlich empfehle ich dringend, "Clean Code" von Robert C. Martin zu lesen. Es wird Ihnen sagen, warum Ihr Code ein Chaos ist und was Sie tun können, um ihn zu bereinigen.

Können Sie mir einen Rat geben, wie ich besser werden kann?

Jays Antwort, die Bücher empfiehlt, ist gut, aber es hört sich so an, als stünden Sie bereits an einem Wendepunkt bei der Arbeit.

Vergangenheit:

Unser Team besteht aus 5 Programmierern und 4 von uns sind neu. 1 hat mehr als 3 Jahre Erfahrung. Wir arbeiten seit fast einem Jahr für ein Programm, und niemand hat jemals meinen Code überprüft, und ich bekam eine Seite, auf der ich arbeiten konnte.

Vorhanden:

Jetzt ist es eng und wir brauchen erst eine Genehmigung und Codeüberprüfung, bevor wir Änderungen am Code vornehmen.

Es hört sich so an, als würde Ihr Unternehmen / Team / Abteilung als Ganzes lernen, sowohl in Bezug auf das Projekt- und Teammanagement als auch in Bezug auf die Programmierung. Die Überprüfung von Code ist eine hervorragende Gelegenheit, um in nahezu allen Bereichen Verbesserungen vorzunehmen, wenn der Code die erforderliche Aufmerksamkeit erhält.

Nutzen Sie dies als Gelegenheit; Angenommen, Sie führen Peer Reviews durch (mit den anderen Entwicklern in Ihrem Team), dann legen Sie ihnen nahe, dass dieser Prozess wichtig ist und dass jeder daraus lernen kann.

An der Basislinie wird es eine schnelle Überprüfung mit dem Ergebnis "Ja, sieht in Ordnung aus" geben. Mit etwas gezielterer Anstrengung können Sie Ideen voneinander abprallen. "Ja, das funktioniert, aber Sie hätten es auf diese Weise angehen können, was Ihr Ziel klarer gemacht hätte ...". Machen Sie sich Notizen für die Zukunft, auch wenn die Bereitstellung des Codes als in Ordnung erachtet wird.

Wenn dies erfolgreich sein soll, müssen Sie Ihr Team und Ihren Manager auf die Seite stellen, was häufig bedeutet, ihnen die Vorteile zu erklären. Für die anderen Entwickler ist dies eine Gelegenheit zum Lernen. Für Ihren Vorgesetzten ist dies die Gelegenheit, das Team zu geringen Kosten zu verbessern und so Ergebnisse zu erzielen, die a) wertvoller oder b) schneller und c) wartungsärmer sind (in der Regel ein großes Problem!).

Dies ist ein Kulturwandel, den Sie nicht selbst erzwingen können, aber Sie können helfen, die Dinge in die richtige Richtung zu lenken!

Vergessen Sie nicht, dies ist eine Art Kulturwandel, der für Organisationen von großem Nutzen sein kann. Gute Manager werden erkennen, dass Sie daran arbeiten, das gesamte Team zu verbessern, was sich auszahlt.

Können Sie mir einen Rat geben, wie ich besser werden kann? Haben Sie jemals etwas erlebt, das Ihren Code kritisiert, und Sie fühlen sich wirklich verletzt? Was machst du auf diesen Events?

Die Antwort darauf finden Sie in den Unternehmen der neuen Generation. Ich war in Unternehmen wie Google und FaceBook und ich sehe, dass man, wenn man den Agile / Scrum-Prozess religiös verfolgt, besseren Code schreiben und ihn bei jedem Sprint verbessern kann.

How to be better? 

Die Antwort ist kontinuierliches Refactoring. Die modernen Entwicklungstools wie Visual Studio verfügen über viele Tools, die Sie bei diesem Prozess unterstützen. Wenn Sie den Scrum-Softwareentwicklungsprozess verfolgen, beispielsweise, dass Sie in Sprint-Zyklus 1 fehlerhaften Code geschrieben haben und während der Überprüfung darauf hingewiesen wurde, dass dieser fehlerhaft ist, haben Sie in Sprint 2 die Möglichkeit, den Code zu überarbeiten.

Diese Probleme treten in erster Linie auf, weil ein guter Prozess fehlt. Die Lösung besteht also darin, einen guten Softwareentwicklungsprozess für Ihr Team zu entwickeln und kontinuierliches Refactoring zu üben.

Ich würde ihnen für das Feedback danken und sie dann bitten zu erklären, was es schlecht macht und wie es verbessert werden sollte.

Wenn Sie der Meinung sind, dass die Person, die das Feedback gibt, sinnvoll ist, sollten Sie in Zukunft Änderungen vornehmen. Aber denken Sie daran, nur weil jemand sagt, dass es nicht heißt, dass es wahr ist.

Können Sie konkrete Beispiele dafür nennen, was als "Durcheinander" bezeichnet wurde?

Zunächst einmal ist jemand, der sagt, Ihr Code sei ein Durcheinander, sehr vage und subjektiv. Es kann verschiedene Dinge für verschiedene Menschen bedeuten. Hier ist der Grund; Es gibt zwei verschiedene Dinge, die berücksichtigt werden müssen.

Struktur

Die Struktur Ihres Codes wird von der Sprache, den Industriestandards und den Unternehmensstandards bestimmt, um nur einige zu nennen. Offensichtlich gibt es auch andere Faktoren.

Dies sind die Arten von Fehlern, mit denen Fusseln, Testwerkzeuge und ähnliche Produkte identifiziert werden sollen. Sie sind gut definiert und Sie oder Ihre Tools können objektive Entscheidungen hinsichtlich ihrer Gültigkeit / Richtigkeit treffen.

Stil

Trotz standardisierter Struktur / Regeln für Code hat jeder Entwickler einen bestimmten Stil in der Art und Weise, wie er ein Problem oder eine Aufgabe schreibt und angeht. Führen Sie die Codewartung in jeder Teamumgebung durch, und im Laufe der Zeit können Sie eine fundierte Vermutung anstellen, wer den Code basierend auf dem Stil geschrieben hat. Sie entwickeln auch Ihren eigenen Stil und er ändert sich, wenn Sie Erfahrung sammeln und Ihr Handwerk erlernen.

Jedes Mal, wenn jemand sagt, dass Ihr Code ein Durcheinander ist , müssen Sie verstehen, ob es sich um die Struktur oder den Stil handelt . Sie sind zwei sehr verschiedene Dinge; Die Struktur ist objektiv, während der Stil absolut subjektiv ist.

Abgesehen davon kann jedes konstruktive Feedback von anderen Programmierern für Sie sehr wertvoll sein. Es liegt ganz bei dir und wie du die Kritik aufnimmst. Im Laufe der Zeit lernen Sie, wer sich die Meinung zu Herzen nimmt und wer mit einem Körnchen Salz.

Im Laufe Ihrer Karriere werden Sie auf Ihren eigenen Code zurückblicken und Dinge entdecken, die Sie anders, besser, sauberer und schneller machen können. Dies ist alles Teil des Lernprozesses und das Erkennen Ihrer eigenen Fehler in der Vergangenheit ist ein wahres Indiz dafür, dass Sie Ihr Handwerk verbessern und verbessern.

Lassen Sie sich nicht von ein bisschen Kritik trüben. Nimm, was du kannst und wenn es sinnvoll und wertvoll ist, füge es deinem Wissensspeicher hinzu.

Während es wichtig ist zu erkennen, wann Ihr eigener Code ein Chaos ist (sehr typisches Gefühl unter Programmierern, besonders wenn sie erfahrener werden und ihren früheren Code älter werden ), ist es noch wichtiger, zuzuhören, wenn andere Ihnen dies mitteilen.

Es gibt nur so viele Probleme, die Sie in Ihrem eigenen Code erkennen können, da sie aufgrund Ihrer aktuellen Programmierkenntnisse entstanden sind.

Die Codeüberprüfung ist eine wichtige Gelegenheit zum Lernen, da sie Sie wahrscheinlich neuen Erkenntnissen aussetzen wird , die Sie bei der Arbeit am Code nicht hatten (andernfalls würden Sie ihn verwenden und es würde kein Chaos geben).

Ich denke, dass es zwei Teile gibt, um negatives Feedback zu verarbeiten.

1. Bestimmen Sie die Art der angesprochenen Probleme und was Sie daraus lernen sollten

Wenn ich meinen Code überprüfe oder überprüfen lasse, sortiere ich Informationen zu Codeproblemen in ungefähr solchen Buckets:

• verstößt gegen harte technologische Anforderungen
  • einfach falsch (funktioniert nicht oder erfüllt nicht die Anforderungen)
  • schlägt unter anderen Umständen fehl (Umgebungs- / Konfigurationsänderung)
  • verwendet veraltete Funktionen und wird in absehbarer Zukunft brechen
• verstößt gegen branchenweit bewährte Verfahren und weist Mängel auf wie
  • unter Verwendung eines bewährten Ansatzes für ein spezifisches Problem
  • Performance
  • Abwärtskompatibilität
  • einfache Wartung
  • Codierungsstil
  • Dokumentation
• gegen die Best Practice am Arbeitsplatz verstößt
  • Entspricht der Branche, ist jedoch spezifischer für Unternehmen / Kollegen und kann sich in Details von der Branche unterscheiden
• nicht im Einklang mit persönlichem Fachwissen
  • kann in gewisser Weise nach Ansicht der Person Überprüfung verbessert werden

Beachten Sie, dass dies von sehr objektiven Dingen ("das wird bei der Bereitstellung auf unserem Produktionsserver kaputt gehen") bis zu sehr subjektiven Dingen ("Ich mag nicht, wie Sie Variablen benannt haben") reicht.

2. Bestimmen Sie, welche Änderungen (falls vorhanden) am Code als Ergebnis der Überprüfung vorgenommen werden

Nachdem die Informationen verarbeitet wurden, wird entschieden, ob sie umsetzbar sind und ob der Code geändert werden sollte. Dies ist nicht unbedingt Ihre Entscheidung, Ihre Meinung könnte oder könnte nicht von Bedeutung sein, abhängig von den beteiligten Parteien und den Besonderheiten Ihrer Situation (Dienstalter usw.). Aber mögliche Ergebnisse sind ungefähr:

• Problem vollständig beheben
  • Verlegenheit gebrochen
  • Formatieren Sie den gewünschten Codierungsstil
  • und so weiter
• Kompromisse eingehen, wenn das Problem ganz oder teilweise angegangen werden sollte, da dies der Fall sein könnte
  • keine Ressourcen (wie Zeit oder Budget)
  • keine Notwendigkeit (wird nur eine unbedeutende Verbesserung, Kompromissstabilität usw. erzielen)
• verstehen, dass das aufgeworfene Problem ungültig ist
  • Feedback (insbesondere aus der subjektiven Meinungskategorie) kann durchaus schädlich sein und sollte nicht blind behandelt werden

Sie haben gelernt, dass es schmerzhaft ist, negatives Feedback zu erhalten, und dass es in Zukunft jedes Mal schmerzhaft sein kann. Sie haben jedoch gelernt, wie wichtig es ist, sich weiterzubilden, und wie der Prozess Ihnen dabei hilft, sich beruflich und am Arbeitsplatz zu verbessern, um eine bessere Codebasis zu erreichen.

Nun, fühl dich nicht gebrochen. Irgendwann wirst du aus den Fehlern lernen. Sobald Sie mit dem Problem fertig sind, können Sie mit dem Jungen sprechen, sodass er das Gefühl hat, dass Sie sich verbessern möchten. Versuchen Sie, mehr zuzuhören und weniger zu streiten.

Ich habe diese Situation durchgemacht und ich kann verstehen.

TL; DR

Wie würden Sie reagieren, wenn jemand Ihnen sagt, dass Ihr Code ein Durcheinander ist?

Meine unkomplizierte Antwort / Tipp:

• Gute alte Peer Review. Bitten Sie verschiedene Crews mit unterschiedlichen kollektiven Mentalitäten, Fachkenntnissen und / oder Aggressivität , Ihren Code zu überprüfen.
• Um nur ein bisschen näher darauf einzugehen, was ich unter "verschiedenen" Peer-Gruppen verstehe: Die StackExchange-Diaspora ist wahrscheinlich die bekannteste, professionellste und angesehenste Gruppe, da es im Vergleich zu Reddit relativ schwierig ist, ein Teil davon zu werden. Reddit tendiert dazu, in den populäreren Sub-Reddits sehr aggressiv zu sein - aber seltsamerweise sind die Programm-Sub-Reddits recht freundlich (nach dem, was ich erlebt habe).

Ein gutes, vielleicht das beste Beispiel für die aggressive, gangstatische Art der Cliquenmentalität sind die XDK-Foren und die schlechteste Trophäe, die ich an das CyanogenMod für Android-Foren / die IRC-Kanalbevölkerung übergebe.

Das war etwas länger als ich gedacht hatte; Mein Ziel war es, verschiedene Kritiken zu bekommen, aber mich darauf zu konzentrieren, ehrliche Kritik von den Leuten zu bekommen, die sich mit ihrem Fach auskennen und wissen, was konstruktive Kritik ist. Oh, und in der Lage sein, jede Form von Kritik anzunehmen, ohne sich davon unterkriegen zu lassen. Faustregel: Wenn Sie anfangen, ähnliche Kommentare zu einer Sache zu hören, die sich auf die Kommentare auswirken kann, sollten Sie eine gründlichere Selbstbeobachtung durchführen.