Soll ich meine autodidaktische Codierpraxis fortsetzen oder lernen, wie man professionell codiert? [geschlossen]

In letzter Zeit arbeite ich professionell, treffe mich mit anderen Programmierern und finde Freunde in der Branche. Das Einzige ist, dass ich zu 100% Autodidakt bin. Es hat dazu geführt, dass mein Stil extrem vom Stil derer abweicht, die richtig trainiert sind. Es sind die Techniken und die Organisation meines Codes, die sich unterscheiden.

Es ist eine Mischung aus mehreren Dingen, die ich tue. Ich neige dazu, mehrere Programmierparadigmen miteinander zu verschmelzen. Wie funktional und OO. Ich lehne mich mehr an die funktionale Seite als an OO, aber ich sehe die Verwendung von OO, wenn etwas als abstrakte Entität sinnvoller wäre. Wie ein Spielobjekt. Als nächstes gehe ich auch den einfachen Weg, wenn ich etwas tue. Im Gegensatz dazu ist der Code, den ich von professionellen Programmierern sehe, manchmal kompliziert. Ich benutze viele Verschlüsse. Und schließlich bin ich nicht der beste Kommentator. Ich finde es einfacher, nur meinen Code durchzulesen, als den Kommentar zu lesen. Und in den meisten Fällen lese ich nur den Code, auch wenn es Kommentare gibt. Außerdem wurde mir gesagt, dass es sehr einfach ist, meinen Code zu lesen, weil ich ihn so einfach schreibe.

Ich höre professionell ausgebildete Programmierer über Dinge wie Unit-Tests. Etwas, das ich noch nie benutzt habe, also habe ich keine Ahnung, was sie sind oder wie sie funktionieren. Viele, viele Unterstriche "_", die nicht wirklich mein Geschmack sind. Die meisten Techniken, die ich benutze, stammen von mir selbst oder von ein paar Büchern, die ich gelesen habe. Ich weiß nichts über MVC, aber ich habe viel darüber gehört, mit Dingen wie backbone.js. Ich denke, es ist eine Möglichkeit, eine Anwendung zu organisieren. Es verwirrt mich nur, weil ich inzwischen meine eigenen Organisationsstrukturen aufgebaut habe.

Es ist ein bisschen schmerzhaft. Ich kann keine Vorlagenanwendungen verwenden, wenn ich etwas Neues wie mit Ubuntu Quickly lerne. Ich habe Probleme beim Verstehen von Code, der von einer geschulten Person stammt. Vollständige OO-Programmierung hinterlässt wirklich einen schlechten Geschmack in meinem Mund, aber das scheint das zu sein, was JEDER andere streng benutzt.

Es hat mich nicht so überzeugt, wie mein Code aussieht, oder mich gefragt, ob ich beim Eintritt in ein Unternehmen Funken verursachen oder vielleicht zu Open-Source-Projekten beitragen werde. Tatsächlich habe ich eher Angst davor, dass die Leute irgendwann meinen Code auschecken werden. Ist dies etwas Normales, das ein Programmierer durchläuft, oder sollte ich wirklich versuchen, meine Techniken zu ändern?

Tatsächlich habe ich eher Angst davor, dass die Leute irgendwann meinen Code auschecken werden.

Gut. Wenn Sie sich darüber im Klaren sind, dass sich die Leute Ihren Code ansehen, werden Sie sich mehr anstrengen.

Das Programmieren ist ein unglaublich großes Feld geworden. Es gibt Dutzende von Themen, Werkzeugen, Nischen und Spezialisierungen, von denen einige eine ganze Karriere für sich sind. Es gibt eine Menge zu lernen und zu wissen, und wenn Sie mit anderen Programmierern zusammenarbeiten, wird es immer Dinge geben, die Sie wissen, dass sie es nicht tun, und Dinge, die sie wissen, dass Sie es nicht tun. Das ist eine gute Sache.

Wenn Sie befürchten, dass Ihre Erfahrungen unvollständig sind, können Sie zahlreiche Schritte unternehmen, um dies durch formelle Schulung und Zusammenarbeit mit geschulten Experten zu ändern. Aber es hört sich so an, als ob Sie befürchten, dass es einen quantifizierbaren Meilenstein gibt, nach dem die Leute sagen: "Okay, jetzt, wo ich das beherrsche, bin ich offiziell ein Programmierer." Es gibt keinen solchen Meilenstein. Ich hatte definitiv Momente, in denen ich dachte "Ja, jetzt komme ich irgendwohin", nachdem ich etwas Neues gelernt habe, aber es gibt keine magische Liste von Dingen, die Sie wissen und tun müssen, um sich selbst Programmierer zu nennen.

