Cosa conta come reinventare la ruota?

Se esiste una soluzione esistente che ai tuoi occhi sarebbe una pratica soluzione, allora non utilizzarla ma creare la tua soluzione sarebbe reinventare la ruota. Oltre a questo, è molto soggettivo.

Informazioni sui tuoi scenari specifici:

1. Desideri sempre un codice pulito, facilmente manutenibile e facile da capire. Questo va sopra reinventando la ruota, IMHO. Il vincolo temporale potrebbe farti voler rompere questo però.
2. Se è più facile iniziare da zero, fallo. Probabilmente otterrai anche un risultato migliore se il codice è stato adattato per la specifica necessità.
3. Se una soluzione è una cattiva soluzione per il tuo problema, non sta reinventando la ruota per crearne una nuova, cioè facendo una ruota migliore .

Reinventare la ruota è ciò che gli altri ti accusano quando la tua analisi indica che dovresti scrivere qualcosa da te e la loro non lo fa.

Penso che reinventare la ruota possa essere definito in modo abbastanza semplice: quando, a lungo termine, si fa più lavoro scrivendolo da solo piuttosto che usare la libreria. Nota che non è sempre chiaro quanto lavoro possa essere a lungo termine . Potresti essere in grado di hackerare insieme un prototipo più velocemente di quanto puoi rifattare il tuo codice esistente per includere la libreria, ma, a lungo termine, quando aggiungi più capacità o devi supportare il codice, la libreria funzionerà meglio.

La linea di fondo è, è necessario fare un po 'di attenzione sulla vostra situazione al momento di decidere se utilizzare o meno una libreria. Devi decidere se la libreria è più facile per ciò che vuoi fare ora e più facile per ciò che farai in futuro . Sapere cosa farai in futuro non è sempre diretto, ma se hai un buon piano, dovresti avere un'idea approssimativa. Detto questo, a volte le previsioni sono imprecise: generalmente non ti rendi conto di aver re-inventato la ruota fino a dopo averla fatta.

È troppo ampio e soggettivo essere in grado di rispondere con qualsiasi accuratezza semplicemente perché ogni caso è diverso.

È perfettamente accettabile reinventare la ruota quando necessario, la chiave sta usando il tuo giudizio per decidere quando la ruota precedente è una soluzione accettabile e quando non è abbastanza rotonda per dare una guida fluida.

È una domanda che deve essere posta quasi retoricamente a volte per garantire che venga utilizzato l'approccio migliore. Puoi trovare spesso un algoritmo migliore in un libro rispetto a la maggior parte i programmatori possono scrivere nel tempo necessario per trovarlo.

Più grande e complesso è il problema, meno probabile esiste una ruota adatta alle tue esigenze e più è legittimo che tu la ricostruisca.

Penso che dovremmo applicare solo "non reinventare la ruota" agli elementi di base (funzioni già costruite nella piattaforma, modelli di design ben noti ...) o se è disponibile la soluzione esatta al tuo problema- ma questo è raramente il caso.

I tuoi 3 punti non contano come reinventare la ruota per me.

Dipende ...

Per i primi due:

• Esiste una soluzione, ma non nella lingua che si desidera utilizzare ...
• In linea di principio potresti ottenere una libreria esistente per fare ciò che vuoi con modifiche pesanti ...

In entrambi questi casi ha senso scrivere il proprio codice. Ma considera questo: la soluzione esistente contiene tecniche, algoritmi o routine da cui potresti imparare? Ignorare questi sarebbe reinventare la ruota.

• Quello che stai scrivendo ha la stessa descrizione di una riga di cose che sono già state fatte ... forse il tuo problema è stato risolto un miliardo di volte prima, ma in un modo che è inefficiente per i grandi insiemi di dati ...

Tre domande:

1. A zillion è molto. Hai veramente esaminato tutte le implementazioni esistenti?
2. L'efficienza è il tuo problema principale?
3. Hai bisogno di codificare la soluzione ottimale ora (e riscrivi più tardi)?

Se la risposta a uno di questi è "No", stai reinventando la ruota.

Detto questo, non sono convinto che reinventare la ruota sia sempre comunque una cosa negativa:

1. È un ottimo modo per apprendi e l'unico modo per capire soluzioni esistenti
veramente
2. Le ruote di altre persone potrebbero non essere buone . È l'unico modo per fare ruote migliori.
3. Anche se le ruote di altre persone sono fantastiche, a volte puoi fare buoni affari creando ruote ancora migliori .

Il tuo primo scenario, si applica per reinventare la ruota, la sua auto-spiegazione.

Il secondo scenario, NON si applica se il codice esistente richiede poche modifiche, ma se lo fa, è una buona idea provare a usare proprietà, metodi e metodi simili rispetto a un codice esistente, quindi altri sviluppatori non hanno problemi con la "ruota".

Fai attenzione all'approccio "è sempre meglio iniziare da scrath", potrebbe essere necessario più tempo del previsto.

Il terzo scenario che citi, è l'approccio "pratico". La "ruota data" può fare il lavoro, ma, in realtà, consuma troppe risorse, memoria, velocità, ecc.

Ho lavorato una volta in un'applicazione che richiede di mostrare i dati gerarchici in un controllo ad albero da una singola tabella. Abbiamo già un controllo che potrebbe farlo, ma supportato diverse tabelle, per articolo.

Per poterlo utilizzare, ho dovuto imparare troppe cose, assegnare troppe proprietà, eseguire troppi metodi e IT era lento. Un collaboratore ha insistito per usarlo, al fine di "non reinventare la ruota".

Ho fatto un nuovo controllo, da zero, ho letto una singola tabella, programma solo alcune proprietà facili da imparare. E prima che me ne accorgessi, c'era un altro collaboratore che l'ha preso dal repository di codice condiviso e ha sostituito il controllo precedente.

Bonus:

Quando la ruota che hai già è "al quadrato". Con "quadrato", intendo che in superficie, sembra che assomigli a una soluzione al tuo problema, ma dopo una buona occhiata, arrivi alla conclusione, no.

Dipende se hai le competenze e il tempo (e l'autorizzazione della tua azienda), per reinventare la ruota.

Per prima cosa leggi questo eccellente articolo di Joel Spolsky: In difesa della sindrome non inventata qui

Quindi tutte le ragioni tecniche diventano sfumature davvero minime. Se ritieni che questo software sia fondamentale per il tuo lavoro, allora riscrivilo. Sì, è "reinventare la ruota", ma probabilmente vale la pena dedicare tempo alla scrittura e al mantenimento. Se non è critico, utilizza solo ciò che è disponibile.

... if you've ever had to outsource a critical business function, you realize that outsourcing is hell. Without direct control over customer service, you're going to get nightmarishly bad customer service -- the kind people write about in their weblogs when they tried to get someone, anyone, from some phone company to do even the most basic thing. If you outsource fulfillment, and your fulfillment partner has a different idea about what constitutes prompt delivery, your customers are not going to be happy, and there's nothing you can do about it, because it took 3 months to find a fulfillment partner in the first place, and in fact, you won't even know that your customers are unhappy, because they can't talk to you, because you've set up an outsourced customer service center with the explicit aim of not listening to your own customers. That e-commerce engine you bought? There's no way it's going to be as flexible as what Amazon does with obidos, which they wrote themselves. (And if it is, then Amazon has no advantage over their competitors who bought the same thing). And no off-the-shelf web server is going to be as blazingly fast as what Google does with their hand-coded, hand-optimized server.

This principle, unfortunately, seems to be directly in conflict with the ideal of "code reuse good -- reinventing wheel bad."

The best advice I can offer:

    If it's a core business function -- do it yourself, no matter what.

Pick your core business competencies and goals, and do those in house...

If you're developing a computer game where the plot is your competitive advantage, it's OK to use a third party 3D library. But if cool 3D effects are going to be your distinguishing feature, you had better roll your own...