Dai consigli da esperto a programmatore principiante su reinventare la mia ruota (soluzione) [duplicato]

Di solito seguo la metodologia di seguito quando si tratta di scenari che stai affrontando:

1. Ottieni la causa principale del problema per la soluzione che stai sviluppando, non è necessario che tutta la logica del codice sia sprecata se la soluzione non viene raggiunta. Se si ottiene correttamente la causa principale, si è in grado di pensare alla nuova logica che può essere collegata per superare la causa principale in questa posizione, è possibile cercare in linea la guida su quella specifica causa principale. In questo modo restringerai la tua ricerca & sarà gestibile.

2. Il tempo di lottare per la soluzione dipende in realtà da due fattori: le scadenze, se presenti, e se non ci sono scadenze fino a quando non si è saturi. Di solito il tempo di circa un giorno per un vero problema è abbastanza buono da iniziare a ripensare su qualche altro approccio. Ci sono alcuni casi in cui, anche dopo aver cercato molto su qualche problema particolare, non è stata trovata una soluzione adeguata in quel momento, la risoluzione del problema potrebbe richiedere anche una settimana in cui bisogna dedicare del tempo a pensare fuori dalle soluzioni che non sono mai state affrontato da chiunque altro fino ad ora. Ad esempio, risolvere il problema della perdita di memoria da un applet Java 3D ospitato su tomcat tramite l'avvio Web.

Suppongo che i punti precedenti coprano le risposte alle tue 3 domande per alcuni aspetti.

Non reinventare la ruota, a meno che tu non abbia validi motivi per farlo.

Se sei a conoscenza dell'implementazione effettiva, ma ritieni di poter fare meglio (il secondo motivo dell'elenco), inizi a spiegare a te stesso che esattamente stai immaginando di migliorare rispetto a soluzione esistente Poi,

• O risolvi il problema,
• Oppure non riesci a risolverlo,
• Oppure, immagino, il tuo caso reale, scopri che non puoi clonare la soluzione esistente in primo luogo, prima ancora di provare ad aggiungere le tue caratteristiche uniche o fare le cose meglio.

Negli ultimi due casi, controlli semplicemente costantemente i tuoi obiettivi e il tuo stato attuale.

• Non codificare solo per lo scopo della codifica. Codice con un obiettivo in mente.
• Non passare ore a scrivere codice non testato e non testabile. Inizia scrivendo i test, quindi esegui il codice stesso.

• Non tentare ciecamente di raggiungere un obiettivo impreciso. Scrivi, se necessario, i precisi requisiti funzionali e non funzionali. Avere gli ultimi è particolarmente importante. Se stai reimplementando qualcosa, assicurati di avere abbastanza requisiti non funzionali che controllano le prestazioni della tua soluzione rispetto a quello che cloni, quanto è documentato, quanto è estensibile, ecc.

  La raccolta e la scrittura di tali requisiti, a proposito, potrebbe spingerti a esplorare più a fondo la soluzione che stai clonando, cosa che alla fine potrebbe condurti alla conclusione che il tuo reale bisogno è già risolto da esso, o che invece di reinventando tutto, potresti semplicemente estendere la soluzione esistente. Ecco un esempio sia di ricerca di funzionalità sconosciute che di estensione della soluzione.

Infine, per quanto tempo continuerai a provare fino a quando capirai che stai seguendo una strada sbagliata dipende dalla tua personalità. Io stesso ho sprecato quattro ore questa domenica cercando di implementare qualcosa in Python (anche se non ho mai usato Python prima), per capire finalmente che ho completamente fallito, e che l'unico modo ragionevole per fare il mio lavoro è di scartare tutto ciò che ho fatto per ore e risolvere il problema aziendale in una lingua che uso quotidianamente negli ultimi sei anni. Altre persone avrebbero trascorso forse un giorno. Altri avrebbero abbandonato dopo un'ora.

Dipende anche dal contesto. Volevo davvero provare qualcosa di "reale" in Python. Se fosse una lingua non ho una buona opinione, avrei abbandonato dopo il primo numero, incolpando la lingua.

Per me la scuola di pensiero è spesso "Questo è un problema ovvio quindi qualcuno deve averlo incontrato prima e dato una soluzione o dei passi verso di esso" che si tratti di un plugin o di una classe di frammenti o quant'altro.

C'è un merito nel provare ad affrontarlo da solo e pensare attraverso il problema, ma, se il tempo è un fattore, perché non approfittare della saggezza collettiva.

Vorrei aggiungere che se si utilizza uno snippet di codice o una classe vale sempre la pena leggere il tutorial e il codice associati in modo da comprendere la soluzione.

Uno dei vantaggi di quel primo passo del tempo di riflessione è quello di aiutarti a focalizzarti su cosa sia effettivamente il problema, quali siano realmente i requisiti e quindi cosa ti serve nella soluzione.

Francamente, cerco sempre prima una soluzione esistente, preferibilmente più di una. Non sprecare il tuo tempo reinventando le cose che esistono, a meno che nessuna delle soluzioni esistenti soddisfi le tue esigenze (nel qual caso, non sono realmente soluzioni, vero?).