Ich kenne mich mit Programmieren aus, ich habe in vielen Projekten ein Dutzend Sprachen verwendet, und dennoch ist die Untermenge an Programmierkenntnissen, die ich selbst nennen kann, winzig. Und ich mag es. Ehrlich gesagt, ist ein Programmierer nicht etwas, was Sie sind. Ein Programmierer ist etwas, was Sie ständig lernen zu sein.

Bestimmen Sie ehrlich Ihre Fähigkeiten, Stärken und Schwächen. Holen Sie sich Feedback von Menschen mit mehr Erfahrung als Sie. Suchen Sie nach Positionen, die Ihrer Meinung nach gut passen - aber scheuen Sie sich nicht, Jobs anzustreben, die etwas außerhalb Ihrer derzeitigen Kompetenz liegen. Wenn Sie nur Jobs annehmen, von denen Sie bereits alles wissen, werden Sie bei der Arbeit nie lernen.

Wenn Sie anfangen, Anwendungen in Zusammenarbeit mit anderen Entwicklern zu entwickeln, werden einige dieser persönlichen Stilschwächen stören.

Wenn Sie in einem Geschäft arbeiten, in dem Unterstriche verwendet werden, werden Sie Unterstriche verwenden. Unabhängig von ihrem bisherigen Hintergrund befolgt jeder den Shop-Standard für den Codierungsstil.

Sofern Ihr Codierungsstil nicht sehr offensichtlich ist, sollten Sie sich daran gewöhnen, klare, präzise Kommentare zu verfassen, in denen erklärt wird, wie Ihr Code funktioniert, damit andere Entwickler ihm folgen können.

Wenn Sie nichts über Unit-Tests wissen, kaufen Sie ein gutes Buch. Es gibt viele gute Bücher über Unit-Tests. Gleiches gilt für MVC.

Professionelle Softwareentwickler wissen, wie man gut mit anderen spielt, ohne die Sandbox zu verschmutzen. Die allerbesten können Code unabhängig vom Stil lesen und schreiben.

Das Programmieren hat eine Kunstkomponente und eine Disziplinkomponente. Die Kunstkomponente besteht darin, sich die besten Ansätze auszudenken und diese umzusetzen. Die Disziplin besteht darin, sicherzustellen, dass Sie es richtig gemacht haben und dass andere Ihren Code verstehen und ihn bei Bedarf verbessern können.

Die Kunstkomponente macht Spaß: Sie tun es, weil Sie es genießen. Das ist natürlich der Teil, den Sie sich selbst zuerst beibringen.

Die Disziplin-Komponente ist eher ein Ärgernis: Sie tun es aus der Notwendigkeit heraus. Es ist jedoch ein wichtiger Bestandteil der Arbeit in einem Team: Man kann zumindest bis zu einem gewissen Grad nicht davon loskommen. Sobald Ihr Code in den Code Ihrer Teamkollegen integriert ist, ist Ihre Flexibilität, Dinge nach Belieben zu ändern, ein Kinderspiel. Sie müssen jedoch in der Lage sein, Ihren Code sicher zu ändern, um auf sich ändernde Anforderungen zu reagieren oder Fehler zu beheben. Hier kommen verschiedene "langweilige" Tests ins Spiel: Mit vielen Tests ist es einfach zu überprüfen, ob Ihre letzte Änderung etwas kaputt macht oder nicht.

Auch der Codestil gewinnt an Bedeutung, da die Einhaltung eines gemeinsamen Stils das Lesen des Codes für alle erleichtert. In größeren Unternehmen werden Sie nächtliche Jobs finden, bei denen die Einhaltung der Kodierungsstandards automatisch überprüft wird, und Sie werden per E-Mail gewarnt, wenn Sie davon abweichen.

Zurück zu Ihrer Frage: Die Konzentration auf die Kunstkomponente ist ein natürliches Frühstadium der Entwicklung des Programmierers. Es kann mehrere Jahre dauern, bis Sie die Komponente Disziplin zu schätzen wissen. Sie müssen jedoch nicht aktiv darauf achten, "Ihre Techniken zu ändern": Sie werden sich während der Arbeit in einem Team auf natürliche Weise verwandeln.

