Le migliori pratiche di codifica devono sempre essere utilizzate [chiuso]

Quando si codifica un software, l'architettura dovrebbe sempre essere la migliore prassi o pratica pratica per quanto riguarda l'applicazione in costruzione?

Se sto sviluppando un'applicazione Web di due pagine che potrebbe durare 5 anni e avere 2 miglioramenti in quei 5 anni, dovrei programmare l'iniezione di dipendenza, i modelli di progettazione, il controller di vista modello con modelli di vista, ecc.

Le migliori pratiche di codifica devono sempre essere utilizzate

Sempre? No, è sciocco.

Le migliori pratiche sono linee guida. Per la maggior parte delle persone, per la maggior parte delle situazioni, se implementati con un po 'di finezza, otterranno i migliori risultati. Sono dove inizi quando consideri le soluzioni. Ma ci saranno luoghi in cui le migliori pratiche possono e devono essere ignorate, perché esistono soluzioni migliori.

Il problema è che gli umani non possono vedere nel futuro. E i principianti (e un gruppo di non principianti) inevitabilmente pensano di trovarsi in quello scenario speciale in cui le regole non si applicano a loro. In caso di dubbi, utilizzare le migliori pratiche. Anni di dibattito ed esperienza tra tonnellate di ingegneri più intelligenti di te o di me li hanno trovati in grado di produrre risultati costantemente buoni. Ma nessuno (o quasi nessuno) di loro conosce il tuo problema particolare come te. Occasionalmente ti imbatterai in casi eccezionali in cui le regole possono essere piegate.

Sì. Questo è evidente. Perché non dovresti fare ciò che è meglio?

Questo non è il problema però. La parte difficile è scoprire qual è la migliore pratica, perché per rispondere è necessario sapere esattamente quali requisiti hai e come è probabile che il progetto si evolva nel corso degli anni, e questo è tremendamente difficile.

Una buona regola empirica tuttavia: NON è la migliore pratica, mai, prendere i nomi di un mucchio di motivi di design e semplicemente incollarli insieme senza pensare.

A parte questo, alla tua domanda non è davvero possibile rispondere. Capire esattamente quale sia la "migliore pratica" per una determinata situazione è ciò che significa essere un ingegnere del software. Dovrai restringerlo per ottenere risposte migliori.

La migliore pratica è quella che soddisfa in modo più efficace i requisiti funzionali e non funzionali del tuo software per caratteristiche, manutenibilità, prestazioni, ecc. Se tale pratica si allinea ad alcuni "standard del settore", è fantastico. Ma in caso contrario, il pragmatismo vince.

Dove attualmente lavoro, stiamo costruendo una nuova interfaccia utente Web per il nostro prodotto da zero. Non sarà RESTful in alcun modo; utilizza esclusivamente POST. Non è multilivello, non utilizza alcun microservizio e non utilizza un database NoSQL. Non ha alcun tipo di architettura come Enterprise Java.

In altre parole, non è affatto alla moda.

Ma incorpora un framework HTML5 all'avanguardia che presenta una banca dati di tipo angolare, il ridimensionamento automatico su diversi tipi di dispositivi come mobile e desktop, l'integrazione con l'interfaccia utente Kendo di Telerik per fare tutto il lavoro pesante e un sistema completamente crittografato e sicuro canale dati.

Soprattutto, sarà realizzato in 30 giorni, un'impresa che un anno richiederebbe un esercito di sviluppatori Java in un'architettura Enterprise. Il codice è ES6 / Typescript; è il codice più pulito che abbia mai visto.

No . Le migliori pratiche sono cose che sono generalmente considerate la cosa migliore da fare il 99% delle volte, ma ciò non significa che si applichino sempre ad ogni situazione.

Come sviluppatore, il tuo compito è conoscere e utilizzare quelle migliori pratiche, ma anche sapere quando è sicuro metterle da parte.

Non si suppone che si tratti di auto-promozione, ma di recente ho scritto un post sul blog relativo al mio lavoro sulla piattaforma Salesforce.com che ha illustrato in dettaglio una di queste occasioni . Una delle regole d'oro è "Non fare mai una query all'interno di un ciclo", ma recentemente, per la prima volta in 7 anni di lavoro sulla piattaforma, ho avuto un motivo perfettamente valido per non rispettare questa regola.

