Quando la programmazione "corretta" non ha più importanza?

Ho costruito un gioco Android nel mio tempo libero. Sta usando la libreria libgdx quindi un bel po 'di lavoro pesante è fatto per me.

Durante lo sviluppo, ho selezionato con noncuranza i tipi di dati per alcune procedure. Ho usato una tabella hash perché volevo qualcosa vicino a un array associativo. Valori chiave leggibili dall'uomo. In altri posti per ottenere cose simili, uso un vettore. So che libgdx ha classi vector2 e vector3, ma non le ho mai usate.

Quando mi imbatto in strani problemi e cerco aiuto in Stack Overflow, vedo molte persone che stanno semplicemente risolvendo le domande che utilizzano un determinato tipo di dati quando un altro è tecnicamente "corretto". Come usare una ArrayList perché non richiede limiti definiti rispetto alla ridefinizione di un int [] con nuovi limiti noti. O anche qualcosa di banale come questo:

for(int i = 0; i < items.length; i ++)
{
    // do something
}

So che valuta item.length su ogni iterazione. Tuttavia, so anche che gli articoli non saranno mai più di 15-20 articoli. Quindi dovrei preoccuparmi se valuto items.length su ogni iterazione?

Ho eseguito alcuni test per vedere come si comporta l'app utilizzando il metodo che ho appena descritto rispetto a quello corretto, seguire il tutorial e utilizzare gli esatti tipi di dati suggeriti dalla community. I risultati: stessa cosa. Media 45 fps. Ho aperto tutte le app sul telefono e sulla scheda galassia. Nessuna differenza.

Quindi immagino che la mia domanda per te sia questa: esiste una soglia quando non conta più che sia corretta? Va bene dire - "fintanto che fa il lavoro, non mi interessa?"

Scrivi un programma per risolvere un problema. Tale problema è accompagnato da una serie specifica di requisiti per risolverlo. Se tali requisiti sono soddisfatti, il problema è risolto e l'obiettivo è raggiunto.

Questo è tutto.

Ora, il motivo per cui vengono osservate le migliori pratiche è perché alcuni requisiti hanno a che fare con manutenibilità, testabilità, garanzie di prestazione e così via. Di conseguenza, hai quelle persone fastidiose come me che richiedono cose come il giusto stile di programmazione. Non ci vuole molto più sforzo per incrociare le tue T e punteggiare le tue I, ed è un gesto di rispetto per coloro che devono leggere il tuo codice in un secondo momento e capire cosa fa.

Per i sistemi di grandi dimensioni, questo tipo di moderazione e disciplina è essenziale, perché devi giocare bene con gli altri per far funzionare tutto e devi ridurre al minimo il debito tecnico in modo che il progetto non collassi sotto il suo stesso peso.

All'estremità opposta dello spettro sono quelle utility una tantum che scrivi per risolvere un problema specifico in questo momento, utility che non utilizzerai mai più. In questi casi, lo stile e le migliori pratiche sono completamente irrilevanti; fai l'hacking insieme, lo esegui e vai avanti con quello successivo.

Quindi, come per tante cose nello sviluppo del software, dipende.

C'è una vecchia saggia citazione: "Non seguire le orme dei vecchi saggi. Cerca quello che cercavano." Vi sono ragioni per tutte le regole della codifica "corretta". Sapere perché esistono queste regole è più importante che sapere quali sono quelle regole.

C'è una regola che non si dovrebbe mettere un test che potrebbe essere ricalcolato ripetutamente in un ciclo for in questo modo. Nei casi in cui la regola è stata inventata per porre rimedio (dove le prestazioni sarebbero davvero diverse), ha senso. In quel caso, c'è solo una risposta giusta. Nel tuo esempio, è noto che non ci sono differenze di prestazioni e che non possono esserci più di una dozzina di iterazioni. In questo caso, ci sono due risposte giuste, o per applicare comunque la regola, poiché è semplice e non danneggerà nulla e potrebbe aiutare a formare buone abitudini, o ignorare la regola, poiché non c'è alcuna differenza di prestazione di cui preoccuparsi.

Preferisco la prima risposta giusta e sembri preferire la seconda. Non ti sbagli. Penso che tu abbia torto nella tua idea di quale sia la "corretta" programmazione. Non si tratta di seguire una serie di regole scelte casualmente che non ti aiutano e non hanno alcuno scopo. Il fatto di non correggere il ciclo for nell'esempio sta effettivamente seguendo un'ottima regola contro l'ottimizzazione prematura.

Una vera programmazione adeguata riguarda il seguire buone regole che abbiano un senso in modo intelligente.