Auf Ihre Frage, ja, Sie sollten immer versuchen, Ihre Technik zu ändern, um das einzigartige Projekt und die aufkommende Technologie anzunehmen.

@ assfallows: "Ehrlich gesagt, ein Programmierer ist nicht etwas, das Sie sind. Ein Programmierer ist etwas, das Sie ständig lernen, zu sein." ist wirklich das A und O der Codierung.

Es ist großartig, dass Sie Bereiche bemerken, in denen Sie etwas anderes tun als andere, besonders wenn Sie sehen, dass es ein Standard ist. Sie haben Unit Testing und MVC entdeckt - und jetzt müssen Sie sich mit ihnen vertraut machen. Sehen Sie sich an, wie sie funktionieren, was Sie für die Implementierung benötigen, und machen Sie sich ein Bild davon, wann es sinnvoll ist, sie zu implementieren.

Dies ist ein sich ständig weiterentwickelndes Feld mit neuen Sprachen und Mustern, die steigen und fallen. Wenn Sie mit dem Codierungsaspekt vertraut sind, beginnen Sie mit der Untersuchung des Designteils. Erfahren Sie, was sie gut macht und wann sie verwendet werden müssen.

Der Beitritt zu einem Team ist sicherlich ein großer Vorteil - Sie brauchen immer andere Augen, um Ihren Code zu betrachten und Bereiche zu erkennen, in denen Sie sich beeilt haben oder an die Sie nicht die vollständigen Auswirkungen gedacht haben.

Sie müssen kein größerer Kommentator sein. Aber Sie sollten ein guter Commiter sein (ja, beginnen Sie mit einer Art VCS - ich empfehle Git).

Stil ist eine Sache, die sich IMMER weiterentwickelt. Mach dir keine Sorgen. Sie erfahren, was ein wiederverwendbarer Code ist und was nicht. Aber man muss üben und Hilfe dafür bekommen.

Versuchen Sie, in einem Open Source-Projekt auf Github mitzuhelfen. Einige Leute sind wirklich nett und werden versuchen, Ihnen zu helfen. Dies ist der beste Tipp, den ich Ihnen geben kann.

Tatsächlich habe ich eher Angst davor, dass die Leute irgendwann meinen Code auschecken werden. Ist dies etwas Normales, das ein Programmierer durchläuft, oder sollte ich wirklich versuchen, meine Techniken zu ändern?

Woher weißt du, was du ändern sollst, ohne dass erfahrene Programmierer dir Feedback geben?

Es kann entmutigend sein, andere Leute zu veranlassen, Ihre Arbeit zu überprüfen, insbesondere in den ersten paar Fällen. Dies ist jedoch der beste Weg, konstruktive Kritik zu üben, um Ihre Fähigkeiten zu verbessern. Es gibt eine SE-Site für Code-Reviews , die Sie möglicherweise hilfreich finden. Clevere Freunde aufzufordern, sich Ihren Code anzusehen, ist eine weitere gute Möglichkeit, Feedback zu erhalten.

Das Wichtigste ist, Flexibilität zu entwickeln. Je vertrauter Sie mit grundlegenden Konzepten sind, desto reaktionsschneller können Sie in einer Sprache, einem Programmieransatz, einem Stil oder einer Umgebung sein.

In der Meisterschaft geht es weniger darum, alles zu lernen, was zu lernen ist, als vielmehr darum, zu lernen, wie man ein Problem in einer Vielzahl von Situationen löst.

Und das beste Rezept dafür ist die Praxis. Sie sollten immer ein Projekt haben; Wenn Sie zwischen bezahlten Auftritten sind, nehmen Sie sich ein persönliches Spielzeug. Freizeit ein Wochenende? Arbeiten Sie sich durch die "Hallo Welt" für eine Sprache oder Plattform, die Sie noch nie zuvor verwendet haben. Suchen Sie nach Möglichkeiten, um auf einmal viel zu lernen. Wenn Sie beispielsweise etwas in Google App Engine erstellen, lernen Sie gleichzeitig Python, BigTable und spaltenorientierte Datenbanken kennen. Sie erhalten auch eine gute Portion "professionellen" Google-Stils.

Ein guter General kann seine erlernten Taktiken und gesammelten Erfahrungen in einer Vielzahl von Gebieten anwenden. Es hört sich so an, als hättest du einige Taktiken und Erfahrungen, aber du musst auf ungewohntes Terrain stoßen. Dies ist wahrscheinlich der beste Weg, um herauszufinden, was Sie wissen und was Sie als Nächstes lernen müssen.

Und wenn Sie nach "professionellem" Stil suchen, übernehmen Sie einige "professionelle" Projekte. Suchen Sie ein Open-Source-Projekt, das Ihnen gefällt, weisen Sie sich eine Änderung zu, und nehmen Sie die gewünschten Änderungen vor. Seien Sie auf Prüfer vorbereitet, aber denken Sie daran, dass die Mehrheit der Leute in diesem Bereich nicht dahin gekommen ist, wo sie für reibungslose soziale Fähigkeiten sind. Der Punkt ist, sich so viel von dem, was Sie sein wollen, wie möglich auszusetzen. Und Sie müssen sich gut genug aufbauen, um es selbst zu tun. Keine Klasse kann dich wirklich unterrichten. Tatsächlich gibt es heutzutage zu viel Klassenlernen und zu wenig solide reale Kompetenz.

Es hat mich nicht so überzeugt, wie mein Code aussieht, oder mich gefragt, ob ich beim Eintritt in ein Unternehmen Funken verursachen oder vielleicht zu Open-Source-Projekten beitragen werde. Tatsächlich habe ich eher Angst davor, dass die Leute irgendwann meinen Code auschecken werden. Ist dies etwas Normales, das ein Programmierer durchläuft, oder sollte ich wirklich versuchen, meine Techniken zu ändern?

Meiner Meinung nach müssen Sie sich keine Gedanken darüber machen, was andere von Ihrem Code halten, wenn Sie sich auf objektive Qualitätsmessungen konzentrieren. Ist es

• Richtig?
• Verständlich?
• Wartungsfähig?
• Effizient?

Als erstes Prinzip sollte es immer Ihr Ziel sein, sich auf objektive Eigenschaften zu konzentrieren und nicht auf die Meinungen anderer. Sich auf die Meinungen anderer zu konzentrieren, ist der Weg zu Mittelmäßigkeit und, wie Sie erleben, zu Angst.

Der einzige Grund, sich mit den Meinungen anderer zu befassen, ist die Möglichkeit, sich sozial (oder in einem Arbeitsumfeld) gut in sie zu integrieren. Wenn Sie das Ziel haben, die objektiven Eigenschaften Ihrer Arbeit zu verbessern, müssen Sie sich nicht vor den Reaktionen anderer fürchten - es handelt sich nur um Gelegenheiten zum Lernen oder im schlimmsten Fall um praktische Details, mit denen Sie sich befassen müssen .

Sei dir selbst treu!! Lerne weiter und genieße, was du tust.

Sie erinnern mich an mich selbst, nachdem Sie studiert haben, um Software-Ingenieur zu werden. Wenn Sie ein Programmierer sein wollen, würde ich sagen, nehmen Sie eine Position. Sie müssen Ihren Code kommentieren, Komponententests schreiben, objektorientierten Code vollständig verstehen. Aber im Moment haben Sie keinen wirklichen Grund, dies zu tun. Solange Sie nur an kleinen persönlichen Projekten arbeiten. Wo Sie nur sich selbst antworten müssen. Sie werden als Entwickler nicht weiter wachsen.

Durch die Übernahme großer Projekte, an denen viele Menschen arbeiten, und die Beantwortung von Managementfragen wie "Ist diese Version fehlerfrei? Weil wir sie an den Kunden weitergeben werden." Sie werden als Programmierer / Ingenieur wachsen. Sie werden einige harte Schläge bekommen. Sie können die Dinge, die Sie erwähnt haben, wertvoller finden und Sie können neue Dinge finden, an die noch niemand gedacht hat. Du wirst wachsen.

Sogar mein College hat mir diese Dinge nicht beigebracht, obwohl sie es versucht haben.

Für Unit-Tests suchen Sie nach Test Driven Development.

Denken Sie zum Kommentieren an Code, den Sie nach Ihrem Ableben geschrieben haben. Und die Zeit, die andere Leute mit Reverse Engineering verbringen werden.

Für objektorientierte Sprachen. Verstehe es zumindest. Mit diesem Tool können Sie Probleme besser lesbar lösen.

Viel Glück: D

Kurz gesagt, ist der beste Weg zu lernen , im Allgemeinen mit jemandem hängen Sie lernen können , aus . Wenn Sie das Gefühl haben, dass Ihre Fähigkeiten nicht auf dem neuesten Stand sind, ist es das Beste, mit Leuten zusammen zu sein, die besser sind als Sie. Sicher viel besser als sich zurückzuziehen und weiter zu isolieren.

Ich denke jedoch, dass Sie ein sehr vereinfachtes und irreführendes Bild zeichnen. Bei weitem nicht alle "professionell unterrichteten" Programmierer sind wirklich gut. Nur weil sie etwas tun, heißt das noch lange nicht, dass es das Richtige ist.

Und vieles (aber nicht alles) von dem, was du sagst, hört sich wirklich so an, als ob du derjenige bist, der ihnen einen oder zwei Tricks beibringen könnte .

Ich lehne mich mehr an die funktionale Seite als an OO, aber ich sehe die Verwendung von OO, wenn etwas als abstrakte Entität sinnvoller wäre.

Das hört sich für mich sehr gut an. Die besten Programmierer sind diejenigen, die das richtige Werkzeug für den Job verwenden. Ich würde immer jemanden auswählen, der beide Paradigmen kennt, und jeden von ihnen dort verwenden, wo es Sinn macht, wenn jemand religiös nur ein einziges Paradigma verwendet.

Als nächstes gehe ich auch den einfachen Weg, wenn ich etwas tue. Im Gegensatz dazu ist der Code, den ich von professionellen Programmierern sehe, manchmal kompliziert.

Auch hier ist die Einfachheit gut . Machen Sie nicht Ihren Code komplex , bis sie benötigt werden komplexer. Einige Leute haben neigen dazu , Dinge Komplex aus fehlgeleiteten Vorstellung von Eleganz zu machen, oder weil „wir werden diese zusätzliche Funktionalität benötigen später“. Im Allgemeinen ist es besser, das Einfachste zu tun, um Ihr Problem zu lösen.

Ich benutze viele Verschlüsse. Gut. Deshalb sind sie da. Sie erschrecken einige Leute, die in den 1990ern und Javas veraltetem Quasi-OOP-Modell feststeckten, aber das ist wirklich ihr Problem.

Und schließlich bin ich nicht der beste Kommentator.

Was und wie zu kommentieren ist, ist höchst subjektiv. Es gibt dort kein wirkliches "Richtig" oder "Falsch", aber wenn Sie an einem Team arbeiten, ist es wichtig, Code zu schreiben, den das gesamte Team und nicht nur der Autor des Codes verstehen kann. Und manchmal müssen Kompromisse eingegangen werden, um dem Codierungsstil des Teams zu entsprechen. Das bedeutet nicht, dass Sie mehr Kommentare schreiben sollten, sondern nur, dass Sie und Ihr Team sich darauf einigen müssen.

Ich höre professionell ausgebildete Programmierer über Dinge wie Unit-Tests. Etwas, das ich noch nie benutzt habe, also habe ich keine Ahnung, was sie sind oder wie sie funktionieren.

Nun, frag sie. :) Das Testen Ihres Codes ist unerlässlich, und Unit-Tests sind hierfür ein beliebtes und nützliches Tool.

Viele, viele Unterstriche "_", die nicht wirklich mein Geschmack sind.

Wie beim Kommentieren ist das subjektiv und hängt von der Sprache ab. In C und C ++ lowercase_with_underscoresist dies eine weit verbreitete Namenskonvention. In vielen anderen Sprachen wird so gut wie nie ein Unterstrich angezeigt. Aber am Ende des Tages ist es wirklich nicht wichtig. Ob eine Funktion aufgerufen wird write_to_logoder WriteToLognicht, wird einen Unterschied machen. Jemand muss es einfach aufsaugen und sich an das halten, was das Team dort vereinbart hat.

Ich weiß nichts über MVC, aber ich habe viel darüber gehört, mit Dingen wie backbone.js. Ich denke, es ist eine Möglichkeit, eine Anwendung zu organisieren. Es verwirrt mich nur, weil ich inzwischen meine eigenen Organisationsstrukturen aufgebaut habe.

