Folgen Sie dem Pfad dessen, was ich weiß, und versuchen Sie dann, korrekte Codierungspraktiken zu implementieren, oder beginnen Sie mit guten Codierungspraktiken und versuchen Sie, mich durchzuarbeiten?

Zunächst möchte ich sagen, dass ich es gewohnt bin, prozedurale Programmierung als mein Hobby zu betreiben - ich versuche, OOP in ein paar Sprachen zu lernen und die Theorie zu verstehen , nur nicht die Praxis.

Ich habe ein Haustierprojekt, das ich erstellen wollte, speziell in PHP mit einem Datenbank-Backend (egal welches). Mein Hauptgrund war, dass die App auf jedem Gerät verwendet werden konnte, daher schien eine WebApp die logische Wahl zu sein.

Ich verstehe, dass zum Erstellen wartbarer PHP-Webanwendungen OOP, Klassen, Frameworks, Bibliotheken usw. verwendet werden sollten. Dies klingt logisch, daher entscheide ich mich, einige der beliebtesten auszuprobieren. Nach einem ganzen Wochenende, in dem ich sie nur ausprobiert und versucht habe, durch die Tutorials zu kommen, bin ich sowohl verwirrt als auch frustriert, die Tutorials an mein kleines Projekt anzupassen.

Ich entschied mich hauptsächlich für einen Proof-of-Concept, die App in einem anderen Programm (Microsoft Access) zu erstellen, und erreichte meine Hauptziele in nur wenigen Stunden - mit Ausnahme des Webparts.

Meine Frage ist, soll ich dem Weg folgen , was ich weiß, dann versuche korrekte Codierung Praktiken zu implementieren, oder soll ich beginnen mit den guten Praktiken Codierung, und versuche , meinen Weg durch frisieren? Für dieses Projekt möchte ich, dass es Open Sourced auf GitHub ist, damit ich für andere Personen offen bin, die meinen Code verwenden und ändern, aber ich weiß auch, dass es schwierig ist, Codierer zu sammeln, um zu helfen, wenn der Code schlecht geschrieben ist.

Best Practices sind hauptsächlich Vorschläge und Vorschläge, die aus Erfahrung gesammelt wurden, um Projekte einfacher zu machen.

Der Schlüsselaspekt dieses IMHO ist der Erfahrungsteil. Obwohl diese Best Practices eine gute Möglichkeit für Leute mit mehr Erfahrung sind, sie mit Anfängern zu teilen, denke ich, dass man immer noch ein Mindestmaß an Erfahrung benötigt, um wirklich zu verstehen, was dies zu einer Best Practice macht. Wenn Sie etwas anderes tun, bedeutet dies, dass Sie ihnen blind als Rechtsstaat folgen. Ich denke, dies wird Ihr Lernen am Ende verlangsamen, wenn Sie andere langsam das Denken für Sie tun lassen.

In jedem Fall ist das absolut wichtigste, was ich in einem Softwareprojekt tun muss, um ... nun ... fertig zu werden, es zu versenden ... kurz gesagt, es funktioniert!

Alles vor diesem Punkt ist Vaporware, eine Erfindung Ihrer Fantasie. Nur wenn Sie etwas haben, das funktioniert, können Sie wirklich beurteilen, ob es langsam, schwer zu warten, schwer zu testen usw. ist. Der Prozess, in dem es funktioniert, wird Dinge aufdecken, für die es möglicherweise eine bewährte Methode gibt, die Ihnen beim Überdenken helfen könnte auf eine Weise, die es einfacher macht, dieses Ziel zu erreichen.

Beginnen Sie also mit dem, was Sie zuerst wissen, und notieren Sie sich die Dinge, die Sie schwer tun. Wenn Sie gegen eine Wand stoßen, treten Sie einen Schritt zurück und sehen Sie sich diese Wand an. Erfahren Sie, woraus sie besteht. In sehr vielen Fällen werden Sie feststellen, dass SIE die Wurzel des Problems sind. Ihr mangelndes Verständnis für einen Teil des Problems, das Sie lösen möchten, Ihr mangelndes Wissen darüber, wie Sie die vorhandenen Tools besser nutzen können, oder Ihre Unkenntnis anderer Tools, die Ihnen die ganze Zeit direkt unter der Nase liegen, aber noch nicht dazu bereit waren beginne ihre Meisterschaft.

Lesen Sie gleichzeitig weiter über neue Methoden. Lesen Sie diese Best Practices und versuchen Sie herauszufinden, ob sie für etwas gelten, das Ihnen in Ihrem Projekt schwer fällt. Wenn nicht, erinnern Sie sich an ihre Existenz und besuchen Sie sie von Zeit zu Zeit erneut. Bleib neugierig. Mit der Zeit werden Sie sehen, dass die oben gemachten Beobachtungen mit dem Wissen, das Sie hier erwerben, auf natürliche Weise klicken.

Experimentieren Sie zuletzt mit dem, was Sie gelernt haben, und prüfen Sie, ob dies die Dinge einfacher macht. Bleiben Sie dabei und irgendwann werden Sie die Best Practice für das lesen, was sie sind. Nur einfache Ratschläge von Menschen, die gelitten und gelernt haben, es einfacher zu machen. Zum Teufel können Sie sogar mit einigen von ihnen nicht einverstanden sein und sehen, dass Ihr Weg tatsächlich besser für Sie funktioniert. Aber ohne Wissen gehen Sie einfach blind.

Viel Glück

TL; DR

Du wirst nie alles wissen. Es gibt so ziemlich immer mehr Tiefe und Breite um jedes einzelne "Ding", das Sie kennen können. Lerne, wie du gehst. Wenden Sie die "Best Practices" an, die Ihrer Meinung nach jetzt relevant sind . Fehler machen. Versuchen Sie einfach, wirklich kostspielige Fehler zu vermeiden . Finden Sie Mentoren, wenn Ihr Projekt zu kostspieligen Fehlern führen kann.

Und jetzt die lange Antwort ...

1. "Arbeitssoftware ist das primäre Maß für den Fortschritt." ( Agiles Manifest )

Wenn Sie die Grenzen Ihres Wissens sehen können, ist das großartig! Verfolge die Kanten! Lerne weiter! Aber bedenken Sie , könnten Sie lernen und analysieren , für immer .

Baue etwas.

2. Lernen und Fehler machen; aber mach keine "schlechten". *

Überschreiten Sie weiterhin die Grenzen Ihres Wissens / Ihrer Fähigkeiten. Sie werden Fehler machen. Sie können von ihnen lernen. Aber Sie müssen nicht rücksichtslos sein .

Die Zeit, die Sie damit verbringen, erfahrenere Entwickler und Mentoren zu finden und mit ihnen zusammenzuarbeiten, sollte sich proportional zum Geschäftswert und zum Risikoprofil des Projekts erhöhen .

Wenn Sie eine kleine CLI für sich selbst erstellen : Lassen Sie sie funktionieren, wie Sie möchten.

Wenn Sie das Webportal einer Bank schreiben: Umgeben Sie sich mit sehr erfahrenen Entwicklern.

3. "Best Practices" sollten in Anführungszeichen geschrieben und mit einem Augenzwinkern gesprochen werden.

"Praktiken" werden zu "Best Practices" befördert, wenn festgestellt wird, dass sie zumindest in einigen Fällen erfolgreich X erreichen . Jemand erkennt den Nutzen von Praxis A für das Erreichen von Nutzen X an und erklärt es als "Best Practice" im Internet. Andere sind sich einig - oft aus gutem Grund. Aber von diesem Punkt an verlieren wir im Allgemeinen aus den Augen, warum einige Praktiken "Best Practices" und andere entweder "Antipatterns" oder "stinkend" sind.

Das Problem ist, dass eine "Best Practice" niemals eigennützig ist. "Antipatterns" sind an und für sich nicht wirklich teuflisch. Und selbst ein "Gestank" kommt nur manchmal von Fäulnis. Manchmal ist dieser Gestank nur ein schicker, köstlicher Käse ...

