Scrivere il tuo framework o usarne uno esistente? [duplicare]

I'm a pretty new .NET developer and I'm trying to learn stuff like WPF, MVVM, layered architecture design, dependency injection, logging, database access, test-driven development, and many more different technologies/techniques.

Ho visto una bella chiacchierata una volta su come imparare qualcosa velocemente (scusa, non riesco a trovarla):

• Segui la regola 20-80: impara solo il 20% di cui hai bisogno che copre l'80% dei casi d'uso. Non rimanere bloccato nei dettagli. Comprendi le basi e lavora con quelle fino a quando non colpisci un muro. E probabilmente colpirai il muro a un certo punto. Ma avrai coperto un sacco di terreno per allora. Se non c'è modo di coprire la maggior parte del tuo caso d'uso con un uso limitato dello strumento, allora è lo strumento sbagliato per il lavoro e le probabilità sono buone, ce n'è una migliore là fuori.
• Non imparare troppe cose alla volta. Adesso dici che non hai bisogno di nessuno degli strumenti che pensi siano buoni. Va bene. Il tuo prossimo passo non è provarli tutti in una volta. Sceglierne uno. Quello che sembra più utile per il compito a portata di mano. Applicalo. Quando riesci a comprenderlo, procedi con la ricorsione.

But then, at the same time I have those nightmares that I start working in a new company and people tell me "You can't code your own MVVM framework? You always need to use Prism? Hahahahaha!" and they go around pointing and laughing at me in circles.

I feel like I'm a lesser programmer. I feel like I don't have what it takes to create a framework on my own. I feel like I am only able to put things together, which are created by other "better" people.

Alcuni consigli, sebbene non tutti siano specifici per la programmazione:

1. Sbarazzati del tuo ego. Questa è una sfida per la vita affrontata passo dopo passo. Ma ne avrai bisogno. Se sei meno preoccupato per l'immagine di te stesso che stai cercando di proiettare, avrai più tempo per pensare a ciò che hai da dire. La maggior parte delle persone restituirà il favore con rispetto.
2. La domanda che è davvero importante è: cosa puoi fare? Come lo fai, è completamente irrilevante. Tutto ciò che conta per il tuo capo, i tuoi utenti e le persone che costruiscono il loro codice sul tuo è quanto velocemente puoi farlo (cioè quanto costa), quanto è flessibile di fronte alle mutevoli esigenze e quanto è utilizzabile (da prospettiva dell'utente o quando si interfaccia da un altro codice). Non importa se utilizzi uno strumento di terze parti o reinventi la ruota ogni volta da zero. Le conseguenze percepibili lo fanno.
3. Non essere disturbato dagli stronzi. La stragrande maggioranza di coloro che hanno acquisito abilità degne di nota come sviluppatori (o qualsiasi area) sanno quanto tempo e lavoro ci vuole. La maggior parte di loro farà di tutto per aiutarti se glielo chiedi (e poi lascia che ti aiutino). Solo alcuni proveranno a svilirti. Più spesso, quelle sono le persone che sentono il bisogno di compensare la propria mancanza di abilità.
4. Non dare per scontato che ci siano molte persone che riescono a mettere insieme un "framework per scopi generali" da soli. Con "successo", intendo che le persone lo useranno e contribuiranno ad esso e il mainstream lo considererà come una delle soluzioni out-of-the-box per un particolare problema. A quel punto, il progetto è stato ripetutamente ripetuto per almeno mezzo decennio, dopo essere stato costantemente rivisto e migliorato da molte persone e con un feedback di migliaia letteralmente - la maggior parte di tutte le persone coinvolte sono state abbastanza esperte. E il più delle volte, è un successore o un knock-off di qualche altra tecnologia che ha già attraversato l'intero processo di maturazione. Non c'è vergogna nell'usarlo. Al contrario: se risolve il tuo problema, non usarlo è uno spreco di risorse. È spesso un segno di arroganza o ignoranza o la combinazione di entrambi.
   Detto questo: ci sono un sacco di "quadri" gonfiati là fuori che fanno schifo. Come una volta Douglas Adams ha sottolineato, la funzionalità del cervello umano è illustrata al meglio dal suo stupore per le grandi cose. Quando le persone vedono un grande quadro con molta documentazione, ritengono che debba essere buono. Il contrario è spesso vero. È spesso un indicatore di sovraingegnerizzazione. Ma di solito, per qualsiasi problema comune, spesso troverai già una soluzione ben collaudata e ben progettata.

To make a long story short, what constitutes the thin line between using a framework and creating your own? And more importantly, how do you close the knowledge gap that automatically comes up if you use a technology/technique without seeing the real-world problems they help with?

1. Quando uno strumento ha finito, usalo. Capire "il lavoro" è la cosa più difficile. Questo è il primo e più importante passo. Quindi devi scegliere i tuoi strumenti. E poi fallo. E poi potresti capire che la tua comprensione del "lavoro" è appena migliorata, quindi devi aggiungere / sostituire alcuni strumenti e parti del programma. La probabilità che questo accada è parte del "lavoro" ed è un fattore importante nella scelta del set di strumenti iniziale.
2. Preferiresti avere un incidente in un'auto di 50 anni per apprezzare tutta la sicurezza costruita in uno moderno? Io non la penso così Hai le tue fette di inferno che vengono comunque. Non è assolutamente necessario chiedere ulteriori problemi.
   Devi sempre scegliere cosa sapere, ma anche cosa non sapere. Questo è il fondamento dell'occultamento delle informazioni, che è il dividere e conquistare dei sistemi complessi. Il tuo linguaggio di programmazione è già una grande nuvola bianca in alto nella astrosfera del pianeta ugglydetailia. Osservi le cose da un livello astratto, perché il tuo cervello può effettivamente funzionare solo in questo modo. È come ci si confronta con il mondo reale ed è sensato applicarlo alla programmazione.
   Inoltre, la conoscenza di per sé non ha valore. Il valore viene dalla comprensione. Che abbastanza spesso implica la conoscenza di cosa non sapere;)