Hören Sie wie bei Unit-Tests nie auf zu lernen. Sie arbeiten mit Menschen zusammen, die Dinge wissen, die Sie nicht wissen und die einen anderen Hintergrund haben als Sie. Voneinander lernen Es gibt eindeutig Dinge, die Sie ihnen beibringen können, aber es gibt auch Dinge, die Sie nicht kennen oder von denen Sie noch nie etwas gehört haben und die sie Ihnen beibringen können. Das bedeutet nicht, dass Sie (oder sie) ein schlechter Programmierer sind. Das bedeutet, dass ein guter Programmierer danach strebt, sich zu verbessern und von anderen zu lernen.

Vollständige OO-Programmierung hinterlässt wirklich einen schlechten Geschmack in meinem Mund

Das Gleiche gilt hier, und ich bin das, was Sie als "professionell ausgebildet" bezeichnen würden (ein CS-Abschluss). Menschen, denen das Programmieren beigebracht wurde, unterscheiden sich ebenso wie Autodidakten. Es hört sich so an, als würden Sie mit einigen zusammenarbeiten, die wirklich ein paar neue Tricks lernen müssen.

Tatsächlich habe ich eher Angst davor, dass die Leute irgendwann meinen Code auschecken werden. Ist dies etwas Normales, das ein Programmierer durchläuft, oder sollte ich wirklich versuchen, meine Techniken zu ändern?

Beide. Natürlich ist es beängstigend, wenn andere sehen (und beurteilen), was Sie gemacht haben. Aber es ist auch sehr lehrreich. Sie können Ihnen sagen, was sie anders gemacht hätten oder warum sie es anders gemacht hätten. Sie können Ihnen helfen, sich zu verbessern, und sie können auch selbst etwas lernen. Zeigen Sie ihnen Code, der ein Problem besser löst, als es ihre "bevorzugte" Lösung getan hätte, und hoffentlich gehen sie "oh, das ist ordentlich. Woher wussten Sie, dass Sie das tun? Wie nennen Sie das? Ich sollte diese Technik selbst verwenden "

Dies ist keine vollständige Antwort, Sie haben bereits mehrere gute. Es gibt jedoch einige Punkte, die für mich etwas verwirrend wirken und nicht angesprochen wurden.

Es ist eine Mischung aus mehreren Dingen, die ich tue. Ich neige dazu, mehrere Programmierparadigmen miteinander zu verschmelzen. Wie funktional und OO. Ich lehne mich mehr an die funktionale Seite als an OO, aber ich sehe die Verwendung von OO, wenn etwas als abstrakte Entität sinnvoller wäre. Wie ein Spielobjekt.

Für mich sieht es aus wie Sie sind verwirrend deklarative vs zwingend notwendig , Programmierung, anstatt Functional Vs objektorientierte Programmierung. Wenn Sie meinen, dass Sie sich zur deklarativen Programmierung und nicht zum Imperativ neigen, dann ist das eine gute Sache. Declarative versucht, Nebenwirkungen zu entfernen, die das Verständnis Ihres Codes erleichtern sollen.

Moderne Programmiersprachen unterstützen oft deklaratives Programmiermodell. In C # führt die Verwendung von Linq beispielsweise zu einem deklarativen Stil, da Sie nicht angeben, wie Sie das Gewünschte erhalten sollen. du sagst nur was du willst.

Vollständige OO-Programmierung hinterlässt wirklich einen schlechten Geschmack in meinem Mund, aber das scheint das zu sein, was JEDER andere streng benutzt.

Moderne Sprachen sind oft Multi-Paradigma-Sprachen. Es ist selten, dass jemand eine "reine" Sprache verwendet. Viele funktionale Sprachen unterstützen Objekte und Nebenwirkungen. Als objektorientiert eingestufte Sprachen legen oft nicht die Einschränkung auf, dass alles ein Objekt ist.

Was meinst du mit vollständiger OO? Ich habe noch nie an "reinem" OO-Code gearbeitet. Vielleicht können Sie uns etwas genauer erklären, was Sie nicht mögen. Eine Illustration aus einem Open Source-Projekt könnte hilfreich sein.

OO-Programmierungen bieten uns viele Funktionen zur Unterstützung von Dingen wie: Datenabstraktion, Kapselung, Messaging, Modularität, Polymorphismus und Vererbung. Wenn ich mir eine Codebasis anschaute, die das nicht ausnutzte, würde das einen schlechten Geschmack in meinem Mund hinterlassen.

Kurze Antwort: ja.

