Як візуалізувати конструкцію фізичного двигуна?

Я роблю двигун фізики і мені стає досить важко відстежувати все. Часто, коли після перерви я повертаюся до свого коду, я просто не пам'ятаю, чому це не працює. Більшість питань - це не прості помилки програмування, а недоліки в дизайні мого фізичного двигуна. Ось чому я просто закінчую його розробку перед програмуванням.

Однак мені потрібен спосіб написати на папері всю конструкцію мого фізичного двигуна. Інше, я просто забуду це завтра і знову загублюсь. Діаграма класів UML взагалі не підходить для проектування двигуна фізики. Мені не дуже цікаві заняття, а процес. Я не вважаю діаграму бізнес-процесів справді корисною, оскільки моделювання одного кроку (кадру) мого процесу не допоможе мені зрозуміти остаточну поведінку мого двигуна на багатьох кроках.

Отже, яку діаграму я повинен використовувати, щоб допомогти мені відстежувати процес? Яку діаграму професіонали використовують для виготовлення двигуна фізики?

СТРАХНІ списки - це чудові речі.

Я не говорю про // # ТОДО: коментарі бла-бла. Я маю на увазі отримати чесний для Бога зошит.

Ніколи не знаєш, коли згадаєш щось важливе, що потрібно зробити. Зошит буде спокійно сидіти там і давати вам думати, не скаржившись на те, як складений ваш почерк. Деякі з моїх найкращих ідей трапляються у ванній (так, я маю зошит із водонепроникністю, але вам не доведеться так далеко ходити).

Ви можете отримати кишенькові розміри, які шиються (не склеюються), щоб вони не розпадалися у вашій кишені. Не вдалося розібратися із вбудованою книжковою маркою? Стрічка, ножиці, стрічка і ніхто ніколи не дізнається.

Коли ідея потрапляє, просто запишіть її. Поруч із кожною ідеєю намалюйте маленькі коробочки, і ви можете легко позначити її як виконану. Поставте прапорець у верхній частині сторінки, і ви знаєте, коли це зроблено.

Який послідовний доступ недостатньо хороший для вас? Так, вони також роблять кишенькові палітурки. Це все може здатися трохи схожим, але це краще, ніж утопити у своїх повідомленнях або намагатися захопити все в Джирі.

Не залишайте речі наполовину реалізованими

Нехай ваші вдосконалення будуть невеликими та досяжними. Не починайте нічого, що неможливо закінчити одним засіданням. Якщо він для цього великий, тоді розбийте його на менші кроки. Завжди залишайте код, який компілює і проходить його тести. О, і не залишайте проходження тестів, яких ви ніколи не бачили невдало. Здійснення тесту як прохідного, так і невдалого - це тест на тест.

Перестаньте думати, що вам потрібен весь дизайн на папері

Що вам потрібно зробити, це зафіксувати свій еволюційний план. Ви не знаєте, як все буде виглядати, коли ви закінчите, так перестаньте робити вигляд, що ви робите. Захопіть те, що ви зрозуміли, як можете. Використовуйте серветку і олівець, якщо вам доведеться. Мало хто розуміє 90% UML так чи інакше. Використовуйте будь-який спосіб, щоб показати, що вам потрібно показати. Я зосереджуюсь на тому, щоб показати свої інтерфейси і те, що знаю про що.

Пишіть нотатки, коли ви припиняєте кодування

Щойно ви знімаєте пальці від клавіш, це останній раз, коли ви зрозумієте, що ви зробили (і що планували), як і зараз. Захопіть це розуміння якнайкраще, що ви можете в деяких замітках. Якщо у вас є лише коментарі, ви все ще прив’язані до комп’ютера і, ймовірно, залишите калюжу в кріслі. Знову ж таки, мати зошит - це приголомшлива річ.

Таким чином ви зможете вишукати мозок витончено, зберегти сечовий міхур і знову зняти пізніше, не вдаючись до кофеїну та стискання зубів.

"Все повинно будуватися зверху вниз, крім першого разу", - кажуть вони.

Я б почав з найнижчого рівня (наприклад, основна векторна математика), і переконався, що я це добре розумію, і він має гарне тестове покриття. Тоді я б створив ще один шар поверх цього, що дозволяє робити більш абстрактні операції (наприклад, групи / сутності, виявлення зіткнень, механіка зіткнень). Знову я б покрив це тестами; це допомогло б мені подумати про реальні випадки використання цих абстракцій у двигуні.

Якщо ви не дуже добре розумієте весь двигун (наприклад, коли ви повторно впроваджуєте добре відомий існуючий двигун), ці шари зазвичай добре мати; це дозволяє мислити над певним шаром з точки зору попереднього шару, і зазвичай не набагато глибшого. Ви можете експериментувати і будувати шар з новими корисними абстракціями; те, що насправді виявляється практичним, часто відхиляється від початкових ідей.

Сподіваємось, кожен шар досить малий, що для цього вам не потрібна складна діаграма, або легко знайти корисний.

Я ніколи не стикався зі складною кодовою діаграмою, яка була б корисною. Хоча діаграми взаємодії та життєвого циклу корисні. Досить часто така діаграма обмежується 1-2 шарами, і тому є простою.