Sie üben keine Dinge wie "Abhängigkeitsinjektion" (DI), weil "Abhängigkeitsinjektion" für das Unternehmen von Natur aus wertvoll ist. Es ist nicht einmal aus der Ferne wichtig, ein funktionierendes Produkt zu erstellen. Es erreicht etwas , das Sie vielleicht in Ihrem Endprodukt wollen. Aber es könnte auch nur Ihre Arbeit machen länger dauern , keinen Nutzen ...

Hmm ...

Sollten Sie also "Best Practices" befolgen? Auch wenn Sie sie nicht verstehen? ... Äh ... ja. Ich meine nein. Aber ja. Aber nur diejenigen, die wirklich auf Sie und Ihre Software und deren Zweck zutreffen.

Rufen Sie das POAP auf ! ^{(Ja. Mein Blog.)}

Prinzipien, Muster und Praktiken sind keine endgültigen Zwecke.

Die gute und ordnungsgemäße Anwendung jedes einzelnen wird daher von einem überlegenen, endgültigeren Zweck inspiriert und eingeschränkt. Sie müssen verstehen, warum Sie das tun, was Sie tun!

(Das POAP ist nicht vom POAP ausgenommen.)

So können Sie beispielsweise möglicherweise nicht jede Nuance von DI vollständig verstehen. Wenn Sie jedoch die Absicht verstehen, wissen Sie, ob Sie DI verwenden sollten, und Sie verstehen DI implizit besser.

Und sobald Sie das Produkt veröffentlicht haben, können Sie darüber nachdenken, ob DI (oder was auch immer) wirklich vorteilhaft war. Wenn ja, artikulieren Sie warum schriftlich. Wenn nicht, artikulieren Sie warum schriftlich ...

Bonuslesung / Etwas relevant:

Analyse Lähmung ist eine Sache. Sie müssen analysieren und lernen; Aber Sie müssen auch Dinge erledigen. Balance.

Sie könnten sich immer wie ein Cowboy-Programmierer fühlen .

^{* Sie tatsächlich wird schlechte Fehler machen , wenn Sie etwas bemerkenswert machen. Aber du bist ein Mensch, nehme ich an. Also, wir vergeben dir im Voraus ... Oder zumindest ich. Vielleicht. ... Nun ... Wir werden sehen.}

Meine Frage ist, sollte ich dem Pfad meines Wissens folgen, dann versuchen, korrekte Codierungspraktiken zu implementieren, oder sollte ich mit den guten Codierungspraktiken beginnen und versuchen, mich durchzuarbeiten?

Vielleicht versuchen Sie Ihr Bestes, aber versenden Sie immer noch etwas? Es gibt zwei unterschiedliche Faktoren zwischen der Bewertung der Qualität und Attraktivität eines Produkts durch die Benutzer und der Bewertung der Qualität des Codes durch die dahinter stehenden Entwickler. Versuchen Sie, diese beiden Kräfte so harmonisch wie möglich zu gestalten. Wenn Sie sich auf Kosten des anderen zu sehr auf das eine konzentrieren, erhalten Sie normalerweise die kontraproduktivsten Routen.

Zunächst einmal würde ich vorschlagen, dass die Übernahme guter Codierungspraktiken kein Unsinn ist ... Der Trick besteht darin, den Zweck jeder Praxis zu verstehen und sie richtig zu implementieren.

Schnelle Anwendungsentwicklungsumgebungen sind verführerisch, da Sie in kürzester Zeit viel erledigen können. Ich habe einmal ein komplettes Buchhaltungssystem in Access erstellt. Aber Sie haben es selbst gesagt: Sie können eine solche Anwendung nicht ohne Umschreiben ins Web bringen, und die Tools, die Sie dort benötigen, sind wirklich unterschiedlich.

Es gibt Gründe, warum niemand mehr visuelle Designtools wie Access oder Visual Basic verwendet. Sie neigen dazu, Sie von dem Code zu isolieren, der wirklich etwas bewirkt. Der Zugriff ist ein gutes Werkzeug, erfordert jedoch genau das, was Webanwendungen speziell vermeiden sollen: Installation. Die Anpassung des Erscheinungsbilds kann schwierig sein. Selbst wenn Sie es im Web nicht benötigen, sieht eine Access-Anwendung immer wie jede andere Access-Anwendung aus. Die meisten Leute, die ihre erste Access-Anwendung schreiben, wissen nicht genug, um eine gute Anwendung zu schreiben, und Access macht es einfach, eine schlechte zu schreiben.

