Utilizzo delle strutture dati e aspetti motivazionali

3

Per una lunga vita da studente mi sono sempre chiesto perché ce ne siano così tanti, ma in molti di loro sembra esserci una mancanza di utilizzo. L'opinione non è cambiata davvero quando ho ottenuto un lavoro.

Abbiamo libri brillanti su ciò che sono e le loro complessità, ma non ho mai incontrato risorse che dessero effettivamente un buon accenno all'uso pratico. Capisco perfettamente che devo esaminare il problema, analizzare le operazioni richieste, cercare la struttura dei dati che li faccia in modo efficiente. Tuttavia in pratica non lo faccio mai, non a causa della sindrome della pigrizia umana, ma perché quando si tratta di lavoro riconosco la priorità temporale rispetto allo sviluppo personale.

Nel tempo ho pensato che quando sarei stato uno sviluppatore migliore ne userei automaticamente di più - non è successo affatto o forse non l'ho fatto. Poi ho scoperto che i colleghi di solito erano nello stesso piatto di me - conoscendo più o meno tre delle strutture dati e ne erano totalmente contenti e si rifiutavano di discutere ulteriormente con me, tornando alle conversazioni sui "nuovi linguaggi fantastici" librerie che fanno lavori per te 'e la gioia di lavorare sotto scrumban ecc.

Sono bloccato con ArrayLists, Arrays e SortedMap, che a prescindere da ciò che faccio sono sempre sufficienti o li ritocco per essere in grado di adempiere al mio compito. Sì, potrebbe essere inefficiente, ma dobbiamo davvero preoccuparci se Intel aumenterà le prestazioni nel corso degli anni, non importa se miglioriamo le nostre competenze? Le nuove macchine Xeon o IBM si preoccupano veramente di ciò che usiamo? Cosa succede se mi piace costruire le cose, ma non sono particolarmente entusiasta se è n log (n) o solo n? In vent'anni la potenza di elaborazione è aumentata enormemente, il che ci dà la libertà di non essere critici su quale utilizzare? Inoltre, appaiono nuovi linguaggi più ottimizzati che supportano più core in modo più efficiente.

Per essere più specifici: mi piacerebbe trovare materiale motivazionale su complesse aree reali / casi di possibili utilizzi effettivi delle strutture dati. Sarei davvero grato se volessi fornire risorse pertinenti. C'è una domanda simile, ma alla fine i link di nuovo descrivono o fanno un esempio stupido (veicoli, studenti o ricerca del Santo Graal - sì, molto rilevanti) e la gente continua a riferirsi allo "scenario decide la struttura dei dati da usare". Voglio conoscere questi scenari complessi per essere in grado di identificare le somiglianze con il mio scenario e poi usarli. Gli scenari complessi in cui conta davvero e non necessariamente di natura quantitiva. Sembra che le strutture dei dati riguardino solo l'efficienza e nient'altro? Non sembra esserci alcuna particolare convenienza per gli sviluppatori in uso uno sopra l'altro.