Praticare l'abilità nel modo sbagliato non ti aiuta a impararlo. Avrai molte possibilità quando lo fai per sbaglio o per mantenere il codice che è stato fatto male da qualcun altro.

Trovo anche affascinante che in questo tipo di domande le persone si preoccupino solo dello strato più alto di astrazione. Stai costruendo su decenni di programmazione della ricerca linguistica, paradigmi di progettazione, sistemi operativi, database, architettura di computer, tecnologia CMOS, giù, ma sei solo preoccupato di non capire le ragioni delle innovazioni negli ultimi 10 anni o giù di lì.

Quando le persone hanno iniziato a creare pagine Web, non esistevano strutture come le strutture. Tra dieci anni, ci saranno miglioramenti alle cose che hai imparato nel modo più duro, e un principiante si chiederà se capiranno abbastanza bene le ragioni sottostanti per tali miglioramenti e prenderà completamente TDD, dipendenza, MVVM, ecc. Come dato. Ci sono persone che ancora lavorano che ricordano quando c'era questa nuova idea che avrebbero dovuto rompere le cose in funzioni relativamente piccole.

In altre parole, non preoccuparti di mancare dell'esperienza dei precedenti dieci anni. Nei prossimi dieci anni sarà richiesto un nuovo tipo di esperienza.

Come tutti i bravi programmatori, continuerai a fare tre cose: apprendi qualcosa di nuovo, scopri nuovi problemi, costruisci soluzioni. Più tempo trascorri a scrivere codice (creazione di soluzioni), meglio riuscirai ad ottenere gli altri due, perché potrai svelare nuovi problemi e imparare qualcosa di nuovo che è utile.

Vuoi sapere come o quando utilizzare un nuovo framework o una nuova metodologia, ma pensa a qualcosa di un po 'più semplice come il ciclo di scrittura del commento:

1. Tutti gli esempi di codice pubblicati commentano tutto.
2. A causa di limiti di tempo, commenti inutili e nessuno rivede il tuo codice e ti costringe a scrivere commenti, non ne scrivi affatto.
3. Torna al vecchio codice e scopri che è difficile da capire.
4. Ricerca il modo migliore per scrivere commenti e scoprire tutte le scuole di pensiero: devi scriverle o altro, usare uno strumento per commentare, scrivere un codice auto-commentante perché i commenti diventano obsoleti, ecc.

Forse i commenti non sono il problema? Come tutto il resto, non lo farai bene la prima volta. Questo è il motivo per cui i mentori sono così importanti (e spesso carenti) nel processo di sviluppo dei nuovi programmatori. C'è troppo da fare per tentativi ed errori tutto. Potresti passare tutta la tua carriera e non avere mai bisogno di un ORM perché non scrivi mai un'app che utilizza un database.

Voler imparare le cose è un ottimo strumento per uno sviluppatore purché sia una sana curiosità e non un'ossessione che ti impedisce di ottenere qualcosa di costruito. Il TDD può aiutarti perché ti concentri solo sulla realizzazione del requisito codificando quanto basta per superare il test. Alla fine, codifichi qualcosa e giunga alla conclusione: "Deve esserci un modo migliore per farlo". Vai a trovare un quadro o scrivi il tuo.