Jetzt haben Sie sich damit abgefunden, eine neue Technologie zu erlernen, um Ihre Anwendung ins Web zu bringen. Sollten Sie es von Anfang an richtig bauen? Na sicher. Das Erlernen einer neuen Entwicklungsumgebung und Philosophie ist jedoch wie das Erlernen einer anderen Sache. Sie müssen es für eine Weile aufhängen, um die Dinge richtig zu machen.

Deshalb denke ich, dass Sie eine falsche Zweiteilung gestellt haben. Niemand lernt zuerst alle "Best Practices". Sie lernen sie, während sie gehen. Aber um in jeder OOP-Sprache produktiv zu sein, müssen Sie einige OOP kennen oder zumindest wissen, wie Klassen grundlegend funktionieren.

Für das, was es wert ist, denke ich nicht, dass PHP Ihre beste Wahl ist. PHP ist attraktiv, weil es "flach" ist, was bedeutet, dass Sie nicht viel wissen müssen, um ein Arbeitsprogramm zu schreiben. Best Practices werden weitgehend dem Entwickler überlassen, was bedeutet, dass PHP Ihnen beim Schreiben "guter" Programme nicht helfen wird. Dies ist keine schlechte Sache, aber es bedeutet, dass Sie wie Access möglicherweise auch PHP für eine robustere Plattform fallen lassen.

Betrachten Sie OOP als ein weiteres Muster, das Sie zum richtigen Zeitpunkt anwenden können. OOP ist kein Framework, das jede Aufgabe methodisch lösen kann. So etwas gibt es in der Softwareentwicklung nicht.

Beachten Sie auch, dass das, was Menschen als gute Praktiken bezeichnen, manchmal fraglich ist. Ich habe oft gesehen, dass unerfahrene Entwickler sehr komplizierte Programmiermuster anwenden, die für das gegebene Problem nicht notwendig waren. Die Komplexität des Codes sollte der Komplexität des Problems angemessen sein. Einfachheit ist ein wichtiger Wert.

Artikel im Internet, Aussagen von Branchenexperten und Ratschläge von älteren Kollegen können durchaus falsch sein. Ich habe das viel gesehen.

Daher empfehle ich Ihnen, die einfachste Lösung anzuwenden, die Ihr Problem löst. Dies umfasst wahrscheinlich die Verwendung eines der beliebtesten Frameworks in Ihrem Bereich. Innerhalb dieser Einschränkung können Sie frei wählen, welche Art von Code Sie mögen. Denken Sie nicht einfach, dass ihre Vorgehensweise für Ihren Fall angemessen ist.

Verstehen Sie auch, warum bestimmte Techniken empfohlen werden. Bei OOP geht es beispielsweise um die Kapselung. Sie können auf andere Weise kapseln (bei Verfahren geht es auch um Kapselung).

Ein negatives Beispiel: Manchmal schreiben Leute eine Datenzugriffsschicht, um die Datenbank zu abstrahieren. Hier besteht die Essenz dieses Musters darin, unabhängig vom konkreten Datenspeicher zu werden und eine einfachere Schnittstelle für höhere Codeschichten bereitzustellen. Wenn Sie diese Vorteile jedoch nicht benötigen, benötigen Sie keine Datenzugriffsschicht und können die Arbeit speichern. Viele Experten empfehlen jedoch, immer eine DAL durchzuführen, was eine falsche Empfehlung ist.

Ich finde, dass es oft Spaß macht, mit gutem Code zu arbeiten. Es macht Spaß, weil Sie an den tatsächlichen Anforderungen arbeiten können, anstatt sich um Infrastrukturprobleme zu kümmern. Wenn Sie feststellen, dass das, was Sie tun, zu viel Grunzarbeit ist, haben Sie wahrscheinlich die falschen Muster ausgewählt.