Dovrebbero sempre essere utilizzate le migliori pratiche di codifica [chiuso]

Should coding best practices always be used

Sempre? No, è sciocco.

Le migliori pratiche sono linee guida. Per la maggior parte delle persone, per la maggior parte delle situazioni, se implementate con una certa finezza, produrranno i migliori risultati. Sono dove inizi quando consideri le soluzioni. Ma ci saranno luoghi in cui le buone pratiche possono e devono essere ignorate, perché ci sono soluzioni migliori.

Il problema è che gli umani non possono vedere nel futuro. E i principianti (e un gruppo di non-principianti) inevitabilmente pensano di essere in quello scenario speciale in cui le regole non si applicano a loro. In caso di dubbi, utilizza le best practice. Anni di dibattiti e di esperienze su migliaia di ingegneri più intelligenti di te o me li abbiamo trovati a produrre costantemente buoni risultati. Ma nessuno (o quasi nessuno) di loro conosce il tuo particolare problema come te. Occasionalmente ti imbatti in casi eccezionali in cui le regole possono essere piegate.

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

Comunque non è questo il problema. La parte difficile è scoprire qual è la migliore pratica, perché per rispondere a ciò è necessario sapere esattamente quali sono i requisiti che si hanno e come è probabile che il progetto si evolva nel corso degli anni, e ciò è diabolicamente difficile.

Tuttavia, una buona regola pratica: NON è la migliore pratica, in assoluto, per prendere i nomi di un gruppo di modelli di design e semplicemente metterli insieme senza pensare.

Oltre a questo, alla tua domanda non si può davvero rispondere. Capire esattamente quale "buona pratica" è per una data situazione è ciò che significa essere un ingegnere del software. Dovrai restringerlo per ottenere risposte migliori.

La best practice è quella che soddisfa in modo più efficace i requisiti funzionali e non funzionali del tuo software per funzionalità, manutenibilità, prestazioni, ecc. Se quella pratica accade per allinearsi con alcuni "standard del settore", è fantastico. Ma se così non fosse, il pragmatismo vincerà.

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

In altre parole, non è affatto anca.

Ma incorpora un avanzato framework HTML5 che presenta un'associazione dati angolare, scalabilità automatica per diversi tipi di dispositivi come i dispositivi mobili e desktop, integrazione con l'interfaccia utente di Kendo di Telerik per eseguire tutto il lavoro di sollevamento pesante e un canale dati completamente crittografato e protetto.

Meglio di tutto, sarà fatto in 30 giorni, un'impresa che richiederebbe un esercito di sviluppatori Java in un'architettura Enterprise per raggiungere l'anno. 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 queste best practice, ma anche sapere quando è sicuro metterle da parte.

Questo non dovrebbe essere auto-promozione, ma ho di recente ha scritto un post sul blog relativo al mio lavoro sulla piattaforma Salesforce.com che ha descritto una di queste occasioni . Una delle regole d'oro è "Mai fare 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 dei limiti sul numero di query che è possibile eseguire in un dato contesto di esecuzione, ma in questo caso ho dovuto interrogare all'interno di un ciclo per evitare di esaurire lo spazio heap e sapevo che sarei andato bene entro il limite della query.

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

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

Devo far notare che non esiste un unico insieme di "buone pratiche" universalmente accettate? Per qualsiasi regola promossa da un esperto, puoi quasi sempre trovare un altro esperto con credenziali uguali che dica qualcosa di diverso.

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

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

Direi in generale: iniziare seguendo le regole del manuale. Quando seguire le regole del libro di testo porta a problemi - complessità non necessaria, prestazioni scadenti, qualsiasi cosa - quindi considera se rompere questa regola una volta potrebbe non essere un'idea migliore.

Se ignori le regole e vai dove ti porta il tuo 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 scoprire che si tratta di un errore stupido da fare.

