"Non reinventare la ruota" ignora i limiti della memoria umana?

Una cosa che mi ha insegnato a lavorare in Haskell e F # è che qualcuno in un'università più intelligente di me probabilmente ha già trovato un'astrazione per quello che sto facendo. Allo stesso modo in C # e nella programmazione orientata agli oggetti, c'è probabilmente una libreria per "it", qualunque cosa stia facendo.

C'è così tanta enfasi sul riutilizzo delle astrazioni nella programmazione che spesso sento un dilemma tra: 1) semplicemente codificare qualcosa di breve e sporco o 2) passare lo stesso tempo a trovare la libreria / soluzione più solida di qualcun altro e solo a usarla.

Come di recente uno dei programmatori qui ha scritto un (de) serializzatore per file CSV, e non potrei fare a meno di pensare che qualcosa del genere è probabilmente molto facile da trovare online, se non è già dotato dello standard .NET API.

Non lo biasimo però, più volte lavorando in .NET ho messo insieme una soluzione basata su ciò che so, solo per rendermi conto che c'era una chiamata al metodo o un oggetto o qualcosa , spesso nella stessa libreria, che faceva quello Volevo e semplicemente non lo sapevo.

Questo è solo un segno di inesperienza o c'è sempre un elemento di compromesso tra scrivere nuovo e riutilizzare il vecchio? Quello che odio di più è quando mi imbatto in una soluzione che già conoscevo e dimenticavo. Mi sento come se una persona non fosse in grado di digerire le enormi quantità di codice che viene preconfezionato con la maggior parte delle lingue al giorno d'oggi.

Innanzitutto, è necessario imparare a identificare i "componenti" che sono abbastanza generici / riutilizzabili da poter già esistere una libreria o una soluzione di terze parti. Una volta che lo fai, renditi conto che, anche se sei un buon sviluppatore, l'esperienza collettiva di innumerevoli sviluppatori che trascorrono innumerevoli ore sullo stesso problema probabilmente avrà prodotto una soluzione migliore di quanto tu possa mai fare. Ciò non significa che non si dovrebbe mai "reinventare la ruota", ma se si sceglie di farlo, è meglio avere una buona giustificazione DAMN per farlo.

C'è così tanta enfasi sul riutilizzo delle astrazioni nella programmazione che spesso sento un dilemma tra: 1) semplicemente codificare qualcosa di breve e sporco o 2) passare lo stesso tempo a trovare la libreria / soluzione più solida di qualcun altro e solo a usarla.

Vale la pena ricordare che anche se ti serve la stessa quantità di tempo per trovare una libreria / soluzione esistente come per scriverlo da solo, ricorda che farlo da solo significa che dovrai mantenerlo per sempre . Non stai solo reinventando la ruota, ma anche l'intero equipaggio dei box per farla funzionare. Certo, alcune librerie sono difettose o mal gestite, ma queste sono cose da tenere a mente quando si sceglie una soluzione di terze parti.

A volte questo è un segno di inesperienza, sia con il linguaggio particolare sia con la programmazione in generale. A volte, tuttavia, se l'adattamento non è ovvio, è solo meglio inserire il proprio codice che fa esattamente quello che vuoi e niente di più . Le librerie generiche, sebbene spesso utili, possono essere costruite per requisiti che semplicemente non hai, e in alcuni casi questo livello di generalità può renderli più problematici di quanto valgono.

Esempio: per i miei piccoli progetti one-man, non uso mai una libreria di registrazione "reale". Uso le printdichiarazioni più una piccola configurazione ad hoc. Non voglio essere disturbato dall'impostazione e dalla configurazione di una libreria di registrazione che ha molte più funzionalità di quelle che userò mai, quando le printdichiarazioni funzionano bene per i miei scopi. Inoltre non voglio ancora un'altra dipendenza che potrebbe non essere compatibile con la versione del compilatore / interprete che voglio usare, che dovrebbe essere distribuita, ecc.

Benvenuti nel mondo della programmazione. Questo problema sarà oggetto di molte divergenze tra te e i tuoi futuri colleghi. Hai due opzioni:

1. Fai il tuo.
2. Costruisci qualcosa sopra la soluzione di qualcun altro.

Penso che ci siano momenti in cui entrambe le soluzioni sono appropriate. Ad esempio, preferirei evitare di girare il mio parser CSV di ORM se posso evitarlo principalmente perché è un lavoro piuttosto noioso. D'altra parte, le biblioteche sono spesso limitate. Direi che per ogni progetto a cui ho lavorato, ho incontrato biblioteche che avrebbero risolto perfettamente il mio problema se non per questo difetto. O a volte una libreria è esattamente ciò di cui hai bisogno quando inizi a fare qualcosa, ma è più dannoso dell'aiuto quando devi apportare modifiche.

In generale, però, sconsiglio di cercare di trovare risposte "corrette" perché non esistono. In caso di dubbio, basta andare con il tuo intestino. Una volta ho sentito qualcuno dire che l'esperienza è definita da quanti stupidi errori fai. Quindi di solito imparerai qualcosa o realizzerai qualcosa che funziona. Ad ogni modo, non è tutto male.

Questo (o una cosa simile) mi è successo spesso in un precedente lavoro in cui il framework soffriva di un grave effetto della piattaforma interna.

Fondamentalmente, la loro base di codice si è evoluta dai primi tempi in Windows C / C ++, quindi ha iniziato a essere compilata in MFC - e così i manutentori hanno iniziato a mescolare MFC e le loro vecchie strutture dati interne e componenti di finestre. La piattaforma interna non era ben documentata, ma si supponeva che "The Way" facesse le cose su quel prodotto, a causa di alcune strutture interne che forniva. Ho spesso trovato più facile e veloce scrivere le mie cose da zero (dai fondamenti di MFC), piuttosto che capire come farlo con il quadro interno dell'azienda.

(Va bene, quindi questo sembra essere quasi l'opposto del tuo punto iniziale - ma il principio è lo stesso, hehe! Sì, a volte è davvero più veloce fare le tue cose piuttosto che passare il tempo e gli sforzi per trovare un riutilizzabile esistente soluzione.)