L'essenza è che la piattaforma ha limiti sul numero di query che è possibile eseguire in un determinato contesto di esecuzione, ma in questo caso ho dovuto interrogare all'interno di un ciclo per evitare di esaurire lo spazio dell'heap e sapevo che sarei stato bene all'interno della query limite.

Quindi è raro, ma ci sono momenti in cui le migliori pratiche non sono rilevanti per uno scenario, quindi se non si adattano, non forzarle.

Presumo che per "buone pratiche" intendi un elenco di regole che qualcuno ha scritto in un libro. Per ovviamente se intendi letteralmente la frase, allora ovviamente dovresti sempre scrivere il miglior codice che puoi.

Devo sottolineare che non esiste un unico insieme di "migliori pratiche" universalmente accettato? Per qualsiasi regola promossa da un esperto, puoi quasi sempre trovare un altro esperto con le stesse credenziali che dica qualcosa di diverso.

Ma al punto: risposta breve: di solito, ma non sempre.

Ogni campo ha le sue "migliori pratiche" e "soluzioni per i libri di testo". Questi rappresentano l'esperienza accumulata e la saggezza di molte, molte persone per molti, molti anni e non dovrebbero essere ignorate. MA! Ci sono sempre circostanze speciali, casi marginali, ecc. La persona veramente capace in ogni campo sa quando seguire le regole e quando infrangerle.

Direi in generale: iniziare seguendo le regole del libro di testo. Quando si seguono le regole del libro di testo si creano problemi - complessità non necessaria, scarse prestazioni, qualunque cosa - quindi considerare se infrangere questa regola questa volta potrebbe non essere un'idea migliore.

Se ignori le regole e vai dove ti porta il capriccio del momento, il tuo codice sarà probabilmente un pasticcio confuso. Non importa quanto sei intelligente, non sei il primo programmatore al mondo. Ha senso imparare dall'esperienza degli altri. Nella nostra vita quotidiana, questo è il motivo per cui abbiamo genitori, insegnanti e predicatori: quindi non dobbiamo ripetere noi stessi ogni stupido errore per imparare che è uno stupido errore da fare.

Ma se segui con astuzia un elenco di regole di un libro il 100% delle volte, ti ritroverai spesso a martellare un piolo quadrato in una buca rotonda. Le persone che hanno scritto il regolamento potrebbero non aver trovato un caso come il tuo. E anche se lo hanno fatto, se è abbastanza raro potrebbero averlo ignorato. Una regola che funziona l'80% delle volte è una regola eccellente, a patto che tu capisca che funziona l'80% delle volte e non il 100% delle volte.