Що зазвичай мені найцінніше - це описи інтерфейсів та гарантії, що надаються кожним рівнем. Наприклад, формат векторної математики та те, що відбувається при числових помилках; формат описів великих об'єктів (завжди опуклий? завжди орієнтований за годинниковою стрілкою ?, як перетинатися? тощо), механічні параметри взаємодії (як просувається час? як обробляється маса? чи завжди зберігається імпульс? як розраховуються сили?), то власне взаємодія (як впоратися з тертям? деформація? фрагментація? це перетворення механічної енергії у втрати тепла?).

Кожен шар повинен бути достатньо малим, щоб було помітно кількість речей, які він вводить, та гарантії, які він надає. Цей опис можна навіть скласти без написання (поки що) коду реалізації. Це знижує шанс визначити, що ви зробили щось жахливо неправильне три шари глибоко; якби ви це зробили, це було б видно щонайбільше двох шарів глибоко.

Складіть схеми архітектури! Трубопровід OpenGL діаграми FrustratedWithFormsDesigner розміщені в коментарі є відмінним прикладом для програми потоку , але це тільки один тип діаграми , які можуть бути корисні.

Створюючи діаграми, ви хочете зробити розуміння коду простим та інтуїтивним; це може охоплювати як концепції високого рівня (наприклад, верхній рядок вузлів у тій діаграмі конвеєра OpenGL, що щось говорить), так і дуже деталізовані технічні деталі (наприклад, графік виклику повної функції).

В ідеалі ваша документація також повинна полегшити зрозуміння коду для інших людей; це може зробити такі речі, як огляд коду або співпраця з відкритим кодом. Погляньте на великі проекти, щоб побачити, як вони цього досягають - під час роботи з сотнями тисяч чи мільйонів рядків коду, розуміння того, як програма працює без її читання, має велике значення для відстеження бази даних коду чи його представлення іншим . Репозиторій Vim, що має 1,3 мільйона LOC, має досить велику документацію на високому рівні (IMO) для цього в /src/README.txt . Він представляє:

• Який код у кожному файлі
• Важливі глобальні змінні та їх значення
• Що відбувається в основному циклі, і які функції він викликає
• Що відбувається в кожному з режимів і основні функції, які ними керуються
• Які існують функції налагодження

Якщо я хочу внести виправлення, я, як правило, знаю, який файл потрібно змінити, щоб досягти своїх цілей без особливого копання.

Однією з найкращих особливостей про Vim /src/README.txtє те, як її легко знайти та наскільки всеосяжної; вона не є детальною в будь-якому сенсі, але якщо натиснути srcпапку на Github, вона автоматично завантажується, і вона дає вказівку для пошуку іншого коду чи документації. На противагу цьому репортажу Powershell, яку я шукав для прикладу, але не зміг знайти жодного еквівалентного файлу або файлів для Vim /src/README.txt. (Поганий знак для проекту з 988 тис. LOC!)

Деякі речі, які ви хочете зробити на схемі чи документі, включають:

• Концептуальний потік програми (що програма виконує та в якому порядку?)
• Впроваджений графік виклику потоку / функції програми (як програма виконує свої цілі? Які функції викликаються або створюються класи?)
• Який код є в яких файлах? Яка організаційна схема і які правила у вас є для визначення куди переходить нова функція? Якщо у вас є чітка організаційна схема, знати, який файл шукати для певної функції чи класу буде легко, навіть без IDE або IDE-подібної функції «знайти проект».
• Відповідно, які файли містять інші файли (пов'язані з графіком виклику функції)?
• Які класи успадковують від яких інших класів? Яке призначення кожного класу?

Як можна зробити ці діаграми? На вашому рівні і для перших чернеток олівець і папір - це, мабуть, найкращий / найшвидший метод. Коли діаграми та документація стануть більш доопрацьованими, ви можете вивчити:

• Dot / Graphviz - набір програм для генерації графіків з .dotфайлів.
• LaTeX / TikZ - дуже складний і багатослівний інструмент для створення графіків чи зображень будь-якого типу - це може бути занадто здоровим для ваших потреб, тим більше, що все розташування вузлів є ручним, але слід пам’ятати, особливо якщо ви плануєте написати папір або щось подібне пізніше.
• Для C, gson в egyptгачках в gccі виводить .dotграф викликів. Може бути автоматизовано або вбудовано в makeкоманду, що приємно!
• Так само GNU cflowможе генерувати графіки викликів лише для тексту для C. Еквівалентні інструменти можуть існувати і для інших мов, хоча ви, можливо, хочете відхилитися від автоматизованих інструментів взагалі - не створення графіка вручну може перешкоджати розумінню коду або надавати неналежним чином. складний рівень деталізації (знати, які функції викликають, printf()як правило, досить не допомагає).

Спробуйте скористатися діаграмою на основі Петрі Нетс. Можна схематично переводити діаграму в комп'ютерні програми, а також можна інтегрувати діаграми високого рівня з діаграмами низького рівня.

Список літератури

Чисті елементи та анотації: візуальна мова програмування загального призначення (2016). Доступно за адресою https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language .

Чисті елементи та анотації для комп'ютерного програмування: обчислення та взаємодії в PDF (2014). Доступно за посиланням https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .