Seguire il percorso di ciò che conosco, quindi provare a implementare pratiche di codifica corrette o iniziare con buone pratiche di codifica e provare a farsi strada?

Prima di tutto, voglio dire che sono abituato a fare la Programmazione procedurale come il mio hobby: sto cercando di imparare OOP in un paio di lingue e capire la teoria , ma non la pratica.

Ho un progetto per animali domestici che volevo costruire, in particolare in PHP con un backend di database (non mi importava quale). Il mio motivo principale era che l'app potesse essere utilizzata su qualsiasi dispositivo, quindi una WebApp sembrava la scelta logica.

Capisco che per creare WebApp PHP gestibili, dovrebbe usare OOP, Classi, Frameworks, Librerie, ecc. Sembra logico, quindi decido di provare alcuni di quelli popolari. Tuttavia, dopo un intero fine settimana in cui li ho solo provati e ho provato a superare i tutorial, sono rimasto confuso e frustrato nel tentativo di adattare i tutorial al mio piccolo progetto.

Ho deciso, principalmente per una dimostrazione di concetto, di creare l'app in un altro programma (Microsoft Access) e ho raggiunto i miei obiettivi principali in solo un paio d'ore - tranne la web part.

La mia domanda è: dovrei seguire il percorso di ciò che conosco, quindi provare a implementare le pratiche di codifica corrette, oppure dovrei iniziare con le buone pratiche di codifica e cercare di farmi strada? Per questo progetto, vorrei che fosse Open Sourced su GitHub, quindi sarei aperto ad altre persone che usano e modificano il mio codice, ma so anche che se il codice è scritto male, sarebbe difficile raccogliere programmatori per aiutare.

Le migliori pratiche sono principalmente suggerimenti e proposte raccolti dall'esperienza per rendere i progetti più facili da * abilitare.

Gli aspetti chiave di questo IMHO sono la parte dell'esperienza. Sebbene queste migliori pratiche siano buoni modi per le persone con più esperienza di condividerle con i principianti, penso che sia ancora necessario un livello minimo di esperienza per capire veramente cosa rende questa è una buona pratica. Fare altrimenti equivale a seguirli ciecamente come lo stato di diritto che alla fine penso rallenterà il tuo apprendimento mentre lasci lentamente che gli altri pensino per te.

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

Qualunque cosa prima di quel punto è vaporware, un frutto della tua immaginazione. Solo una volta che hai qualcosa che funziona puoi davvero valutare se è lento, difficile da mantenere, difficile da testare ecc. Il processo per farlo funzionare esporrà cose per le quali, forse, esiste una migliore pratica che ti aiuterebbe a ripensarlo in modo da facilitare il raggiungimento di tale 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 alcune parti 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 sono proprio sotto il naso tutto il tempo ma non erano pronti a inizia la loro padronanza.

Allo stesso tempo, continua a leggere su nuovi modi di fare le cose. Leggi queste best practice e prova a vedere se si applicano a qualcosa che trovi difficile nel tuo progetto. In caso contrario, ricorda la loro esistenza e rivisitali di volta in volta. Sii curioso. Con il passare del tempo vedrai che le osservazioni fatte sopra fanno semplicemente clic sulle 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 semplici consigli da parte di persone che hanno sofferto e imparato un modo per renderlo più semplice. Diamine potresti anche non essere d'accordo con alcuni di essi e vedere che la tua strada funziona davvero meglio per te. Ma senza sapere che stai camminando alla cieca.

in bocca al lupo

TL; DR

Non saprai mai tutto. C'è praticamente sempre più profondità e ampiezza attorno a ogni singola "cosa" che puoi sapere. Impara mentre vai. Applica le "migliori pratiche" che ritieni siano rilevanti adesso. Fare errori. Cerca solo di evitare di commettere errori davvero costosi . Trova 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 limiti delle tue conoscenze, è fantastico! Insegui i bordi! Continua a imparare! Ma tieni presente che potresti imparare e analizzare per sempre .

Costruisci qualcosa.

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

Continua a spingere i confini delle tue conoscenze / abilità. Si dovrà fare degli errori. Puoi imparare da loro. Ma non devi essere sconsiderato .

Il tempo impiegato per trovare e lavorare con sviluppatori e tutor più esperti dovrebbe aumentare in proporzione al valore aziendale e al profilo di rischio del progetto.

Se stai creando una piccola CLI per te stesso : fallo funzionare come preferisci.

Se stai scrivendo il portale web di una banca: circondati di sviluppatori di grande esperienza.

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

Le "Pratiche" sono promosse come "migliori pratiche" quando si ritiene che riescano a realizzare X in almeno alcuni casi. Qualcuno riconosce i benefici della Pratica A per ottenere il 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, generalmente perdiamo di vista il motivo per cui alcune pratiche sono "buone pratiche" e altre sono o "antipattern" o "puzzolenti".

Il problema è che una "best practice" non è mai egoistica. "Antipatterns" non sono in realtà diabolici in sé e per sé. E anche una "puzza" viene a volte solo dal marciume. A volte, quella puzza è solo un formaggio delizioso e delizioso ...

Non si praticano cose come "iniezione di dipendenza" (DI) perché "iniezione di dipendenza" è intrinsecamente preziosa per l'azienda. Non è nemmeno lontanamente essenziale per costruire un prodotto funzionante. Realizza qualcosa che potresti desiderare nel tuo prodotto finale. Ma potrebbe anche richiedere più tempo per il tuo lavoro senza alcun vantaggio ...

Hmm ...

Quindi, dovresti seguire le "migliori pratiche?" Anche se non li capisci? ... Err ... sì. Voglio dire di no. Ma si. Ma solo quelli che si applicano davvero a te, al tuo software e al suo scopo.

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

I principi, i modelli e le pratiche non sono scopi finali.

La corretta e corretta applicazione di ciascuno è quindi ispirata e limitata da uno scopo superiore e più finale. Devi capire perché stai facendo quello che stai facendo!

(Il POAP non è esente dal POAP.)

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

E, una volta rilasciato il prodotto, puoi riflettere se DI (o qualsiasi altra cosa) sia stato davvero vantaggioso. In tal caso, spiega perché per iscritto. Altrimenti, spiega perché per iscritto ...

Lettura bonus / Abbastanza rilevante:

La paralisi dell'analisi è una cosa. Devi analizzare e imparare; ma devi anche fare le cose. Equilibrio.

Potresti sempre sentirti un programmatore di cowboy .

^{* In realtà si commettono errori male se nulla degno di nota. Ma, sei umano, presumo. Quindi ti perdoniamo in anticipo ... O almeno io. Può essere. ... Bene ... Vedremo.}

La mia domanda è: dovrei seguire il percorso di ciò che conosco, quindi provare a implementare pratiche di codifica corrette, o dovrei iniziare con le buone pratiche di codifica e cercare di farmi strada?

Forse fai del tuo meglio ma spedisci ancora qualcosa? Esistono due forze diverse tra il modo in cui gli utenti valutano la qualità e il fascino di un prodotto e il modo in cui gli sviluppatori dietro di esso valutano la qualità del codice. Cerca di rendere queste due forze il più armoniose possibile. Concentrarsi troppo su uno a spese 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 è confusa ... 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 pochissimo tempo. Ho creato un intero sistema di contabilità in Access una volta. Ma l'hai detto tu stesso: non puoi portare un'applicazione del genere sul Web senza una riscrittura e gli strumenti di cui hai bisogno sono davvero diversi.

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

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

Ecco perché penso che tu abbia posto una falsa dicotomia. Nessuno impara prima tutte le "migliori pratiche". Li imparano mentre vanno. Ma per essere produttivo in qualsiasi linguaggio OOP, penso che dovrai conoscere un po 'di OOP, o almeno come funzionano fondamentalmente le lezioni.

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 in gran parte affidate allo sviluppatore, il che significa che PHP non ti aiuterà a scrivere programmi "buoni". Questo non è necessariamente una cosa negativa, 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 compito. Una cosa del genere non esiste nell'ingegneria del software.

Si noti inoltre che ciò che le persone affermano di essere buone pratiche a volte è discutibile. Ho visto spesso sviluppatori inesperti adottare 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.

Articoli sul web, dichiarazioni di esperti del settore e consigli di colleghi senior possono essere sbagliati. L'ho visto molto.

Pertanto ti consiglio di applicare la soluzione più semplice che risolva il tuo problema. Probabilmente, questo includerà l'uso di uno dei quadri 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, capire perché sono consigliate alcune tecniche. Ad esempio, OOP riguarda l'incapsulamento. È possibile 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 sottrarre il database. Qui, l'essenza di questo modello è diventare indipendente dall'archivio dati concreto ed esporre un'interfaccia più semplice a livelli più alti di codice. Ma se non hai bisogno di questi vantaggi, 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 un buon codice spesso sia divertente con cui lavorare. È divertente perché puoi lavorare sui requisiti effettivi invece di occuparti delle preoccupazioni relative all'infrastruttura. Se scopri che quello che stai facendo è un lavoro troppo grugnito, probabilmente hai scelto un set di schemi sbagliato.