Ho scritto un libro sulla progettazione di database che include molte regole che consiglio ai progettisti di database di seguire. (Mi astengo dal dare il titolo in modo che non sembri sfuggire spudoratamente all'autopromozione.) Incoraggio certamente chiunque voglia progettare un database a leggere un libro come il mio e imparare tutto ciò che può da esso . Ma DI CORSO ci sono momenti in cui dovresti infrangere le regole che elenco.

Una volta ho scritto un documento sugli standard di programmazione per un team di sviluppatori che ho guidato in quel momento. E l'ultima regola è andata in questo modo: "Se hai una buona ragione per infrangere una delle regole di cui sopra, allora vai avanti, MA devi includere un commento nel tuo codice che spieghi perché hai infranto la regola. Se non puoi venire con una buona ragione, quindi segui la regola. Se scrivere il commento è più un problema che seguire la regola, segui la regola ". Abbiamo avuto solo poche volte in cui qualcuno ha trovato che infrangere una regola valeva la pena di dover spiegare il perché.

Con le migliori pratiche , presumo che tu intenda "regole informali che la comunità di sviluppo software ha imparato nel tempo che possono aiutare a migliorare la qualità del software" e non una sorta di miglior modo letterale di svolgere un compito specifico.

Sì, fino a quando non avrai un motivo per non farlo. Dovrebbe essere una buona ragione per aver preso in seria considerazione e applicato le circostanze e i limiti dell'attività in corso. Ciò significa che hai compreso appieno la pratica e sei in grado di applicarla. Non entriamo in questo concetto che se non lo capisci, non deve essere il miglior modo di pensare. Vedi la definizione

Non farai sempre ciò che è meglio. Quando il capo ti dice di "Spedisci questo pezzo di merda o sei licenziato!" Lo spedirai e probabilmente andrai a cercare un altro lavoro, ma lo spedirai comunque. A volte ti ritrovi a fare qualcosa che è abbastanza buono. Certo, non vuoi prendere l'abitudine di questo, ma a volte devi far rotolare i carri e non puoi preoccuparti che i cavalli siano ciechi.

Alcune cose sono importanti, altre no.

Dovresti adattare la tua scelta di lingua e stile al problema in questione.

Ad esempio, una "Best Practice" per la gestione delle eccezioni potrebbe essere quella di catturare sempre le eccezioni e registrarle, ma quando si crea un unit test la best practice è spesso quella di lasciarle fuori in modo che il framework di unit testing possa segnalarle correttamente.

D'altra parte, considera la regola "DRY". Cercare un codice che non si ripeta è sempre positivo, non solo per le ovvie ragioni, ma anche perché più codice in questo modo migliore diventa un programmatore - è un ottimo modo per flettere le tue capacità di programmazione / pensiero invece delle tue abilità di digitazione e copia / incolla, e nel lungo periodo ti sentirai meglio rivisitare il tuo codice (anche quando ti aspettavi che fosse un codice usa e getta) se seguivi alcune regole sensate.

In breve, sii flessibile, ma non solo codificare spazzatura illeggibile perché pensi che sia un codice da buttare via.

Proverò a vedere da una prospettiva diversa.

I moderni framework di oggi rendono molto semplice l'installazione di un progetto di base con mvc, iniezione di dipendenza, architettura a strati, ecc. Direi di iniziare con una base generata e utilizzare gli strumenti forniti per te, fino a quando non ti imbatti in qualcosa che richiede una soluzione fatta a mano. Quindi è possibile tagliare gli angoli da quelle migliori pratiche.

Non è più difficile usare qualcosa come Spring Boot per l'app Web 2 pagine, quindi lanciare i propri servlet, query jdbc e altre cose.

Nella mia esperienza c'è solo una best practice che considero obbligatoria:

Keep It Simple, Stupid (KISS)

In altre parole: qualunque strumento, API, architettura, ecc. Scegliate: se lo mantenete semplice, è più probabile che sia facile lavorare in futuro, avere meno bug, essere veloce, efficiente in termini di memoria e tutto ciò che potreste desiderare.

Tutte quelle altre cose di cui la gente parla: Principi, schemi, pratiche, ecc. - Considero un pallet di strumenti tra cui scegliere, selezionando quelli che meglio si adattano al progetto a cui sto lavorando. Tutti forniscono tecniche e idee per risolvere i problemi. Il trucco è capire se hai questi problemi in primo luogo.

Le migliori "Best Practices" contengono sempre una sezione che dovresti usare la tua intelligenza ed esperienza per identificare quando gli articoli nel manuale sono inappropriati. Possono anche contenere una sezione sulla revisione, l'approvazione e la documentazione di tali eccezioni e renderle parte delle "migliori" pratiche.

Quando si codifica un software, l'architettura dovrebbe sempre essere la migliore prassi o pratica pratica per quanto riguarda l'applicazione in costruzione?

In teoria, sì.

Nel mondo reale, [ancora] sì, purché tu possa permetterti di farlo.

Che, ovviamente, significa "No".

Le pressioni di tempo e denaro cercheranno sempre di spingerti lungo la strada di una soluzione "veloce e sporca", perché offre un valore "migliore" al cliente. Il modo in cui ciò viene implementato non ha alcun interesse per il cliente o per i suoi commercialisti. Se riesci a fare un lavoro [male] in due giorni o perfettamente in tre mesi, quale pensi che ti chiederanno?

Il divario tra i due - le migliori pratiche e ciò che devi "scappare" - si chiama "debito tecnico"; è perfettamente accettabile, purché tu abbia un piano per "ripagarlo", cioè per tornare indietro e migliorare le cose in seguito. Ancora una volta, non qualcosa per cui (sempre?) Ottieni il budget.

Una tattica è quella di rilasciare una versione beta precoce con la correzione "rapida", ma assicurarsi che i miglioramenti architetturali necessari siano prioritari prima della versione "completa". Ancora una volta, non qualcosa che devi sempre (mai?) Fare.