Come visualizzare il design di un motore fisico?

Le liste DA fare sono cose meravigliose.

Non sto parlando di // #ODO: commenti blah blah. Voglio dire ottenere un taccuino onesto per Dio.

Non sai mai quando ricorderai qualcosa di importante da fare. Un notebook si siederà tranquillamente e ti farà pensare senza lamentarti di come la tua grafia non verrà compilata. Alcune delle mie idee migliori accadono in bagno (sì, possiedo un notebook impermeabile ma non devi andare così lontano).

Puoi ottenere quelli tascabili che sono cuciti (non incollati) in modo che non cadano a pezzi in tasca. Non è riuscito a ottenere una fantasia con un marchio di libro incorporato? Nastro, forbici, nastro e nessuno lo saprà mai.

Quando un'idea ti colpisce, annota. Disegna piccole scatole accanto a ciascuna idea e puoi facilmente contrassegnarla come completata. Metti una scatola nella parte superiore della pagina e sai quando la pagina è finita.

Quale accesso sequenziale non è abbastanza buono per te? Sì, fanno anche i raccoglitori. Tutto questo potrebbe sembrare un po 'troppo, ma è meglio che annegare in post-it o provare a catturare tutto in Jira.

Non lasciare le cose a metà implementate

Mantieni i tuoi miglioramenti piccoli e realizzabili. Non iniziare nulla che non può essere finito in una sola seduta. Se è troppo grande per farlo, scomporlo in piccoli passi. Lascia sempre il codice che compila e passa i suoi test. Oh e non lasciare test che non hai mai visto fallire. Effettuare un test sia in positivo che in negativo è come testare il test.

Smetti di pensare che hai bisogno dell'intero disegno su carta

Ciò che devi fare è catturare il tuo piano in evoluzione. Non sai come andranno le cose quando hai finito, quindi smettila di fingere di farlo. Cattura ciò che hai capito meglio che puoi. Usa un tovagliolo e un pastello, se necessario. Poche persone comprendono comunque il 90% di UML. Usa il modo in cui puoi per mostrare ciò che devi mostrare. Mi concentro sul mostrare le mie interfacce e cosa sa di cosa.

Scrivi note quando interrompi la codifica

Il momento in cui ti toglierai le dita dai tasti è l'ultima volta che capirai cosa hai fatto (e cosa hai pianificato) e lo farai ora. Cattura questa comprensione nel miglior modo possibile in alcune note. Se tutto quello che hai sono commenti, sei ancora legato al computer e probabilmente lascerai una pozzanghera sulla sedia. Ancora una volta, avere un notebook è una cosa fantastica.

In questo modo puoi far atterrare il tuo cervello con garbo, salvare la vescica e riprenderti più tardi senza ricorrere alla caffeina e ai denti strizzati.

"Tutto dovrebbe essere costruito dall'alto verso il basso, tranne che per la prima volta", dicono.

Vorrei iniziare dal livello più basso (ad esempio matematica di base dei dati vettoriali), e ho fatto in modo di capirlo bene e ha una buona copertura di test. Poi avrei creato un altro livello in più, consentendo operazioni più astratte (ad es. Gruppi / entità, rilevamento collisioni, meccanica delle collisioni). Ancora una volta, lo coprirei con i test; mi aiuterebbe a pensare ai veri casi d'uso di queste astrazioni nel motore.

A meno che tu non abbia una buona conoscenza dell'intero motore (ad es. quando riattivi un motore già noto), di solito è bene avere questi strati; ti permette di pensare su un particolare livello in termini del livello precedente, e di solito non molto più profondo. Puoi sperimentare e costruire un livello con nuove astrazioni utili; ciò che risulta essere pratico in realtà spesso devia dalle idee iniziali.

Speriamo che ogni livello sia abbastanza piccolo da non aver bisogno di un diagramma complicato, oppure è facile trovarne uno utile.

Non ho mai incontrato un diagramma di codice complesso che fosse utile. I diagrammi Interazione e ciclo di vita sono comunque utili. Molto spesso un diagramma del genere è limitato a 1-2 livelli ed è quindi semplice.

Quello che di solito trovo più prezioso sono le descrizioni dell'interfaccia e le garanzie fornite da ciascun livello. Per esempio. il formato della matematica vettoriale e cosa succede sugli errori numerici; il formato delle descrizioni di oggetti più grandi (sempre convesse? sempre orientate in senso orario ?, come intersecare? ecc.), i parametri meccanici dell'interazione (come il tempo avanza? come viene gestita la massa? la quantità di moto viene sempre preservata? come vengono calcolate le forze?) quindi interazioni proprie (come gestire l'attrito? la deformazione? la frammentazione? trasformare l'energia meccanica in perdite di calore?).

