Cosa succede se non ho buone idee per implementare una funzione? [chiuso]

A parte parlare con le persone a riguardo (la domanda suggerisce che non hai colleghi sul progetto), spesso trovo un buon approccio per concentrarsi sulle cose che posso fare.

Di solito c'è una parte del codice che so che devo scrivere comunque. Le cose che non so ancora scrivere, vengono sostituite da stub che restituiscono risultati fittizi o usano un'approssimazione abbastanza buona per testare il resto.

Questo ti mantiene produttivo. E quando hai bisogno di implementare il pezzo mancante, hai l'interfaccia. E hai scritto un sacco di codice che circonda il problema, nello stesso dominio problematico, che di solito mi aiuta a generare idee: sai più esattamente ciò che ti viene richiesto, e quali altri input sono disponibili se aiuta a risolvere il problema . Inoltre, spesso la conclusione è che il pezzo mancante non ha bisogno di essere onnicomprensivo come inizialmente pensato.

Se la ricerca fallisce, puoi sempre implementare la prima idea (non necessariamente la migliore) che hai, e poi rifattarla più tardi quando trovi il giusto approccio.

Questo è l'approccio giusto, poiché anche se trovi qualcosa che sembra una buona idea, potrebbe rivelarsi un problema in seguito. Oppure potrebbe essere buono in quel momento, ma in seguito troverai qualcosa di molto meglio. Allora dovrai ancora refactoring.

Quando si esegue questa operazione, assicurarsi di progettare e implementare in modo tale che sia facile da refactoring. Se lo fai correttamente, dovrai modificare solo la parte problematica e non iniziare dall'inizio.

Che ne dici di chiedere ad un'altra persona? Ad esempio, potresti descrivere il tuo problema qui, o, se è più un problema di implementazione, su stackoverflow.com, e chiedere idee. A volte ti sarà già d'aiuto se inizi a scrivere il problema, anche se non ottieni risposte soddisfacenti.

Alcune idee:

• Brainstorm
  Scrivi tutte le idee stupide che hai in mano (su carta o lavagna). Attraversa quelli che non funzioneranno. Continua a scrivere. Includere soluzioni a problemi reali potenzialmente correlati. Ad esempio, mescolare la pittura, mettere un chiodo nel muro o cambiare il tuo olio risolve una similitudine del mondo reale?
• Chiedi aiuto
  Google, chiedi qui, chiedi ai tuoi amici smanettoni, ecc.
• Risolvi un problema correlato
  Non puoi risolvere il problema il , ma puoi risolvere un problema molto più semplice? O uno altrettanto complesso e correlato? Fai quello. Quindi apportare piccole modifiche individuali per avvicinare la soluzione alla soluzione desiderata.
• Inizia a scrivere da fuori in
  Indipendentemente dal fatto che la tua interfaccia sia un servizio Web, una pagina web, un modulo nativo, una telecamera, una tastiera, un monitor, o qualsiasi altra , c'è un'interfaccia Scrivi poche righe di codice / pseudocodice per far funzionare l'interfaccia. Usa metodi magici che non esistono ancora. Fai ricorsivamente lo stesso per ogni metodo magico inesistente. Ottimizza in seguito.

Non c'è niente di sbagliato nell'andare con la soluzione sbagliata. Spesso a volte non ne sai abbastanza del dominio del problema in quel momento. Andando con una soluzione cattiva, andiamo avanti e impariamo di più sul problema. Quindi puoi ancora tornare indietro e rifattorizzare la tua prima soluzione.

Cerco sempre di guardarlo dal punto di vista dell'utente finale. È molto facile pensare a un'idea "cool" come sviluppatore su cui è possibile dedicare un po 'di tempo a lavorare per aggiungere davvero poco alla tua app.

Idealmente vuoi mappare tutte le funzionalità della tua app e assegnarle le priorità in base al beneficio per l'utente finale, personalmente utilizzo MOSCoW , anche se il tuo metodo di priorizzazione è lo stesso per tutto il tempo può essere semplice come un 1 - 5.

Dopo di che, se ritieni ancora che questa funzione sia una parte essenziale della tua app, come hanno già detto le persone, chiedi! Non credo di aver mai riscontrato un problema che alla fine non è stato risolto né da un collega né da quelle brave persone su StackOverflow.

La mia opinione è: mai scrivere codice che funzioni! Dovrebbe essere molto difficile da refactoring in futuro.

È un approccio molto comune per gli sviluppatori (e ovviamente per i PM o i boss). Ho sentito un sacco di tempo "basta farlo funzionare" o "I'll fix later" (più tardi quando ??? never!) Ma, penso che la qualità non sia qualcosa che non puoi ottenere nel bel mezzo del progetto.

Il mio suggerimento è, smettila di pensare al tuo problema per un po '... fai qualcosa di diverso, e, a volte, le soluzioni escono da sole.

Btw, chiedere ad un collega è assolutamente un ottimo modo per risolvere i tuoi problemi.