Segui il percorso di ciò che so, quindi cerca di implementare le corrette pratiche di codifica, o inizia con buone pratiche di codifica e cerca di farmi strada?

Le best practice sono principalmente suggerimenti e proposte raccolte dall'esperienza per contribuire a rendere i progetti più facili * in grado.

Gli aspetti chiave di questo IMHO sono la parte dell'esperienza. Sebbene queste buone pratiche siano un buon modo per le persone con più esperienza da condividere con i principianti, penso che sia ancora necessario un livello minimo di esperienza per capire veramente cosa rende questa best practice. Fare altrimenti equivale a seguirli ciecamente come lo stato di diritto che alla fine penso rallenterà il tuo apprendimento mentre lentamente permetti agli altri di fare il pensiero per te.

In ogni caso, la cosa più importante in assoluto in un progetto software per me è ... beh ... finiscila, spediscilo ... in breve, fallo funzionare!

Qualcosa prima di quel punto è vaporware, un frutto della tua immaginazione. Solo una volta che hai qualcosa che funziona puoi valutare veramente se è lento, difficile da mantenere, difficile da testare ecc. Il processo per farlo funzionare esporrà cose per le quali, forse, esiste una buona pratica che ti aiuterà a ripensarla in un modo che renda più facile raggiungere questo obiettivo.

Quindi sì, inizia con quello che sai prima, prendi nota delle cose che fai che sono difficili. Quando colpisci un muro fai un passo indietro e guarda quel muro, scopri di cosa è fatto. In moltissimi casi ti renderai conto che TU sei la radice del problema. La tua mancanza di comprensione di una parte del problema che stai cercando di risolvere, la tua mancanza di conoscenza su come puoi sfruttare meglio gli strumenti che hai o la tua ignoranza di altri strumenti che hai sotto il naso tutto il tempo ma non erano pronti a inizia la loro maestria.

Allo stesso tempo, continua a leggere nuovi modi di fare le cose. Leggi queste best practice e prova a vedere se si applicano a qualsiasi cosa tu stia trovando difficile nel tuo progetto. In caso contrario, ricorda la loro esistenza e rivisitali di volta in volta. Stai curioso Col tempo vedrai che le osservazioni fatte sopra fanno semplicemente clic in modo naturale con le conoscenze acquisite qui.

Infine, sperimenta ciò che hai imparato e vedi se rende le cose più semplici. continua a questo e alla fine leggerai le migliori pratiche per quello che sono. Solo un semplice consiglio da parte di persone che hanno sofferto e imparato un modo per renderlo più facile. Diamine, potresti persino non essere d'accordo con alcuni di loro e vedere che la tua strada funziona davvero meglio per te. Ma senza conoscenza stai solo camminando alla cieca.

buona fortuna

TL; DR

Non lo saprai mai tutto. C'è praticamente sempre più profondità e ampiezza attorno a ogni singola "cosa" che puoi conoscere. Impara mentre vai. Applica le "migliori pratiche" che ritieni pertinenti ora. Fai errori. Cerca solo di evitare di commettere errori costosi . Trova i mentori se il tuo progetto potrebbe portare a costosi errori.

E ora la lunga risposta ...

1. "Il software di lavoro è la misura principale del progresso." ( Manifesto agile )

Se riesci a vedere i bordi della tua conoscenza, è fantastico! Perseguire i bordi! Continua ad imparare! Ma tieni presente che potresti imparare e analizzare per sempre .

Costruisci qualcosa.

2. Impara e commetti errori; ma non fare "cattivi". *

Continua a spingere i confini delle tue conoscenze / abilità. farai errori. Puoi imparare da loro. Ma non è necessario essere spericolato .

Il tempo che passi a trovare e a lavorare con sviluppatori e mentori più esperti dovrebbe aumentare in proporzione al valore aziendale e profilo di rischio del progetto.

Se stai facendo un po 'di CLI per te : Funziona come vuoi.

Se stai scrivendo il portale web di una banca: Circondati di sviluppatori molto esperti

3. Le "migliori pratiche" dovrebbero essere scritte tra virgolette e pronunciate con un occhiolino.

Le "Pratiche" sono promosse alle "migliori pratiche" quando si osserva che hanno successo in raggiungere X in almeno alcuni casi. Qualcuno riconosce il beneficio di Pratica A per ottenere Beneficio X e dichiara che la pratica è una "best practice" su Internet. Altri sono d'accordo - spesso per una buona ragione. Ma da quel momento in poi, di solito perdiamo di vista perché alcune pratiche sono "best practice" e altre sono "antipatterns" o "puzzolente".

Il problema è che una "migliore pratica" non è mai egoistica. "Antipattern" non sono in realtà diabolici di per sé. E persino un "puzzo" solo a volte viene da rot. A volte, quella puzza è solo un formaggio delizioso e delizioso ...

Non pratichi cose come "injection dependency" (DI) perché "dependency injection" è intrinsecamente prezioso per il business. Non è neanche lontanamente essenziale costruire un prodotto funzionante. Realizza qualcosa che vorresti nel tuo prodotto finale. Ma potrebbe anche solo rendere il tuo lavoro più lungo senza alcun beneficio ...

Hmm ...

Quindi, dovresti seguire le "migliori pratiche?" Anche se non li capisci? ... Err ... si. Intendo no. Ma si. Ma solo quelli che si applicano veramente a te, al tuo software e al suo scopo.

Invoca POAP ! ^{(Sì. Il mio blog.)}

Principles, patterns, and practices are not final purposes.

The good and proper application of each is therefore inspired and constrained by a superior, more final purpose. You need to understand why you're doing what you're doing!

(The POAP is not exempt from the POAP.)

Quindi, potresti non comprendere appieno ogni sfumatura di DI, per esempio. Ma, se capisci l'intento, saprai se "dovresti" usare DI, e capirai implicitamente DI meglio.

E, una volta rilasciato il prodotto, è possibile riflettere sul fatto che DI (o qualsiasi altra cosa) sia davvero vantaggioso. In tal caso, articolare il motivo per iscritto. In caso contrario, articolare il motivo per iscritto ...

Lettura bonus / Interessante:

La paralisi delle analisi è una cosa. Devi analizzare e imparare; ma devi anche fare delle cose. Balance.

Potresti sentirti sempre un coder di cowboy .

^{* In realtà farà errori sbagliati se fai qualcosa di degno di nota. Ma tu sei umano, suppongo. Quindi ti perdoniamo prima del tempo ... O almeno lo faccio. Può essere. ... Beh ... Vedremo.}

My question is, should I follow the path of what I know, then try to implement correct coding practices, or should I start with the good coding practices, and try to fudge my way through?

Forse fai del tuo meglio ma spedisci ancora qualcosa? Ci sono due diverse forze tra il modo in cui gli utenti valutano la qualità e il fascino di un prodotto e come gli sviluppatori dietro di esso valutano la qualità del codice. Cerca di rendere queste due forze il più armoniose possibile. Concentrarsi su uno troppo a scapito dell'altro è di solito il modo in cui si finisce con i percorsi più controproducenti.

Bene, prima di tutto, suggerirei che l'adozione di buone pratiche di codifica non sia di disturbo ... Il trucco è capire lo scopo di ogni pratica e come implementarla correttamente.

Gli ambienti di sviluppo rapido delle applicazioni sono seducenti, perché puoi fare molto in poco tempo. Ho creato un intero sistema di contabilità in Access una volta. Ma l'hai detto tu stesso: non puoi fare un'applicazione simile sul web senza una riscrittura, e gli strumenti di cui hai bisogno sono davvero diversi.

Ci sono motivi per cui nessuno usa più strumenti di progettazione visuale come Access o Visual Basic. Tendono ad isolarti dal codice che realizza veramente qualcosa. L'accesso è un ottimo strumento, ma richiede proprio quello che le applicazioni web sono specificamente progettate per evitare: installazione. La personalizzazione del suo aspetto può essere difficile; anche se non è necessario sul Web, un'applicazione di Access sarà sempre simile a qualsiasi altra applicazione di Access. La maggior parte delle persone che scrivono la loro prima applicazione Access non ne sa abbastanza per scrivere una buona applicazione e Access facilita la scrittura di una cattiva applicazione.

Quindi ora sei rassegnato ad apprendere una nuova tecnologia per ottenere la tua applicazione sul web. Dovresti costruirlo nel modo giusto fin dall'inizio? Ovviamente. Ma imparare un nuovo ambiente di sviluppo e la filosofia è come imparare qualsiasi altra cosa; devi metterlo da parte per un po 'per sistemare le cose.

Ecco perché penso che tu abbia posto una falsa dicotomia. Nessuno impara prima tutte le "migliori pratiche". Li imparano mentre vanno. Ma per essere produttivi in qualsiasi linguaggio OOP, penso che avrai bisogno di conoscere qualche OOP, o almeno come funzionano fondamentalmente le classi.

Per quello che vale, non credo che PHP sia la scelta migliore. PHP è attraente perché è "superficiale", il che significa che non devi sapere molto per scrivere un programma di lavoro. Le migliori pratiche sono lasciate in gran parte agli sviluppatori, il che significa che PHP non ti aiuterà a scrivere programmi "buoni". Questo non è necessario, ma significa che, come Access, potresti anche abbandonare PHP per una piattaforma più solida.

Considera OOP come un altro modello che puoi applicare al momento giusto. OOP non è un framework in grado di risolvere metodicamente ogni attività. Una cosa del genere non esiste nell'ingegneria del software.

Nota anche che le persone che affermano di essere buone pratiche sono a volte discutibili. Ho visto spesso sviluppatori inesperti che adottano schemi di programmazione molto complicati che non erano necessari per il problema dato. La complessità del codice dovrebbe essere appropriata per la complessità del problema. La semplicità è un valore importante.

Gli articoli sul web, le dichiarazioni degli esperti del settore e i consigli dei colleghi anziani possono essere errati. Ho visto molto questo.

Pertanto ti consiglio di applicare la soluzione più semplice che risolva il tuo problema. Probabilmente, questo comprenderà l'uso di uno dei framework popolari nel tuo spazio. All'interno di questo vincolo puoi scegliere liberamente quale tipo di codice ti piace. Non pensare semplicemente che il loro modo di farlo sia appropriato per il tuo caso.

Inoltre, capisci perché si raccomandano alcune tecniche. Ad esempio, OOP riguarda l'incapsulamento. Puoi incapsulare in altri modi (le procedure riguardano anche l'incapsulamento).

Un esempio negativo: a volte le persone scrivono un livello di accesso ai dati per astrarre il database. Qui, l'essenza di questo modello è di diventare indipendenti dall'archivio dati concreto e di esporre un'interfaccia più semplice agli strati superiori di codice. Ma se non hai bisogno di questi benefici, non hai bisogno di un livello di accesso ai dati e puoi salvare il lavoro. Tuttavia, molti esperti raccomandano di fare sempre un DAL che è una raccomandazione errata.

Trovo che il buon codice spesso sia divertente con cui lavorare. È divertente perché puoi lavorare su requisiti reali invece di preoccuparti dell'infrastruttura. Se trovi che quello che stai facendo è un lavoro eccessivo, probabilmente hai scelto la serie sbagliata di schemi.