Quali fattori ti influenzano nel provare un nuovo framework o strumento?

• È ESATTAMENTE una soluzione per il problema in questione, almeno sulla carta
• Posso aspettarmi che sarà adottato da un'enorme quantità di sviluppatori, o è già
• Non è uno stupido buzzwordfest
• È stato progettato da persone esperte e ha recensioni positive
• Fa quello che mi serve in almeno 5 volte meno quantità di codice / tempo che dovrei aggiungere / spendere se lo facessi da solo
• È uno standard del settore
• I prototipi cancellano bene
• Il codice / pattern / API è molto chiaro, compatto, diretto al punto
• Sarà supportato a lungo termine o il codice sorgente è disponibile
• Elimina la complessità anziché aggiungerne una nuova
• Nessun sovraccarico di runtime notevole
• Non limita l'estensibilità
• Non ha bisogno di molte dipendenze esterne
• Non è sperimentale
• La licenza è compatibile con il progetto

Tutto quanto sopra, questo praticamente lo riassume.

Per prima cosa controllo il sito web. Se non riesco a capire per cosa è stato progettato il progetto abbastanza velocemente, lo salterò. Alcuni inseriscono molte notizie sulla loro home page, senza specificare in che cosa è stato effettivamente realizzato il software.

Poi controllo la licenza, ci sono un sacco di progetti che non possono essere usati con software proprietario, e alcuni aggiungono cose stupide alla loro licenza, come json.org affermando "Il software deve essere usato per il bene, non per il male". (dal cui giudizio?)

Quindi cerco codice di esempio. Di solito è più rapido avere un'idea del progetto piuttosto che controllare la documentazione. Una documentazione di riferimento è buona, ma il codice di esempio è un must.

Qualsiasi altra cosa è solo un bonus. Se i tre sopra sono ok, sarei disposto a testarlo per vedere se funziona per me.

La tua lista è un buon modo per fare una rapida valutazione, anche se aggiungerei la licenza.

Se sto cercando un prodotto maturo, controllo anche i siti web di lavoro per vedere se qualcuno lo mette come qualcosa che stanno cercando. Di solito un nuovo progetto è di per sé una bandiera rossa, perché se non fa qualcosa che nessun altro fa, non voglio rischiare un nuovo progetto.

Se passa una valutazione rapida e soddisfa una necessità, osservo l'architettura, il design e la qualità del codice sorgente. Quindi provo effettivamente a testarlo, se ha superato tutti i test precedenti.

Per quanto riguarda il livello professionale, per me di solito è un progetto che ha un senso e un progetto che ha una ragione per esistere. Tutto il resto sulla lista è per verificare se l'esecuzione lo rende più prezioso di fastidioso.

Tutto si riduce a due cose (almeno per me):

Necessità : può aiutarmi a risolvere un problema attualmente irrisolvibile o che richiede molto tempo, lavoro e spese generali?

Desiderio : siamo onesti, siamo una folla che gode di uno spettacolo interessante quando si parla di framework e strumenti. Se può stupirci, allora tanto meglio.

La combinazione migliore è ottenere una miscela di questi due. Buona fortuna!

Risolve un problema che ho!

Personalmente ritengo che ci siano troppi "quadri" là fuori. Non avendo molto a che fare con il mondo ".NET" "C #", ritengo che il singolo vantaggio più grande in questo ambiente sia la SM che fornisce un'unica struttura di sviluppo integrata completa.

Il mondo Java in particolare ha troppe strutture in competizione, sovrapposte e incompatibili, nessuna delle quali si distingue come la migliore e tutte hanno lacune e idiosincrasie.