Sich selbst zu unterrichten ist fast alles gut.
Filtern mit gutem Verstand, guter Rat.

WRT lernen professionelles Programmieren, ja.
Woran denkst du?
Konferenzen, Seminare, Zertifizierungen, ein Abschluss?
Jeder hat einen Kosten / Nutzen.
Wenn der ROI gut ist und Sie über die Ressourcen verfügen, entscheiden Sie sich dafür.

Wiegen Sie die Beratung zu den Graden unter Berücksichtigung der Quelle ab: Menschen mit / ohne sie haben berechtigte Interessen.
Sprechen Sie mit jeweils einem halben Dutzend.

Ist die Wissenschaft von der Industrie isoliert? Häufig.
Ist ein Abschluss wertlos? Dollarmäßig schwer zu argumentieren.
Absolventen verdienen fast immer mehr Geld, aber achten Sie auf College-Darlehen.

Wissensmäßig? Vielleicht.
Wenn Sie die Schule hassen, werden Sie nicht mehr herausholen, als Sie hineingesteckt haben.

Wenn Sie der Meinung sind, dass ein Abschluss für Sie ein würdiges Ziel ist, ist dies wahrscheinlich auch der Fall.

Erfahren Sie mehr über das Studienprogramm, die Kosten und die Umwelt. Stellen Sie sicher, dass Sie Interesse, Engagement, Zeit und Ressourcen haben. Sie sind wahrscheinlich dreizehn Jahre zur Schule gegangen. Was sind also noch vier? Sie sind am teuersten, und die Hauptperson, auf die Sie sich verlassen können, um sie zum wertvollsten zu machen, sind Sie.

Kosten können ziemlich beängstigend sein, aber sie erzählen nur einen Teil der Geschichte, weil es viele Zuschüsse und Stipendien für Verdienste, Bedürfnisse und hundert andere Gründe gibt.

Wenn Sie gehen, wählen Sie kluge Profis und Knospen.

Zweite Frage - Kann ich meinen eigenen Stil verwenden?

Sie haben zwei Fragen.

Das erste steht in deinem Titel. Bitte sehen Sie meine frühere Antwort.

Der zweite Teil wird in etwa fünf Absätzen beschrieben, in denen Sie anhand der folgenden Punkte beschreiben, wie sich Ihr Stil vom professionellen Stil unterscheidet:

• 100% Autodidakt.
• Unterschiedlich in Technik und Organisation.
• Mischung aus funktional und objektorientiert.
• Unkompliziert.
• Viele Verschlüsse.
• Einige Kommentare.
• Keine Unit-Tests.
• Nur wenige Unterstriche.
• Kein MVC.
• Keine backbone.js.
• Keine Vorlagenanwendungen.

Zusammenfassend, ich denke, Sie fragen, ob es in Ordnung ist, dass Sie den Frank Sinatra-Ansatz verwenden - "Ich habe es auf meine Weise gemacht." Ich spüre Ambivalenz, wenn Sie den Code anderer als professionell bezeichnen, aber Sie sind nicht dabei. Stil ist ein persönliches Problem, und die Debatte darüber, was guter Code ist, ist endlos und oft eine Zeitverschwendung. Einige Probleme können einfacher sein, wenn Ihre Gruppe eine schriftliche Kodierungskonvention verwendet. Bitte checken sie aus:

http://en.wikipedia.org/wiki/Coding_conventions

Es gibt eine Etikette, um den Code eines anderen zu töten, und das ist eine andere Sache, an der Sie mit Ihrem Team arbeiten sollten. Zieh deine dicke Haut an und hoffe, sie sind nicht zu brutal, aber was auch immer du tust, geh nicht in den Krieg.

Sie äußerten sich besorgt darüber, dass andere Ihren Code sehen könnten. Machen Sie sich bereit, denn sie werden es nicht nur sehen, sondern auch neu schreiben und Ihnen sagen, was mit Ihrem Stil nicht stimmt. Ihre Mitarbeiter können flexibel oder starr sein. In beiden Fällen empfehle ich, den Code für den Stil nicht umzuschreiben oder jeden Punkt des Stils zu einer Aushandlung zu machen.

Gründe für einen einheitlichen Code (und eine einheitliche Schulung) sind, die Geschwindigkeit und Produktivität der Entwicklung zu steigern und das Erlernen von Best Practices in gewisser Weise zu institutionalisieren. Probleme wie camelCase oder use_underbars können trivial und kleinlich erscheinen, aber die Konsistenz hat Vorteile.

Seien Sie offen für Unit-Tests und testgetriebene Entwicklungen. Wenn Sie alleine sind und keine Projekte gegen Bezahlung durchführen, ist dies eher ein Hobby. Deine Sachen müssen sich nicht mit dem vermischen, was andere Leute tun. Wenn Ihr Code abstürzt, ist das keine große Sache. Wenn Sie jedoch in ein Team involviert sind, kann der von Ihnen geschriebene Code das gesamte Team beeinflussen, insbesondere, wenn es an Kunden geht.

Wenn Ihr Team MVC verwendet, informieren Sie sich bitte darüber, hoffentlich aus denselben Quellen, auf die sie verweisen. Methoden zur Strukturierung von Programmen können einen großen Unterschied machen, wie experimentell gezeigt wurde. Nehmen Sie wieder das Beispiel und die Führung Ihres Teams.

Wenn Ihr Team backbone.js verwendet, verwenden Sie es auch. Ihr Team ist wie Enten, die in Formation fliegen. Durch Aneinanderreihen verbrauchen sie weniger Energie, werden sicherer und kommen effektiver ans Ziel. Die Analogie bricht zusammen, wenn Sie sehr viel Druck ausüben, aber die Verwendung gemeinsamer Tools, Techniken und die Ausrichtung hinter den Entscheidungen des Teams hat große Vorteile.

Der gegebene Rat ist ziemlich nützlich, aber ich versuche mich daran zu erinnern, dass mein Hauptziel darin besteht, "funktionierende Software" zu erstellen, die für meine Benutzer nützlich ist. Mein Publikum ist normalerweise NICHT eine Gruppe von Programmierern - es sind Geschäftsleute, die bereit sind, Geld für eine automatisierte Lösung zu bezahlen (Benutzer interessieren sich nicht für OO-Methoden, Frameworks, Komponententests, Codekommentare usw.) aufgelegt.)

Ich fand die Ideale des Agilen Manifests in meiner Karriere nützlich (www.agilemanifesto.org)

• Individuen und Interaktionen über Prozesse und Werkzeuge
• Arbeitssoftware über umfangreiche Dokumentation
• Zusammenarbeit der Kunden bei Vertragsverhandlungen
• Reagieren, um nach einem Plan umzuschalten

Ich beziehe mich vollständig auf diese Frage. Ich habe genau die gleichen Gefühle und einen sehr ähnlichen Hintergrund (aber nicht genau den gleichen). Ich sollte professionell (oder eher akademisch) ausgebildet sein, damit ich etwas über OO-Programmierung usw. weiß. Programmierung war nicht mein Hauptthema, aber ich habe es getan. Ich habe OO in einigen meiner Kurse gelernt und überhaupt keinen Grund dafür verstanden. Tatsächlich war das einzige Mal, dass ich OO verstand, als ich kommerzielle Arbeit leistete und von zwei großartigen Mentoren dazu gezwungen wurde.

Ich bin mir sicher, dass mein Professor ebenso brillant war, aber Sie sehen den wirklichen Vorteil in der Praxis in einem kommerziellen Umfeld im Vergleich zu funktionaler Programmierung, aber Sie haben keine Chance, ihn in einem Kurs zu sehen, der darauf ausgelegt ist, innerhalb weniger Monate zu laufen und zu unterrichten und zu enden . Ich hatte noch keine Gelegenheit, an MVC-basierten Strukturen zu arbeiten, aber ich bin mir sicher, dass dies auch so sein wird, dh ich würde die Konzepte aus einem Buch übernehmen können, aber ich werde den Nutzen verstehen, wenn ich sehe, dass es in einem verwendet wird kommerzielles Umfeld. Und ich stimme Ihnen voll und ganz zu, warum Sie OO und MVC und jede andere komplexe Struktur verwenden sollten, wenn Sie ein Problem auf einfachere Weise lösen können. Mein Rat ist, nicht schüchtern zu arbeiten, weil Sie dadurch einer anderen Situation ausgesetzt werden und Sie die gleichen Dinge in einem anderen Licht verstehen können.

Klar, ich habe Syntax und Konzepte in meinem akademischen Hintergrund gelernt, aber in der Geschäftswelt habe ich angefangen, Programmieren zu lernen.