(solo quando ho trovato risorse scientifiche sul perché esattamente i carboidrati semplici sono cattivi ho smesso di mangiare zucchero e caramelle sostituendolo completamente con frutti meno dannosi - spero che tu possa vedere l'analogia)

    
posta Aubergine 24.03.2012 - 04:10
fonte

4 risposte

4

Penso che ci siano alcuni motivi per cui gli sviluppatori tendono a utilizzare solo poche strutture di dati.

Esistono strutture dati generali che funzionano abbastanza bene la maggior parte delle volte in modo che diventino la scelta principale delle strutture dati per la maggior parte dei problemi.

  • So che le tabelle hash e le liste sono le mie strutture dati "goto". So anche che in alcuni casi ho usato tabelle hash quando Red Black Trees o anche AVL Trees sarebbero state scelte migliori. Tuttavia, la tabella hash è più familiare sia per me che per il mio team. E la scelta non influisce molto sulle prestazioni del nostro software.

Le lingue influenzano la scelta fornendo determinate strutture dati come built-in che portano a un maggiore utilizzo.

  • Che si tratti di array in C o tabelle hash in Perl e Python vedo altri (e me stesso) che usano queste strutture dati più spesso perché sono più familiari e più prontamente disponibili.

I programmatori tendono a dirigersi verso un'area durante le loro carriere e rimangono in quella zona.

  • So che gli implementatori di database e file system hanno molta più familiarità con B-Trees e tendono ad usare quella struttura dati in altre cose.

A seconda di ciò che si lavora sulla scelta della struttura dei dati potrebbe non importare molto nella ragione. Notare "entro la ragione". Non sto parlando di usare una stringa di testo libera e una ricerca full-text per contenere dati indicizzati numericamente che dovrebbero essere in una matrice. I motivi per cui potrebbe non avere importanza.

  • Hai a che fare con una piccola quantità di dati.
  • Il collo di bottiglia è esterno al codice che controlli.

Per me una parte dei criteri per il professionista e gli sviluppatori esperti è conoscere più di un paio di strutture di dati, ma soprattutto essere in grado di riconoscere quando le strutture dati "goto" (o anche le strutture che conosci) non sono appropriate . E poi facendo il lavoro e la ricerca per trovare la struttura appropriata e usarla.

    
risposta data 24.03.2012 - 05:39
fonte
0

Penso che dovresti provare lo sviluppo mobile o incorporato . Quindi saprai come utilizzare un oggetto heap non necessario come ArrayList su una matrice primitiva differisce in termini di prestazioni e tempo della batteria.

Il tuo utilizzo delle strutture dati dovrebbe cambiare con il tuo dominio di sviluppo. Come puoi essere così ignorante se stai sviluppando un sistema in tempo reale critico o back-end di un'applicazione web in cui quel modulo sarà sottoposto a un carico pesante?

Se persino non li usi, conoscerli non fa male. Nel tuo caso, se stai sviluppando un'applicazione front-end in cui le aspettative di rendimento sono basse, non dovresti pensare a utilizzare un ArrayList o creare una nuova struttura dati che aumenterà le tue prestazioni di% 20.

    
risposta data 29.05.2012 - 08:47
fonte
0

Alcuni punti rapidi:

  • Quando si tratta di strutture di dati, le loro caratteristiche di prestazione (e le modalità di utilizzo) sono praticamente tutto ciò che le distingue. Ha senso descriverli a questo livello e lasciare che gli sviluppatori scelgano di conseguenza. L'elencazione dei possibili casi d'uso pratico può essere illustrativa, ma sempre incompleta (con un sacco di ipotesi sugli esatti scenari di utilizzo).
  • Sì, l'hardware è diventato molto più potente, al punto che per la maggior parte delle applicazioni quotidiane di programmazione, è abbastanza difficile fare confusione (anche se abbiamo visto alcune eccezioni degne di nota, ne sono sicuro) . Gli scenari in cui la differenza tra O (N) e O (log (N)) fanno una grande differenza non si incontrano più comunemente negli scenari di tutti i giorni. Se mai dovessi lavorare con grandi quantità di dati, sicuramente ti interesserà.
  • Ricorda che la maggior parte dello sviluppo del software è "ottimizzata" per testabilità, leggibilità, manutenibilità, ecc. L'ottimizzazione prematura è vista come un male nello sviluppo di software professionale. È molto più facile lavorare con un hash table che tutti nel mio team sanno di quanto non sia per me scriverne uno. Altrettanto importante, non mi serve tempo per usare quello che c'è già, e posso essere abbastanza sicuro che sia privo di errori.

Da una nota a margine, penso che quello che stai vivendo sia il nostro settore che diventa sempre più maturo nel senso classico. Il tuo programmatore di tutti i giorni non è lì per reinventare gli algoritmi più efficienti, proprio come i meccanici delle auto non dovrebbero inventare un nuovo cambio per la tua auto (sì, è un cattivo tempo di analogia). Siamo ancora lontani da quel livello di maturità, ovviamente, ma non è una sorpresa se il tuo "meccanico" medio è sorpreso dal fatto che non stanno usando tutte quelle teorie che hanno imparato all'università. Tuttavia, se sei il ragazzo della fabbrica che progetta il cambio, ti interesserà sicuramente se si tratta di O (N) o O (log (N)).

    
risposta data 29.05.2012 - 08:47
fonte
0

Penso che imparare le strutture dati per la maggior parte di noi sviluppatori non sia più così importante.

hai una lista (non) ordinata o un tipo di dizionario (hashmap).

Invece implementate contro un'interfaccia elenco e il vostro codice non si preoccupa se l'elenco è un elenco di array, un elenco collegato o un b + -tree. Tutto ciò che conta è l'interfaccia API.

Ovviamente ci sono situazioni rare in cui le prestazioni / memoria sono importanti. Solo allora è necessario conoscere le diverse implementazioni e le loro prestazioni / caratteristiche di memoria. Suppongo che questi casi siano meno dello 0,1% di tutti.

In fase di scolarizzazione impari algoritmi e strutture dati implementandoli. Sul lavoro li trovi in librerie già pronte e li usi.

    
risposta data 29.05.2012 - 11:23
fonte

Leggi altre domande sui tag