Dovrei codificarmi da solo?

Bene, questo è molto soggettivo. Penso che ogni programmatore si sia chiesto questo a un certo momento.

Inoltre, dipende molto. C'è una regola d'oro: più persone usano un codice, meglio diventa: è molto testato, è ottimizzato molto, i bug sono minimi, ecc.

Quindi, secondo me, ci sono pochi criteri:

• se hai bisogno di qualcosa per un uso comune (come i normali contenitori - proprio come std::vector o std::list , o puntatori intelligenti (boost)) e non hai bisogno di così tanto rendimento - usa quello esistente, che è "là fuori". Questo ti farà risparmiare molto tempo a programmare, testare, trovare bug. E, come ho detto, più gli sviluppatori lo usano, più bug vengono trovati e risolti velocemente, migliore sarà la lib.
• se hai bisogno di qualcosa di molto specifico:
• • se non stai cercando prestazioni elevate (ad esempio per i sistemi in tempo reale, che dovrebbero elaborare, diciamo, 10.000 messaggi al secondo) e se c'è qualcosa, questo può aiutarti - Suggerirei lo stesso , usa quello esistente
• • le cose sono diverse se hai davvero bisogno di alte prestazioni e LA COSA PIÙ IMPORTANTE - SEI SICURO, CHE LO RAGGIUNGERLO - poi sviluppalo da solo. Posso darti un esempio concreto della mia esperienza: ci sono molte librerie IPC, ma la maggior parte di esse ha molte funzionalità, che noi (io e i miei colleghi della compagnia) non abbiamo bisogno. Quindi, questo rallenta le cose, mentre sviluppiamo software per sistemi in tempo reale, che elaborano molti messaggi al secondo e ogni operazione, ogni millisecondo è importante per noi. Poi abbiamo sviluppato la nostra IPC lib - ci sono voluti molto tempo, molti test, molti bug, ecc., Ma era la soluzione migliore per noi.
    Altro esempio: alcuni contenitori, come std::list o std::vector , hanno davvero grandi funzionalità e molte cose utili. Ma se sei sicuro, che non avrai bisogno di loro e hai davvero bisogno di prestazioni HIGH , e, ancora, sei sicuro, che puoi ottenere questo - potresti implementare il tuo contenitore.

Sai, è davvero soggettivo. Il tempo del programmatore è molto più costoso e prezioso del tempo della CPU o qualcosa del genere. Quindi, se puoi utilizzare qualcosa di esistente e soddisfa (come prestazioni, interfaccia), utilizzalo.