Il modo corretto di esaminare ciò è la diminuzione dei rendimenti: confrontare il vantaggio aggiunto dello sviluppo del programma con il costo dello sviluppo aggiuntivo.

I rendimenti decrescenti si verificano quando il vantaggio marginale è inferiore al tempo / sforzo marginale.

Puoi creare un caso aziendale per items.lengthuscire dal forcircuito? Economicamente, quel cambiamento può persino giustificare il tempo impiegato a giustificarlo? Poiché non vi è alcuna differenza nell'esperienza utente, non otterrai mai nulla nemmeno per il tempo trascorso a misurare (a parte una lezione utile da ricordare). Gli utenti non apprezzeranno il programma più di quanto non facciano loro e non verranno vendute più copie a seguito di tale modifica.

Questo non è sempre facile da valutare, perché i casi aziendali sono pieni di incognite e rischi, e sono quindi suscettibili di cadere in preda a fattori non considerati che diventeranno evidenti solo col senno di poi. Le modifiche proposte possono essere completamente non banali, in modo tale da fare una grande differenza.

Il tipo di pensiero a ritorni decrescenti può equivalere a una caccia alle scuse per non agire, ed evitare di correre rischi, che a posteriori potrebbe rivelarsi una serie di opportunità mancate.

Ma a volte è ovvio quando non fare qualcosa. Se qualche pezzo di sviluppo sembra richiedere un miracolo economico solo per pagare il costo dello sviluppo (pareggio), è probabilmente una cattiva idea.

Quando non dovresti preoccuparti che il tuo codice sia "corretto"

• Se riesci a rispondere all'obiettivo aziendale e a mantenerlo nel tempo con bassi costi generali. (gli utenti non visualizzano la fonte prima di pagarti)
• MVP / POC - Se scrivere un codice corretto significa perdere tempo su un concetto prima di sapere come guadagnare da esso (se spendi anni e 45 milioni di dollari scrivendo la tua app e finisci per chiudere il negozio perché non aveva mercato, a nessuno importa come era proprio il codice)
• Quando si trovava in una situazione pericolosa per la vita (ad esempio iron man prototipo 1 era un trucco sporco, ma lo ha portato fuori dalla caverna giusto?)
• o se semplicemente non sai come scrivere il codice corretto (se somene riesce a guadagnarsi da vivere scrivendo un codice non corretto, nella disoccupazione di oggi, dico, è meglio scrivere codice cattivo piuttosto che essere senzatetto)
• se sai semplicemente cosa stai facendo o pensi di poterla fare finta di farlo

Quando scrivere il codice corretto

• Se avrà un impatto aziendale significativo, ad esempio le prestazioni influiranno sulle entrate o impediranno le vendite
• Se non è così corretto che il mantenimento del codice diventa un problema aziendale (elevati costi di manutenzione)
• Se sei un programmatore noto che sta lavorando a un grande progetto open source
• Lo stesso vale per una grande azienda che contribuisce al mondo con una biblioteca interna
• Se vuoi mostrare il tuo lavoro come portfolio in future interviste

Le prestazioni sono la tua principale preoccupazione? È quello che stai cercando di massimizzare?

In tal caso, c'è una lezione fondamentale da imparare e, se lo fai, sarai uno dei pochi.

Non cercare di "pensare" a cosa dovresti fare per renderlo più veloce - è una supposizione. Se stai chiedendo "Dovrei usare questa classe di contenitori o quella?" O "Devo mettere lengthla condizione del ciclo?", Sei come un dottore che vede un paziente e cerca di decidere quale trattamento somministrare senza effettivamente interrogare o esaminare il paziente.

Questo è indovinare. Lo fanno tutti, ma non funziona.

Lascia invece che il programma stesso ti dica qual è il suo problema. Ecco un esempio dettagliato.

Vedi la differenza?

La tua domanda è "finché finirà il lavoro, non mi interessa?"

La mia risposta è "non sai mai cosa succederà al tuo codice". Sono stato coinvolto in così tanti progetti che sono iniziati come "hey fammi scrivere questa cosa veloce per occuparmi del problema di un utente". Scrivilo, mettilo là fuori, non pensarci mai più.

Una volta, quella cosa che ho scritto si è trasformata in "oh, ora l'intero dipartimento dell'utente vuole usare quel codice", che prima che potessi girare è diventato "l'intera società sta usando quel codice e ora devo dimostrare che sopravviverà a un audit e domani è prevista una revisione del codice di 20 persone e alcuni vicepresidenti lo hanno già venduto ai nostri clienti ".

Mi rendo conto che stai "scrivendo un gioco Android nel tuo tempo libero" ma non sai mai se quel gioco decollerà e diventerà il tuo biglietto per fama e fortuna. Peggio ancora, quel gioco potrebbe diventare il tuo biglietto per l'infamia perché continua a mandare in crash i telefoni delle persone. Vuoi essere la persona che riceve un'offerta di lavoro perché i figli di qualcuno non riescono a smettere di giocare sui loro telefoni o vuoi essere la persona che viene vilificata su bacheche come questa?

La risposta è che non importa mai, e importa sempre ...

Non importa mai perché la programmazione, corretta o no, è un modo per raggiungere un obiettivo, non un obiettivo in sé. Se questo obiettivo viene raggiunto senza una programmazione "corretta", va bene (dal punto di vista aziendale è spesso meglio se l'obiettivo può essere raggiunto senza alcuna programmazione).

Importa sempre perché una corretta programmazione è uno strumento che ti aiuterà a raggiungere i tuoi obiettivi. Il modo corretto di fare le cose è semplicemente il riconoscimento che farlo in un altro modo provoca più dolore a lungo termine di quanto non risparmi.

Che risponde alla domanda su quando puoi ignorarlo - quando sei sicuro che un altro modo sarà più facile a lungo termine (forse perché non ci sarà lungo periodo).

Gli strumenti una tantum vengono generalmente eseguiti il ​​più rapidamente e sporco possibile, con un controllo degli errori minimo o nullo o altra convalida, nessuna registrazione delle eccezioni, codice cut-n-paste con modifiche minori o addirittura nessuna modifica invece di funzioni generiche, e così via .

Fai attenzione: a volte quelle app veloci e sporche prendono vita da sole, il che significa che tutte le scorciatoie ti mordono nel ...

O anche qualcosa di banale come questo:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

So che valuta item.length su ogni iterazione. Tuttavia, so anche che gli articoli non saranno mai più di 15-20 articoli. Quindi dovrei preoccuparmi se valuto items.length su ogni iterazione?

In realtà nel codice finale, items.length non verrà valutato in ogni iterazione perché il compilatore lo ottimizza. E anche se non lo fosse, la lunghezza è un campo pubblico nell'oggetto array; accedervi non costa.

Quindi immagino che la mia domanda per te sia questa: esiste una soglia quando non è più> importante essere corretta? Va bene dire: "Fintanto che fa il lavoro, non mi interessa?"

Dipende davvero da cosa ti aspetti dal tuo prodotto finale; la differenza tra un prodotto medio e un ottimo prodotto si basa sui dettagli. Un'auto come Tata Nano e un'auto come Mercedes S "fanno il lavoro" - ti porta da un posto all'altro. La differenza sta nei dettagli: potenza del motore, comfort, sicurezza e altro. È lo stesso con qualsiasi prodotto esistente, compresi i prodotti software; ad esempio perché qualcuno dovrebbe pagare a Oracle, IBM o Microsoft per database Oracle, DB2 o MS SQL Server poiché MySQL e Postgre sono gratuiti?

Se vuoi prestare attenzione ai dettagli e ottenere un prodotto di alta qualità, dovresti preoccuparti di queste cose (e di altre cose, ovviamente).

Se stai programmando a casa per te, forse puoi tagliare alcuni angoli; e quando stai sperimentando e provando le cose questo è completamente giustificato.

Comunque abbi cura di te. Nell'esempio che dai non c'è davvero bisogno di tagliare quell'angolo, e devi stare attento. Questo potrebbe iniziare una tendenza e cattive abitudini che fai a casa potrebbero insinuarsi nel tuo codice di lavoro. Molto meglio esercitarsi e migliorare le buone abitudini a casa e lasciare che penetrino nel tuo codice al lavoro. Ti aiuterà e aiuterà gli altri.

Qualsiasi programmazione tu faccia e ogni pensiero che fai sulla programmazione è esercizio. Rendilo utile, altrimenti tornerà e ti morderà.

Guarda il lato buono però. Hai chiesto questo, quindi forse sei già a conoscenza del punto che sto sollevando.

Se un produttore di mobili stava realizzando un mobile da utilizzare laddove la qualità non era della massima importanza o dove la qualità poteva passare inosservata, dovrebbero comunque cercare di rendere i loro tagli dritti e fare un lavoro adeguato unendo i pezzi?

Molte persone vedono il software come arte. Ciò che costruiamo non dovrebbe solo svolgere una funzione, deve essere affidabile, mantenibile, robusto. La realizzazione di tale software richiede abilità e tale competenza deriva dalla pratica.

Quindi, anche se la scelta di un costrutto a ciclo continuo per ciò su cui stai lavorando oggi potrebbe non avere importanza, il fatto che ti sforzi di usare i costrutti adeguati in ogni momento, ti renderà nel tempo un programmatore migliore.