Ogni livello dovrebbe essere abbastanza piccolo da avere una quantità osservabile di cose che introduce e garantisce che fornisce. Questa descrizione può anche essere scritta senza che sia stato ancora scritto alcun codice di implementazione. Questo riduce la possibilità di determinare che hai fatto qualcosa di terribilmente sbagliato in tre strati profondi; se lo facessi, sarebbe già visibile al massimo già in due strati.

Crea diagrammi dell'architettura! I diagrammi della pipeline OpenGL FrustratedWithFormsDesigner pubblicati nei commenti sono un ottimo esempio per il programma flusso , ma questo è solo uno tipo di diagramma che può essere utile.

Durante la progettazione di diagrammi, si desidera rendere comprensione del codice semplice e intuitivo; questo può comprendere sia concetti di alto livello (come la linea superiore di nodi nel diagramma di una pipeline OpenGL, che dicono qualcosa) o dettagli tecnici molto dettagliati (come un grafico di chiamata a funzioni complete).

Idealmente, la tua documentazione dovrebbe anche rendere il codice facile da capire per gli altri; questo può rendere semplici le revisioni del codice o la collaborazione open-source. Guarda a progetti di grandi dimensioni per vedere come ottengono ciò: quando lavori con centinaia di migliaia o milioni di linee di codice, capire come funziona il programma senza doverlo leggere è di fondamentale importanza per tenere traccia del codice base o per presentarlo ad altri . Il repository Vim, con 1,3 milioni di LOC, ha una documentazione di alto livello (IMO) piuttosto buona per questo in /src/README.txt . Presenta:

• Quale codice in ogni file
• Variabili globali importanti e i loro valori
• Cosa succede nel ciclo principale e quali sono le funzioni che esso chiama
• Cosa succede in ciascuna delle modalità e le funzioni principali che le gestiscono
• Quali caratteristiche di debug native sono

Se voglio contribuire con una patch, generalmente so quale file devo modificare per raggiungere i miei obiettivi senza molto scavare.

Una delle migliori caratteristiche di /src/README.txt di Vim è la facilità con cui si trova e quanto è completa; non è granulare in alcun senso, ma se fai clic sulla cartella src su Github viene caricato automaticamente, e dà la direzione per trovare altro codice o documentazione. Il contrasto con il repository Powershell, che ho cercato di un esempio, ma non è stato in grado di trovare file o file equivalenti in% co_de di Vim. (Un brutto segno per un progetto con 988 mila LOC!)

Alcune cose che potresti desiderare di diagrammi o documenti includono:

• Flusso di programma concettuale (cosa realizza il programma e in che ordine?)
• Grafico di chiamata del flusso / funzione del programma implementato (in che modo il programma raggiunge i suoi obiettivi? Quali funzioni vengono chiamate o le classi create?)
• Che codice c'è in quali file? Qual è lo schema organizzativo e quali sono le regole per determinare dove va una nuova funzione? Se hai un strong schema organizzativo, sapere quale file cercare una determinata funzione o classe sarà facile, anche senza una funzione "trova progetto" IDE o simile a IDE.
• In modo simile, quali file includono quali altri file (relativi a un grafico di chiamata di funzione)?
• Quali classi ereditano da quali altre classi? Qual è lo scopo di ogni classe?

Come puoi creare quei diagrammi? Al tuo livello e per le prime bozze, matita e carta sono probabilmente il metodo migliore / più veloce. Quando i diagrammi e la documentazione diventano più raffinati, puoi esaminare:

• Dot / Graphviz, un insieme di programmi per la generazione di grafici da /src/README.txt file.
• LaTeX / TikZ, uno strumento molto complesso e prolisso per la generazione di grafici o immagini di qualsiasi tipo - potrebbe essere troppo pesante per le tue esigenze, soprattutto perché tutto il posizionamento del nodo è manuale, ma dovrebbe essere tenuto presente, specialmente se pianifichi scrivere un foglio o qualcosa di simile in seguito.
• Per C, .dot di gson si aggancia a egypt e genera un grafico di chiamata gcc . Può essere automatizzato o incorporato in un comando .dot , che è bello!
• In modo simile, GNU make può generare grafici di chiamata di solo testo per C. Esistono strumenti equivalenti per altre lingue, anche se potresti voler allontanarti dagli strumenti automatici in generale - non creare manualmente il grafico può ostacolare la tua comprensione di il codice o fornire un livello di dettaglio inappropriatamente complesso (sapere quali funzioni chiamano cflow è in genere piuttosto inutile).

Prova a utilizzare un diagramma basato su reti di Petri. È possibile tradurre il diagramma in programmi per computer in modo sistematico ed è possibile integrare diagrammi di alto livello con diagrammi di basso livello.

Riferimenti

Elementi di rete e annotazioni: un linguaggio di programmazione visuale di uso generale (2016). Disponibile all'indirizzo link .

Elementi netti e annotazioni per la programmazione del computer: calcoli e interazioni in PDF (2014). Disponibile all'indirizzo link .