Informazioni su questo: "Farti da solo ti aiuta a capire come funziona, ma non puoi capire tutto sulla programmazione, c'è molto e continua a cambiare". - hai completamente ragione. Per imparare qualcosa, devi fare per praticarlo. Quando scrivi qualcosa di tuo, imparerai molto - molto più che ne parli (dal libro, da internet, dall'articolo, qualunque cosa). Il miglior insegnante è la pratica.

Ma la pratica potrebbe essere fatta a casa, questo ti renderà uno sviluppatore migliore. La maggior parte delle aziende ti pagherà per scrivere codice di qualità, e lo farà più velocemente, con meno bug. Nessuno ti consente di implementare map , ad esempio: sai, è piuttosto difficile e difficile da implementare (devi conoscere alcune strutture di dati avanzate lì - come albero AVL o qualcosa di simile). (e intendo map per un uso casuale, non qualcosa di molto, molto speciale, perché se è qualcosa di specifico - è diverso allora).

Non sono sicuro se ti ho più confuso o aiutato, ma non c'è una risposta corretta per questo:)

Mentre stai ancora imparando e codificando "per divertimento" non c'è niente di sbagliato nella codifica di te stesso - in effetti è probabilmente una buona idea.

Tuttavia, quando si tratta di scrivere software commerciale, si dovrebbero cercare 3 librerie di parti ^rd che possano aiutarti a concentrarti sulla scrittura del codice che è univoco per la tua applicazione. Tuttavia, il tempo impiegato per la codifica di alcune funzioni di base non andrà sprecato. Sarai in grado di utilizzare le conoscenze acquisite per valutare la libreria e decidere se fa quello che ti serve.

Alcune librerie (non necessariamente DirectX) possono avere un bell'aspetto in superficie e funzionare bene nei sistemi di dimostrazione, ma quando le implementate in un sistema reale con volumi reali di dati hanno difficoltà. Con la conoscenza acquisita dall'implementazione del tuo codice "libreria", sarai in grado di individuare questi problemi molto più facilmente, capire se puoi mitigarli e magari anche contribuire con una correzione (se si tratta di Open Source).

A volte mi sento allo stesso modo. Il modo in cui lo vedo è: se ne hai bisogno fatto in fretta, cerca una biblioteca; se hai tempo, l'apprendimento è preferibile perché se qualcosa si rompe sai come risolverlo e non devi aspettare un bugfix.

Un'altra considerazione è se c'è una libreria che dovresti imparare a usare, nel tuo esempio DX se intendi diventare un wiz DX, probabilmente dovresti farlo nel modo DX. Probabilmente preferiremo anche il lavoro a pagamento DX.

Spero che questo aiuti.

Non puoi scrivere tutto da solo. Ci sono anche cose che dovrebbero essere scritte da esperti, inclusi software di sicurezza e complicati modelli in C ++. In ogni caso, è probabile che le librerie di terze parti siano migliori di quelle che potresti scrivere tu stesso, a meno che tu non abbia dedicato molto tempo o le librerie non fossero particolarmente buone.

Se vuoi imparare come scrivere qualcosa, fallo assolutamente. Non usarlo più tardi se si tratta di un software di sicurezza o qualcosa del genere.

Se le librerie non funzionano abbastanza per il tuo scopo, o sono troppo generiche, potresti doverne scrivere la tua.

Scrivi cose nelle tue competenze principali. Se schiaffi un gioco insieme da librerie di terze parti incollati frettolosamente insieme, sarà male. Se scrivi ciò che sei bravo e usi le librerie di terze parti per il resto, sarà molto meglio.

Inoltre, questo dipende dal costo del tuo tempo. Per un'azienda, di solito è più economico comprare qualcosa piuttosto che provare a sviluppare qualcosa di corrispondente in casa, perché i programmatori costano denaro e la biblioteca non è direttamente redditizia. In genere, gli individui non valutano il proprio tempo così tanto e possono trovare reinventare la ruota ricompensando di per sé.

Ho trascorso molti anni a sviluppare Cobol. Non c'erano quasi librerie di codici e dovevamo codificare tutto da soli. La maggior parte dei negozi Cobol disponeva di una propria libreria di subroutine per le procedure più comuni per quel negozio.

Suppongo che anche adesso quando uso Java, tendo a codificare cose che dovrebbero essere gestite dalle funzioni della libreria. Avresti dovuto vedere i miei metodi di elaborazione dell'array Java quando non avevo idea che esistessero classi di raccolta. : -)

Suppongo che la risposta sia, posso codificare il metodo o il processo più rapidamente di quanto possa trovarlo.

Sono felice che tu abbia fatto la domanda, anche se l'hai pubblicata su Stack Overflow. È un bel cambiamento di ritmo dalla domanda "Quali librerie dovrei usare per aggiungere due numeri".

Se farlo tu stesso sarà più piacevole, una buona esperienza di apprendimento di cui potresti beneficiare, o le soluzioni esistenti non sono quello che vuoi, fallo da solo.

Se non hai idea di cosa fare, è complicato da fare, o il tempo è importante, sarebbe meglio usare una libreria di terze parti.

In alcuni negozi, potresti finire per reinventare la ruota a causa di accordi di licenza e commissioni di royalty. Se il negozio non vuole rivelare alcuno dei suoi codici proprietari allora potrebbe dover riscrivere le librerie GPL pubbliche.

La preferenza è usare qualsiasi libreria prima di reinventare il software. Tuttavia, c'è una buona conoscenza ed esperienza da acquisire reinventando la ruota.

Risponderò a questa decisione costruttiva contro l'acquisto. L'utilizzo di librerie di terze parti può accelerare lo sviluppo, ma è possibile che anche un codice lotto venga applicato al lavoro in corso. Il codice extra significa più parti mobili, con implicazioni di prestazioni e affidabilità.

Sei anche costretto a utilizzare lo "schema" dello sviluppatore per affrontare il problema, che potrebbe non essere adatto al tuo stile.

Ad esempio, quando si tratta di consumare API in questi giorni, evito le librerie. La maggior parte delle API Web sono molto semplici e non richiedono ulteriore astrazione. Gli sviluppatori di librerie sembrano aggiungere 3 livelli di API in cima all'API, solo per adattarsi al loro modo di pensare.