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

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

Questo è tutto.

Ora, la ragione per cui si osservano le migliori pratiche è perché alcuni requisiti hanno a che fare con la manutenibilità, la testabilità, le garanzie sulle prestazioni e così via. Di conseguenza, hai quelle persone fastidiose come me che richiedono cose come uno stile di codifica appropriato. Non ci vuole molto più sforzo per incrociare le tue T e dotare i tuoi io, ed è un gesto di rispetto verso coloro che devono leggere il tuo codice più tardi e capire cosa fa.

Per i sistemi di grandi dimensioni, questo tipo di controllo e disciplina è essenziale, perché devi giocare 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 ci sono quelle utility uniche che scrivi per risolvere un problema specifico in questo momento, utilità che non userai mai più. In questi casi, lo stile e le migliori pratiche sono completamente irrilevanti; metti insieme la cosa, eseguila e vai avanti con la prossima cosa.

Quindi, come con così tante cose nello sviluppo del software, dipende.

C'è una vecchia citazione saggia: "Non seguire le orme dei saggi degli antichi: cerca ciò che cercavano". Ci sono ragioni per tutte le regole della codifica 'corretta'. Sapere perché esistono queste regole è più importante di sapere quali sono queste regole.

C'è una regola che non dovresti mettere un test che potrebbe essere ricalcolato ripetutamente in un ciclo for come quello. Nei casi in cui la regola è stata inventata per porre rimedio (dove le prestazioni sarebbero davvero diverse), ha senso. In tal caso, c'è solo una risposta giusta. Nel tuo esempio, è noto che non ci sono differenze di prestazioni e che non possono esserci più di un paio di dozzine di iterazioni. In questo caso, ci sono due risposte giuste, sia per applicare la regola in ogni caso, poiché è semplice e non farà male a nulla e potrebbe aiutare a formare buone abitudini, o ignorare la regola, dal momento che non c'è alcuna differenza di prestazioni di cui preoccuparsi.

Preferisco la prima risposta corretta e tu preferisci la seconda. Non ti stai sbagliando. Penso che tu abbia torto nella tua idea di cosa sia la "corretta" programmazione. Non si tratta di seguire una serie di regole scelte a caso che non ti aiutano e non hanno alcuno scopo. Il tuo non fissare il ciclo for nell'esempio sta effettivamente seguendo una buona regola contro l'ottimizzazione prematura.

Una vera e propria programmazione appropriata è seguire le buone regole che hanno senso in modo intelligente.

Il modo corretto di considerare questo è un rendimento in diminuzione: confrontare il vantaggio aggiuntivo di sviluppare il programma sul costo dello sviluppo aggiuntivo.

I rendimenti decrescenti vengono impostati quando il vantaggio marginale è inferiore al tempo / sforzo marginale.

Puoi creare un caso aziendale per lo spostamento di items.length sul ciclo for ? Economicamente, questo cambiamento può anche giustificare il tempo trascorso cercando di giustificarlo? Poiché non vi è alcuna differenza nell'esperienza utente, non si otterrà mai nulla per il tempo trascorso a misurare (a parte una lezione utile da ricordare). Gli utenti non apprezzeranno il programma più di quanto non facciano, e più copie non saranno vendute, come conseguenza di tale cambiamento.

Questo non è sempre facile da valutare, perché i casi aziendali sono pieni di incognite e rischi e sono quindi suscettibili di cadere preda di fattori non considerati che diventeranno evidenti solo a posteriori. I cambiamenti proposti possono essere completamente non banali, in modo che facciano una grande differenza.

Il tipo di pensiero basato sui rendimenti decrescenti può rappresentare una caccia alle scuse per non agire, ed evitare di correre rischi, che a posteriori potrebbero rivelarsi una serie di opportunità mancate.

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

Quando non ti interessa che il tuo codice sia "corretto"

