Il "non reinventare la ruota" ignora i limiti della memoria umana?

In primo luogo, è necessario imparare a identificare "componenti" che sono generici / riutilizzabili a sufficienza che è probabile che esistano già 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 passano innumerevoli ore sullo stesso problema probabilmente avrà prodotto una soluzione migliore di quanto tu possa mai essere in grado di fare. Ciò non significa che devi mai "reinventare la ruota", ma se scegli di farlo, è meglio avere una buona giustificazione DAMN per farlo.

There's such an emphasis on reusing abstractions in programming that I often feel a dilemma between: 1) just coding something short and dirty myself or 2) spending the same time to find someone else's more robust library/solution and just using that.

Vale la pena ricordare che anche se ti ci vuole lo stesso tempo per trovare una libreria / soluzione esistente come per scrivere da solo, ricorda che farlo da solo significa anche che avrai per mantenerlo per sempre . Non stai solo reinventando la ruota, ma anche l'intera squadra dei box per tenerla in funzione. Certo, alcune librerie sono buggy o mal gestite, ma queste sono cose che dovresti tenere a mente quando scegli una soluzione di terze parti.

A volte questo è un segno di inesperienza, sia con il linguaggio particolare che con la programmazione in generale. A volte, però, se l'adattamento non è ovvio, è meglio far scorrere il tuo codice che esattamente cosa vuoi e nient'altro . Le librerie generiche, sebbene spesso utili, possono essere costruite per requisiti che semplicemente non hai, e in alcuni casi questo livello di genericità può renderli più problematici di quanto valga.

Esempio: Per i miei piccoli progetti one-man, non uso mai una libreria di registrazione "reale". Uso le istruzioni print e una piccola configurazione ad hoc. Non voglio essere preoccupato di configurare e configurare una libreria di registrazione che abbia più funzioni di quelle che utilizzerò mai, quando le dichiarazioni di print 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, dovrebbe essere distribuita, ecc.

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

1. Crea il tuo.
2. Costruisci qualcosa sulla soluzione di qualcun altro.

Penso che ci siano momenti in cui entrambe le soluzioni sono appropriate. Per esempio, preferirei evitare di far ruotare il mio parser CSV di ORM se posso evitarlo soprattutto perché è un lavoro piuttosto tedioso. D'altra parte, le biblioteche sono spesso limitate. Direi che per ogni progetto su cui ho lavorato, ho incontrato librerie che risolvono perfettamente il mio problema se non per questa unica lacuna. O a volte una libreria è esattamente ciò di cui hai bisogno quando inizi a fare qualcosa, ma è più dannoso che aiuto una volta che hai bisogno di apportare modifiche.

In generale, tuttavia, sconsiglio di provare a trovare risposte "corrette" perché non esistono. In caso di dubbio, vai con il tuo istinto. Una volta ho sentito qualcuno dire che l'esperienza è definita da quanti stupidi errori fai. Di solito, o imparerai qualcosa o farai qualcosa che funzioni. Ad ogni modo, non è affatto male.

Questo (o qualcosa di simile) mi è spesso capitato in un precedente lavoro in cui il framework soffriva di un severo Inner Platform Effect.

Fondamentalmente, la loro base di codice si è evoluta dai primi giorni di Windows C / C ++, poi ha iniziato a essere compilata sotto 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 molto ben documentata, ma era presumibilmente "The Way" per fare 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 framework interno dell'azienda.

(Okay, 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 che passare il tempo e gli sforzi per trovare un esistente soluzione riutilizzabile.)