Ma se segui pedissequamente un elenco di regole da alcuni libri il 100% delle volte, ti troverai spesso a martellare un piolo quadrato in un buco rotondo. Le persone che hanno scritto il regolamento potrebbero non aver trovato un caso simile al tuo. E anche se lo fossero, se è abbastanza raro potrebbero averlo ignorato. Una regola che funziona l'80% delle volte è una regola eccellente, purché 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 designer di database di seguire. (Mi asterrò dal dare il titolo in modo che non sembri che sto sfortunatamente scivolando nell'autopromozione.) Certamente incoraggio chiunque voglia progettare un database per leggere un libro come il mio e imparare tutto ciò che può da esso . Ma DI CORSO ci sono momenti in cui dovresti rompere le regole che elenco.

Una volta ho scritto un documento di programmazione standard per un team di sviluppatori che ho guidato in quel momento. E l'ultima regola è andata più o meno così: "Se hai una buona ragione per rompere una delle regole precedenti, allora vai avanti, MA devi includere un commento nel tuo codice che spiega perché hai infranto la regola. Se non puoi venire con una buona ragione, quindi segui la regola: se scrivere il commento è più difficile che seguire la regola, allora segui la regola ". Abbiamo avuto solo una manciata di volte in cui qualcuno ha scoperto che infrangere una regola valeva la pena di dover spiegare il perché.

Con le best practice , presumo tu intenda "regole informali che la comunità di sviluppo del software ha appreso nel tempo può aiutare a migliorare la qualità del software "e non una sorta di modo letterale di fare un compito specifico.

Sì, finché non hai una ragione per non farlo. Dovrebbe essere una buona ragione per cui hai preso seriamente in considerazione e applicato alle circostanze e ai limiti del compito in questione. Ciò significa che comprendi pienamente la pratica e sei in grado di applicarla. Non entriamo in questa nozione che se non la capisci, allora non deve essere il miglior modo di pensare. Vedi la definizione.

Non farai sempre ciò che è meglio. Quando il capo ti dirà: "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, ma a volte devi far rotolare i carri e non puoi preoccuparti che i cavalli siano ciechi.

Alcune cose sono importanti, altre no.

Devi 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 rilevare sempre le eccezioni e registrarle, ma quando si crea un test di unità è spesso meglio lasciarle andare in modo che il framework di testing dell'unità possa segnalarle correttamente.

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

In sintesi, sii flessibile, ma non limitarti a codificare la posta indesiderata illeggibile perché pensi che sia un codice da buttare via.

Proverò a visualizzare da una prospettiva diversa.

I moderni framework di oggi rendono molto semplice la configurazione di un progetto di base con mvc, injection dependance, architettura a strati ecc. (spring boot lover here). Direi di iniziare con una base generata e utilizzare gli strumenti forniti per te, finché non ti imbatti in qualcosa che richiede una soluzione artigianale. Quindi potresti tagliare gli angoli da quelle migliori pratiche.

Non è più difficile usare qualcosa come Spring Boot per l'applicazione web di 2 pagine, quindi eseguire il rollover dei propri servlet, query jdbc e altro.

Nella mia esperienza esiste solo una delle migliori pratiche che considero obbligatoria:

Keep It Simple, Stupid (KISS)

In altre parole: quali strumenti, API, architetture, ecc. tu scegli: se lo fai in modo semplice, è più facile lavorare in futuro, avere meno bug, essere veloce, efficiente in termini di memoria e tutto il resto desiderio.

Tutte le altre cose di cui si parla: principi, schemi, pratiche, ecc. - Considero un pallet di strumenti tra cui scegliere, selezionando quelli che meglio si adattano al progetto su 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 in cui è necessario utilizzare la propria 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.

When coding software, should the architecture always be best practices or practical practices in regards to the application being built?

In teoria, sì.

Nel mondo reale, [ancora] sì, finché puoi permetterti di farlo.

Che, ovviamente, significa "No".

Le pressioni sul tempo e sui soldi cercano sempre di spingerti verso una soluzione "rapida e sporca", perché offre un valore "migliore" al cliente. Il modo in cui viene implementato non interessa al cliente o ai suoi commercialisti. Se riesci a fare un lavoro [male] in due giorni o perfettamente in tre mesi, quale pensi che ti chiederanno?