• Se riesci a rispondere all'obiettivo aziendale e mantenerlo nel tempo con un sovraccarico ridotto. (gli utenti non visualizzano la fonte prima che ti paghino)
• MVP / POC - Se scrivere codice corretto significa perdere tempo su un concetto prima di sapere come guadagnare (se passi anni e 45 milioni di dollari a scrivere la tua app e chiudere il negozio perché non ha mercato, no a uno importa quanto fosse corretto il codice)
• Quando si verifica una situazione pericolosa per la vita (ad esempio, il prototipo di Iron Man 1 era un trucco sporco, ma l'ha fatto uscire dalla caverna giusto?)
• o se semplicemente non sai come scrivere il codice corretto (se somene riesce a guadagnarsi da vivere scrivendo codice non corretto, nella disoccupazione di oggi, dico, meglio scrivere codice cattivo che essere senzatetto)
• se semplicemente sai cosa stai facendo o pensi di farla franca fingendo di farlo

Quando scrivere il codice corretto

• Se avrà un impatto aziendale significativo, ad es. le prestazioni influiscono sulle entrate o impediscono le vendite
• Se non è corretto, mantenere il codice diventa un problema aziendale (costi di manutenzione elevati)
• Se sei un programmatore conosciuto che lavora su un grande progetto open source
• Lo stesso per una grande azienda che fornisce una biblioteca interna al mondo
• Se vuoi mostrare il tuo lavoro come portfolio nelle interviste future

Il rendimento è la tua preoccupazione principale? È questo che stai cercando di massimizzare?

Se è così, c'è una lezione fondamentale da imparare e, se lo fai, sarai uno dei pochi.

Non cercare di "pensare" cosa dovresti fare per renderlo più veloce - questo è indovinare. Se stai chiedendo "Dovrei usare questa classe contenitore o quella?", O "Dovrei inserire length nella condizione del ciclo?", Sei come un medico che vede un paziente e prova a decidere quale trattamento dare senza interrogare o esaminare il paziente.

Questo è indovinare. Tutti lo fanno, ma non funziona.

Invece, lascia che il programma stesso ti dica quale sia il suo problema. Ecco un esempio dettagliato.

Vedi la differenza?

La tua domanda è "finché il lavoro viene svolto, non mi interessa?"

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

Una volta, quella cosa che ho scritto si è trasformata in "oh, ora l'intero reparto dell'utente vuole usare quel codice", che prima che potessi girarmi è diventato "l'intera azienda sta usando quel codice e ora devo dimostrare che lo farà sopravvivere a un controllo e c'è una revisione del codice di 20 persone prevista per domani e alcuni vicepresidente lo ha già venduto ai nostri clienti. "

Mi rendo conto che stai "scrivendo solo 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 infamia perché continua a schiantare i telefoni delle persone. Vuoi essere la persona che ottiene un'offerta di lavoro perché i figli di qualcuno non possono smettere di giocare ai propri telefoni o vuoi essere la persona che viene vilipesa su bacheche come questa?

La risposta è che non ha mai importanza, e conta sempre ....

Non ha importanza perché la programmazione, corretta o meno, è 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 programmazione).

Importa sempre perché la programmazione corretta è 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 risparmia.

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

Gli strumenti one off vengono generalmente eseguiti il più velocemente e sporchi possibile, con un controllo degli errori minimo o di altro tipo, senza registrazione delle eccezioni, codice cut-n-paste con modifiche minori o addirittura senza modifiche invece di funzioni generiche, e così via.

Stai attento: a volte le app veloci e sporche si caricano da sole, il che significa che tutte le scorciatoie ti mordono nel ...

Or even something trivial like this:

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

I know it evaluates item.length on every iteration. However, I also know items will never be more than 15 to 20 items. So should I care if I evaluate items.length on every iteration?

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.

So I guess my question to you is this: Is there a threshold when it no longer >matters to be proper? Is it ok to say - "so long as it gets the job done, I >don't care?"

Dipende davvero da cosa ti aspetti dal tuo prodotto finale; la differenza tra un prodotto medio e un ottimo prodotto dipende dai dettagli. Una macchina come Tata Nano e un'auto come la Mercedes S "fa il lavoro" - ti porta da un posto all'altro. La differenza si basa sui 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 questa roba (e di altre cose, ovviamente).

Se stai programmando a casa per te allora forse puoi tagliare qualche angolo; e quando stai sperimentando e provando cose questo è completamente giustificato.

Comunque stammi bene. Nell'esempio che date non c'è davvero alcun bisogno di tagliare quell'angolo, e bisogna stare attenti. Questo potrebbe iniziare una tendenza e le cattive abitudini che fai a casa potrebbero insinuarsi nel tuo codice al lavoro. Molto meglio praticare e migliorare le buone abitudini a casa e lasciarli filtrare nel tuo codice al lavoro. Ti aiuterà e aiuterà gli altri.

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

Guarda il lato buono però. Te l'hai chiesto, quindi forse sei già al corrente del punto che sto facendo.

Se un produttore di mobili stava fabbricando un mobile da usare dove la qualità non era della massima importanza o dove la qualità poteva passare inosservata, dovrebbero comunque provare a fare i tagli dritti, e fare un buon lavoro unendo il pezzi insieme?

Molte persone vedono il software come un'arte. Ciò che costruiamo dovrebbe non solo svolgere una funzione, deve essere affidabile, manutenibile, robusto. Fare questo tipo di software richiede abilità e questa abilità deriva dalla pratica.

Quindi, anche se la scelta di un costrutto ciclico per ciò su cui stai lavorando oggi non ha importanza, il fatto che ti sforzi di usare i costrutti appropriati in ogni momento, nel tempo, ti farà diventare un programmatore migliore.