Come affrontare qualcosa di complesso?

Question

Conosci quella parte particolare del tuo codice che è essenziale per il progetto ma probabilmente ci vorrà molto tempo per farlo? Hai mai la sensazione che preferiresti lavorare su qualcos'altro (probabilmente meno importante) o non codificare affatto invece di lavorare su quella parte? Quella bestia che fai così tanto per evitare e usare ogni trucco pigro che conosci per ritardarne l'immancabile implementazione?

Ora, probabilmente sono solo pigro, ma ho sempre avuto a che fare con un codice del genere. Scrivi qualcosa che non mi va di scrivere (ed è peggio se lo fai per divertimento e non vieni pagato!). Un sistema di grandi dimensioni che impiegherà molto tempo per entrare in una fase in cui si ottengono risultati utili o indicazioni sul funzionamento. Come inizi a scrivere qualcosa del genere? La maggior parte delle persone suggerirebbe probabilmente di dividere e conquistare e tecniche architettoniche simili, ma non si tratta di come lo fai; si tratta di come iniziare a farlo. Quali sono i primi passi che faresti?

Answer 1

Racconterò una storia di un caso in cui questo è successo a me.

Volevo implementare un nuovo algoritmo di decisione frametype per x264 che utilizzava la programmazione dinamica in avanti (l'algoritmo di Viterbi). Ma sarebbe stato complicato, disordinato, brutto e così via. E non volevo davvero farlo. Ho provato a imputare il progetto su Google Summer of Code, ma per una sorta di terribile sfortuna, l'unico studente che abbiamo semplicemente salvato su suo progetto ... è stato lo studente che ha scelto quel progetto.

Quindi dopo due mesi di lamentele e schivate, ho finalmente lavorato sull'algoritmo. Ed ecco come l'ho fatto.

Per prima cosa, ho parlato con l'altro sviluppatore, che apparentemente aveva già qualche idea su come farlo. Ne abbiamo parlato e me lo ha spiegato fino a quando non ho compreso appieno il processo da un punto di vista algoritmico. Questo è il primo passo di qualsiasi progetto di questo tipo: capire l'algoritmo dietro di esso così bene che è possibile pseudocodificare l'intera cosa.

Quindi, ho parlato con un altro mio collega. Siamo andati su una lavagna e l'ho delineato fino a quando lui lo ha capito. Spiegandolo a qualcun altro, ho acquisito la comprensione di me stesso. Questo è il secondo passo: spiegare l'algoritmo a qualcun altro così bene che essi possono pseudocodificarlo. Questa è un'emulazione del processo di programmazione, poiché la programmazione è una forma di "spiegazione" un algoritmo per il computer.

Quindi, ho scritto un semplice prototipo Java che utilizzava valori falsi arbitrari per la funzione di costo e veniva utilizzato esclusivamente per testare la ricerca di Viterbi. L'ho finito e l'ho confrontato con una ricerca esaustiva, che si adattava perfettamente. La mia programmazione dinamica era corretta. Questo è il terzo passo: scrivere la forma più semplice possibile dell'algoritmo nell'ambiente più semplice possibile.

Quindi l'ho portato su C, la lingua madre di x264. Ha funzionato di nuovo. Questo è il quarto passo: porta quella semplice forma dell'algoritmo sull'ambiente completo.

Quindi, infine, ho sostituito la funzione di costo falso con quella reale. Dopo alcuni bughunting e riparazioni, ha funzionato. Questo è il passaggio finale: integrare l'algoritmo completamente con l'ambiente.

Questo processo è durato appena una settimana, ma dal punto di vista di me all'inizio del progetto, è stato del tutto scoraggiante e non sono riuscito nemmeno a iniziare, ma suddividendolo in un tale passaggio processo, sono stato in grado non solo di farlo << a>, ma eseguilo molto più velocemente di quanto mi aspettassi.

E i vantaggi sono andati ben oltre x264; Ora capisco Viterbi così a fondo che ora posso spiegarlo ad altri ... e quegli altri possono trarne grandi benefici. Ad esempio, uno degli sviluppatori di ffmpeg sta usando un adattamento del mio algoritmo e del mio codice per risolvere in modo ottimale un problema un po 'diverso: il posizionamento ottimale delle intestazioni nei file audio.

Answer 2

In genere adoro la parte grande e complessa. Sono le parti che in realtà rappresentano una sfida e mi costringono a considerare attentamente ciò che sto facendo. Sono tutti i pezzi piccoli e noiosi che non mi piacciono. Tuttavia, quando si tratta di fare qualcosa che ho rimandato, trovo importante un semplice consiglio:

APPENA FATTO !!!

Scherzi a parte, una volta avviato è molto più facile finirlo. Trovo sempre di rimandare le cose fino a quando le avvio, poi improvvisamente scopro che, ora che ho iniziato, non è così male come avevo immaginato, e guarda, è quasi già fatto!

Answer 3

Dividi e conquista non si tratta solo di strutturare il codice, ma funziona anche come approccio per rendere concettualmente gestibile un progetto. Se ho difficoltà a iniziare un progetto quasi sempre perché è troppo grande e spaventoso . Dividendosi in pezzi concettualmente gestibili, diventa meno spaventoso.

Credo anche in " proiettili traccianti " come descritto dai programmatori pragmatici. Riduci il progetto nel modo più semplice possibile "prova del concetto" delle parti principali, ad es. senza interfaccia utente, casi speciali, gestione degli errori e così via. Forse sono solo alcune routine di base con unit test. Con questo hai conquistato le parti spaventose e puoi costruire dal profondo.

Fondamentalmente il trucco per iniziare (almeno per me) è: non iniziare l'intero progetto. Inizia da una parte piccola (preferibilmente core) e costruisci da lì. Se ancora faccio fatica a iniziare, è perché la piccola parte che ho deciso è ancora troppo grande, quindi devo dividerla e ridurla ulteriormente.

Answer 4

Sono d'accordo con te sul fatto che molte parti grandi e importanti di un software non sono divertenti da scrivere. Di solito inizio la mia giornata di sviluppo con alcune piccole cose, come l'aggiunta di una funzione qui o la correzione di un bug lì. Quando è il momento, inizio con la maggior parte, ma quando non riesco più a vedere la cosa, faccio qualcosa di diverso. Va bene se fai ancora tutto in tempo. E ricorda che potrebbe rendere le cose più facili se parli con altre persone di quella grande bestia prima di farlo, mentre lo fai e dopo aver finito. Questo non solo libererà la tua mente, ma otterrai anche l'opinione degli altri da un punto di vista meno soggettivo. Pianificare insieme queste cose aiuta anche.

Answer 5

Divertente, sono il contrario. Quando inizio ad affrontare un problema, scelgo per primi quelli più grandi. Il nocciolo del problema è di solito ciò che mi interessa.

Se sto realizzando un progetto per me stesso, di solito non posso preoccuparmi di implementare tutti i bit sfocati attorno ai bordi, quindi non vengono mai eseguiti. Se sto facendo qualcosa per davvero, alla fine arrivo a tutti i bit fuzzy, ma non è la mia parte preferita.

Answer 6

Penso che ci siano due problemi qui.

Il primo è effettivamente iniziare. Come dici tu, può essere piuttosto complicato. Personalmente ho appena iniziato un po ', solo per ottenere qualcosa su carta / schermo. Probabilmente sarà sbagliato e avrà bisogno di essere modificato ma, in generale, è più facile criticare che creare, anche sul tuo stesso lavoro.

Quindi c'è l'effettivo processo di risoluzione dei problemi difficili. C'è un grande libro intitolato " Conceptual Blockbusting " che discute vari modi di affrontare i problemi. Ho imparato molto su come approccio al problem solving e ai miei punti ciechi usando quel libro. Altamente raccomandato.

Answer 7

Cerco di stabilire una metafora di ciò che il sistema sta cercando di fare. Mi sento sempre più a mio agio quando posso descrivere il comportamento in termini di metafora.

Mi rivolgo quindi ad esso da un punto di vista dello sviluppo guidato dai test, ovvero inizio a descrivere cosa deve fare il sistema impostando i test che verificheranno il comportamento corretto.

HTH.

applausi,

Rob

Answer 8

La parte più difficile del progetto sta dal non fare nulla fino alla prima riga. Basta mettere qualsiasi cosa sulla carta per iniziare questo processo ed è sorprendente la velocità con cui il resto può fluire da qui.

Sono un fan dell'approccio " dividi e conquista " -type me stessa.

Quando c'è un compito particolarmente grande in un sistema che incombe su di me, lascio il computer, prendo carta e penna e lo divido in tutti i suoi componenti logici e nel flusso di lavoro.

Quindi prendi ciascuna di queste attività e scomponi le funzioni / chiamate più elementari richieste.

Posso quindi inserire metodi stub che ritengo necessari. e arricchirli uno per uno. A questo punto ognuna di queste "attività secondarie" non è più grande delle attività di sviluppo più piccole in orbita attorno allo stesso progetto, quindi sentiti come un'attività molto meno onerosa che incombe su di me.

Answer 9

Di solito mi occupo di questo tipo di problemi a casa usando una penna e un pezzo di carta. Immagino l'algoritmo e / o il flusso logico e poi stub (sulla carta!) le classi e gli stub del metodo e quando entro davanti a un computer posso farlo molto più facilmente ... Probabilmente sono solo io ..