Un algoritmo appropriato aiuta davvero a migliorare la qualità e, in definitiva, l'efficienza di un programma?
Possiamo ancora produrre un programma di buona qualità senza l'algoritmo?
Un algoritmo appropriato è un MUST nella programmazione moderna?
Penso che questa domanda elimini una prospettiva storica.
Ritorniamo ai "vecchi tempi" (di cui non sono un testimone personale, quindi questa è solo la mia ricostruzione di quell'epoca - sentitevi liberi di correggermi se avete sperimentato le cose in modo diverso) Lo spazio e le prestazioni dell'HW erano nulle rispetto a quelle odierne . Quindi tutto le persone scritte allora dovevano essere molto efficienti. Quindi avevano bisogno di pensare molto alla ricerca e di inventare i migliori algoritmi per ottenere le necessarie prestazioni spazio / temporali per portare a termine il lavoro. Un altro fattore in questo era che gli sviluppatori stavano principalmente lavorando su ciò che potreste chiamare infrastruttura : sistemi operativi, stack di protocolli, compilatori, driver di dispositivo, editor, ecc. Tutto questo è usato molto da molte persone , quindi le prestazioni fanno davvero la differenza.
Al giorno d'oggi siamo viziati con un incredibile HW con processori multicore e gigabyte di memoria anche in un laptop di base (diamine, anche in un telefono cellulare). Ciò significa naturalmente che in molti casi le prestazioni, e quindi l'algoritmo, hanno cessato di essere il problema centrale, ed è più importante fornire una soluzione veloce che fornire una soluzione rapida. OTOH abbiamo un mucchio di framework che ci aiutano a risolvere problemi, e incapsulare un gran numero di algoritmi allo stesso tempo. Quindi, anche quando non stiamo pensando ad algoritmi, possiamo benissimo usarne molti in background.
Tuttavia, ci sono ancora aree in cui le prestazioni sono importanti. In queste aree devi ancora pensare molto ai tuoi algoritmi prima di scrivere il codice. La ragione è che l'algoritmo è il centro del design, che determina molte strutture dati e relazioni nel codice circostante. E se scopri troppo tardi che il tuo algoritmo non sta scalando bene (ad esempio è O (n 3 ) quindi è sembrato bello e veloce quando lo hai testato su 10 elementi, ma nella vita reale lo farai avere milioni), è molto difficile, soggetto a errori e richiede molto tempo per sostituirlo nel codice di produzione. E le micro-ottimizzazioni non ti aiuteranno se l'algoritmo fondamentale non è adatto per il lavoro.
Solo per indicare qualcosa:
Un algoritmo è esso stesso una soluzione generale passo passo del tuo problema. Quindi, se hai risolto il problema, hai effettivamente utilizzato un algoritmo.
Il punto più importante qui è che devi usare gli algoritmi per risolvere il problema, in un modo o nell'altro. Il più delle volte è meglio pensare al tuo problema prima di saltare alla codifica: questa fase viene spesso chiamata design. Ma, quanto e in che modo lo farai dipende da te.
Inoltre, non dovresti mescolare il concetto di algoritmo con diagrammi di flusso (temo che stia succedendo qui). I diagrammi di flusso sono solo una rappresentazione grafica che può essere utilizzata e utilizzata nei giorni precedenti per illustrare un algoritmo. Al giorno d'oggi è deprecato.
Modifica
Esistono molti modi per rappresentare un algoritmo e il codice del linguaggio di programmazione è uno di questi. Tuttavia, molto spesso è molto meglio o più facile non risolvere l'intero problema in una sola volta ma solo un contorno e poi riempire gli spazi vuoti mentre procedete.
Il mio preferito qui è pseudo codice, e solo per coprire un generale schema astratto dell'algoritmo in domanda - è ridicolo da ottenere nei dettagli con pseudocode , ovvero che codice reale è per.
Ma il codice reale può essere usato per schema. Ad esempio, alle persone del TDD piace progettare l'algoritmo mentre codificano, e dal momento che non possono risolverlo tutto a una volta entrambi, disegnano un contorno dell'esecuzione del programma in tempo reale codice e utilizzare oggetti fittizi (o funzioni, metodi ...) come spazi vuoti a essere compilato in seguito.
I diagrammi di attività UML sembrano essere a incarnazione moderna di vecchio stile diagrammi di flusso con notazione aggiunta per le nuove cose come il polimorfismo e multithreading. Non posso davvero dire quanto è utile, dal momento che non l'ho fatto li uso davvero molto - sono solo menzionandolo per completezza.
Inoltre, se stai basando il tuo algoritmo sul passaggio tra afferma, quindi un diagramma di stato è abbastanza utile.
Generalmente, qualsiasi mezzo tu debba semplicemente schizzo l'idea alla base di un determinato algoritmo è un buon modo per andare.
Una buona analogia è che devi conoscere una ricetta prima di iniziare a cucinare. Ok, puoi modificarlo mentre procedi, ma devi ancora sapere cosa vuoi fare prima di iniziare. Se voglio fare uno spezzatino d'agnello, farò cose molto diverse rispetto a quando voglio cuocere una pagnotta di pane.
Il codice implementa gli algoritmi. Cercare di scrivere codice senza aver progettato l'algoritmo è come provare a dipingere una casa prima che vengano costruiti i muri. Gli algoritmi sono stati un "MUST" dall'inizio della programmazione.
Essere fluenti nella tua lingua aiuta a migliorare la qualità e la produttività. E risolvere i piccoli problemi algoritmici è molto più utile per questo rispetto alla ripetizione dello stesso materiale MVC 100 volte.
Anche se, suppongo ci siano altri modi per ottenere scioltezza.
L'algoritmo diventerà un MUST nel dominio di programmazione moderno? È già un "must", a meno che tu non sia un po '"php ninja" che scrive "cool codez". Tutte le "migliori" aziende (Google, Amazon, ecc.) Mettono alla prova la tua esperienza algoritmica nell'intervista e immagino che non lo farebbero senza alcun motivo.
Ma tornando al punto originale, dovresti sempre metterti alla prova se vuoi migliorare. E dal momento che i normali lavori (ovvero "ora scrivono i gestori CRUD per altri 100 oggetti") non sempre forniscono una buona sfida, gli algoritmi lo compensano.
Direi che è necessario almeno un'idea iniziale di un algoritmo prima di iniziare la codifica. Probabilmente rivedrai la tua idea mentre codifichi in base alle strutture dei dati ecc.
In seguito potresti rivedere il codice se la profilazione suggerisce che c'è un problema di prestazioni in quell'area.
Il motivo è che è più rapido correggere gli errori prima di aver scritto il codice sbagliato.
Più prosaicamente, ci sono regolarmente differenze di produttività da 10 a 1 tra i diversi programmatori. Quando guardi i programmatori che hanno raggiunto il livello di produttività 10 volte, trascorrono la frazione minima del loro tempo per la codifica. Il tempo di digitare il codice non dovrebbe essere il collo di bottiglia. Invece trascorrono una parte maggiore del loro tempo per assicurarsi che abbiano esigenze dirette, pianificazione, test, ecc.
Al contrario, quando guardi i programmatori che si immergono nella codifica senza una pausa, devono inevitabilmente scrivere il codice più e più volte quando incontrano problemi completamente prevedibili, e il risultato finale è meno gestibile e più buggato. (Per inciso, sapevi che una media dell'80% dei soldi spesi per lo sviluppo del software è in fase di manutenzione? Rendere le cose manutenibili è importante.)
Generalmente algoritmi e strutture dati prima, codice dopo. Ma dipende molto dal dominio di programmazione. Ho usato un sacco di cose matematiche applicate, e ho davvero guardato il modello a cascata allora prevalente. Questo perché raramente gli algoritmi di livello medio-basso potevano essere dati per scontati. Disegna una grande struttura attorno all'esistenza di sottosistemi non scritti, quindi scopri in ritardo che la matematica di uno di quei sottosistemi cruciali non funziona (è instabile o altro). Quindi ho sempre pensato prima ai sottogruppi più difficili, e se c'era qualche motivo di dubbio, ho scritto e testato per primo quelli prima. Ma, per alcuni domini problematici, puoi semplicemente andare avanti senza molta pianificazione.
Disegna un algoritmo in sezioni, quindi suddividi le sezioni e codificale singolarmente. In questo modo puoi combinare entrambi i punti di vista:
Per me, è praticamente tutto il codice. Penso che sia vero per i programmatori più produttivi. Posso scrivere il codice con la stessa facilità con cui scrivo testo.
Per quanto possibile, cerco di acquisire i requisiti come test eseguibili (codice). Il design è solo un codice di alto livello. È più veloce e più preciso catturare il design nella lingua di destinazione che acquisirlo in qualche altra forma e poi tradurlo.
Ho riscontrato che la maggior parte degli utenti non è in grado di esaminare in modo efficace i requisiti testuali. Fanno bene con casi d'uso sequenziali, ma i casi d'uso non possono catturare ogni aspetto dell'interfaccia utente. Il migliore è di gran lunga l'implementazione, consentire agli utenti di provarlo, ottenere i loro commenti e modificare il codice di conseguenza.
Quando ti siedi e inizi a programmare, hai in mente un algoritmo, che sia "progettato" o meno.
Se ti sei seduto e hai iniziato a programmare senza alcun algoritmo completo in mente, avresti fatto una delle seguenti azioni:
1) tasti di mashing casuali. Questo probabilmente produrrà un errore del compilatore
2) scrivere codice compilabile che probabilmente fa qualsiasi cosa eccetto la cosa che vuoi che faccia
3) scrivere il codice per risolvere piccole parti del problema e costruirlo man mano che procedi in modo aggregante, ma non pensare in anticipo - quindi alla fine il problema è risolto - ma il codice non è molto efficiente e con la possibilità di dover tornare indietro e perdere tempo lungo la strada
Quindi le persone di solito programmano con un algoritmo in testa. Potrebbe essere stato ritagliato o ragionato sulla carta o su un altro supporto.
Può essere una buona disciplina pensare al tuo attacco a un problema lontano dalla tastiera, specialmente nei giorni precedenti come programmatore. Come hanno notato altre risposte, man mano che si acquisisce maggiore esperienza, è possibile migliorare la codifica di alcuni blocchi di problemi più "maneggevoli" al volo. Tuttavia, per problemi complessi o complessi, è utile pensare e progettare lontano dalla tastiera: quando si è impegnati con il codice, è più probabile che si pensi in termini di costrutti del linguaggio e in come affrontare il compito più immediato nel linguaggio. problema. Mentre pensare al problema con, ad esempio, carta e penna, ti libera di più dall'aspetto linguistico del codice e ti consente di pensare ad un livello più alto e astratto.
Devi smettere di guardare alla costruzione del software come qualcosa di fondamentalmente dalla costruzione di qualsiasi altra cosa di valore. Non è. Quindi, come qualsiasi altra cosa, è sempre necessario un piano o un progetto ben pensato, tuttavia succedere.
Does an appropriate algorithm really help improve the quality and ultimately the efficiency of a program?
Un piano / schemi di schemi appropriati aiuta a costruire una casa di qualità in modo efficiente?
Can we still produce a good quality program without the algorithm?
Riesci a costruire una casa di buona qualità in modo efficiente senza un piano di costruzione appropriato? Secondo il Teorema della scimmia infinita , probabilisticamente, sì (proprio come un milione di scimmie che digitano a caso per l'eternità alla fine digiteranno opere di Shakespeare.
Is an appropriate algorithm a MUST in modern programming?
Se non vuoi essere una scimmia del codice e vuoi assicurarti di non distribuire software che assomigli e funzioni come merda, sì, è un must. Ogni progetto che ho dovuto salvare (perché il codice sembrava una merda umida- bile) ha iniziato invariabilmente con una risposta negativa a quella domanda.
In effetti, la programmazione moderna è stata l'allontanamento dal programmatore di software di programmazione cowboy, dove è stato necessario pianificare di qualche tipo .
Anche quando hai una libreria di algoritmi e strutture di dati a tua disposizione (.ie. Boost in C ++ o nella libreria di raccolte Java), devi sapere come funziona quella roba per usarla appropriatamente, e per comporla in ragionevole , algoritmi di livello superiore.
Non è meglio. È meglio non "progettare" nulla. Questo è per le persone che non scrivono programmi. Sai, le persone con una reale esperienza del problema a portata di mano. Se sei un matematico, un ingegnere o un logista, bene, devi lavorare sul processo altrove. Ma non è "programmazione".
Metti prima una specie di test e benchmark.
Quindi scrivi qualcosa, qualsiasi cosa. Effettua il refactoring-riscrittura -loop fino a quando non si esaurisce il tempo o non si può più migliorare.
Anche se molti sembrano pensare che si possa fare qualcosa con un computer senza effettivamente fare nulla su un computer, penso che questo sia uno dei miti più comuni là fuori. Astronautismi di architettura.
Inoltre, non puoi ottimizzare il tuo algo prima che sia scritto.
IOW, "stai vicino al metallo".
Leggi altre domande sui tag algorithms