Come visualizzare il design di un motore fisico?

Sto realizzando un motore fisico e sta diventando abbastanza difficile tenere traccia di tutto. Spesso quando torno al mio codice dopo una pausa, non ricordo perché non funziona. La maggior parte dei problemi non sono semplici errori di programmazione ma difetti di progettazione nel mio motore fisico. Ecco perché dovrei semplicemente finire di progettarlo prima di programmarlo.

Tuttavia, ho bisogno di un modo per scrivere su carta l'intero progetto del mio motore fisico. Altrimenti, lo dimenticherò domani e mi perderò di nuovo. Un diagramma di classe UML non è affatto appropriato per la progettazione di un motore fisico. Non mi interessano davvero le lezioni ma il processo. Non vedo il diagramma del processo aziendale come veramente utile perché la modellazione di un singolo passaggio (frame) del mio processo non mi aiuterà a capire il comportamento finale del mio motore su molti passaggi.

Quindi, che tipo di diagramma dovrei usare per aiutarmi a tenere traccia del processo? Che tipo di diagramma usano i professionisti per creare un motore fisico?

FARE liste sono cose meravigliose.

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

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

Puoi avere quelli tascabili cuciti (non incollati) in modo che non si sfaldino in tasca. Non sei riuscito a crearne uno di fantasia con un marchio incorporato? Nastro, forbici, nastro e nessuno lo saprà mai.

Quando un'idea colpisce basta annotarla. Disegna piccole caselle accanto a ogni idea e puoi facilmente contrassegnarla come completata. Metti una casella nella parte superiore della pagina e sai quando la pagina è terminata.

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

Non lasciare le cose per metà implementate

Mantieni i tuoi miglioramenti piccoli e realizzabili. Non iniziare nulla che non possa essere finito in una sola seduta. Se è troppo grande per questo, suddividilo in piccoli passi. Lascia sempre il codice che compila e supera i test. Oh, e non abbandonare i test che non hai mai visto fallire. Fare un test sia passare che fallire è come testare il test.

Smetti di pensare di aver bisogno dell'intero disegno su carta

Quello che devi fare è catturare il tuo piano in evoluzione. Non sai come appariranno le cose quando hai finito, quindi smetti di fingere di farlo. Cattura ciò che hai capito nel miglior modo possibile. Usa un tovagliolo e un pastello se devi. Poche persone capiscono comunque il 90% di UML. Usa qualunque modo possibile per mostrare ciò che devi mostrare. Mi concentro sul mostrare le mie interfacce e cosa sa di cosa.

Scrivi note quando smetti di scrivere codice

Nel momento in cui togli le dita dai tasti è l'ultima volta che capirai cosa hai fatto (e cosa hai pianificato) e come fai ora. Cattura questa comprensione nel miglior modo possibile in alcune note. Se tutto ciò che hai sono commenti, allora 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 atterrare con grazia il cervello, salvare la vescica e decollare più tardi senza ricorrere a caffeina e digrignare i denti.

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

Partirei dal livello più basso (ad es. Matematica vettoriale di base) e mi assicurerei di averlo compreso bene e che abbia una buona copertura del test. Quindi costruirò uno strato in più, consentendo operazioni più astratte (ad es. Gruppi / entità, rilevamento delle collisioni, meccanica delle collisioni). Ancora una volta, lo coprirei con i test; mi aiuterebbe a pensare ai casi d'uso reali di queste astrazioni nel motore.

A meno che tu non abbia una conoscenza molto buona dell'intero motore (ad es. Quando ripeti l'implementazione di un noto motore esistente), di solito è bene avere questi livelli; ti permette di pensare a un particolare livello in termini di livello precedente e di solito non molto più profondo. Puoi sperimentare e costruire un livello con nuove utili astrazioni; ciò che si rivela pratico nella realtà spesso si discosta dalle idee iniziali.

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

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

Quello che di solito trovo più prezioso sono le descrizioni delle interfacce e le garanzie fornite da ogni livello. Ad esempio il formato della matematica vettoriale e cosa succede sugli errori numerici; il formato delle descrizioni degli oggetti più grandi (sempre convesso? sempre orientato in senso orario?, come intersecare? ecc.), i parametri meccanici di interazione (come il tempo avanza? come viene gestita la massa? il momento è sempre preservato? come vengono calcolate le forze?) quindi interazioni proprie (come gestire l'attrito, la deformazione, la frammentazione, trasformare l'energia meccanica in perdite di calore è una cosa?).

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

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

Quando si progettano diagrammi, si desidera rendere la comprensione del codice semplice e intuitiva; questo può comprendere sia concetti di alto livello (come la linea superiore di nodi in quel diagramma di pipeline OpenGL, che dice qualcosa) sia dettagli tecnici molto dettagliati (come un grafico di chiamata a funzione completa).

Idealmente, la tua documentazione dovrebbe anche rendere il codice facile da comprendere per altre persone; questo può semplificare le attività di revisione del codice o collaborazione open source. Guarda i grandi progetti per vedere come ottengono questo risultato - quando lavori con centinaia di migliaia o milioni di righe di codice, capire come funziona il programma senza doverlo leggere è estremamente importante per tenere traccia della base di codice o presentarla ad altri . Il repository Vim, con 1,3 milioni di LOC, ha una documentazione di alto livello (IMO) abbastanza grande per questo in /src/README.txt . Introduce:

• Quale codice fa in ogni file
• Importanti variabili globali e loro valori
• Cosa succede nel ciclo principale e quali funzioni chiama
• Cosa succede in ciascuna delle modalità e le principali funzioni che le gestiscono
• Quali sono le funzionalità di debug native

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

Una delle migliori caratteristiche di Vim /src/README.txtè quanto sia facile da trovare e quanto sia completo; non è granulare in alcun senso, ma se fai clic sulla srccartella su Github si carica automaticamente e dà indicazioni per trovare altro codice o documentazione. Contrastalo con il repository Powershell, di cui ho cercato un esempio ma non sono riuscito a trovare file o file equivalenti a Vim /src/README.txt. (Un brutto segno per un progetto con 988 mila LOC!)

Alcune cose che potresti voler diagramma o documento includono:

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

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

• Dot / Graphviz, un insieme di programmi per la generazione di grafici da .dotfile.
• LaTeX / TikZ, uno strumento molto complesso e dettagliato per la generazione di grafici o immagini di qualsiasi tipo - potrebbe essere troppo pesante per le tue esigenze, soprattutto perché tutto il posizionamento dei nodi è manuale, ma dovrebbe essere tenuto presente, soprattutto se hai intenzione di scrivere un carta o qualcosa del genere più tardi.
• Per C, di GSON egyptganci in gcce fornisce in uscita un .dotgrafico delle chiamate. Può essere automatizzato o incorporato in un makecomando, il che è bello!
• Allo stesso modo, GNU cflowpuò generare grafici di chiamate di solo testo per C. Potrebbero esistere strumenti equivalenti per altre lingue, anche se potresti voler allontanarti dagli strumenti automatizzati in generale - non creare il grafico manualmente potrebbe ostacolare la tua comprensione del codice o fornire un improprio livello di dettaglio complesso (sapere quali funzioni chiamare di printf()solito è 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 e annotazioni netti: un linguaggio di programmazione visiva per tutti gli usi (2016). Disponibile su https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language .

Elementi e annotazioni netti per la programmazione di computer: calcoli e interazioni in PDF (2014). Disponibile su https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .