Я делаю физический движок, и мне становится довольно сложно следить за всем этим. Часто, когда я возвращаюсь к своему коду после перерыва, я просто не помню, почему это не работает. Большинство проблем - не просто ошибки программирования, а недостатки дизайна в моем физическом движке. Вот почему я должен просто закончить проектирование, прежде чем программировать.
Однако мне нужен способ написать на бумаге весь дизайн моего физического движка. Иначе я просто забуду это завтра и снова потеряюсь. Диаграмма классов UML совсем не подходит для разработки физического движка. Я действительно не забочусь о классах, но о процессе. Я не считаю диаграмму бизнес-процесса действительно полезной, потому что моделирование одного шага (фрейма) моего процесса не поможет мне понять окончательное поведение моего движка на многих этапах.
Итак, какую диаграмму я должен использовать, чтобы помочь мне следить за процессом? Какую диаграмму используют профессионалы для создания физического движка?
Ответы:
Делать списки замечательные вещи.
Я не говорю о // #TODO: комментарии бла-бла. Я имею в виду получить честный для Бога блокнот.
Никогда не знаешь, когда вспомнишь что-то важное. Записная книжка будет спокойно сидеть и позволять вам думать, не жалуясь на то, как ваш почерк не будет компилироваться. Некоторые из моих лучших идей происходят в ванной комнате (да, у меня есть водонепроницаемый блокнот, но вам не нужно заходить так далеко).
Вы можете получить карманные, которые сшиты (не склеены), чтобы они не развалились в вашем кармане. Не удалось получить модный со встроенной закладкой? Лента, ножницы, лента и никто никогда не узнает.
Когда идея приходит в голову, просто запишите ее. Нарисуйте маленькие прямоугольники рядом с каждой идеей, и вы можете легко пометить ее как выполненную. Поставьте поле вверху страницы, и вы узнаете, когда страница будет готова.
Какой последовательный доступ недостаточно хорош для вас? Да, они также делают карманные переплеты. Все это может показаться немного большим, но это лучше, чем тонуть в заметках или пытаться запечатлеть все в Jira.
Не оставляйте вещи наполовину реализованными
Держите ваши улучшения маленькими и достижимыми. Не начинайте ничего, что не может быть закончено за один присест. Если это слишком много для этого, то разбейте его на более мелкие шаги. Всегда оставляйте код, который компилируется и проходит тесты. Да, и не оставляйте проходные тесты, которые вы никогда не видели неудачными. Выполнение теста, как успешного, так и неудачного, - это то, как вы тестируете тест
Перестань думать, что тебе нужен весь дизайн на бумаге
Что вам нужно сделать, это захватить ваш развивающийся план. Вы не знаете, как все будет выглядеть, когда вы закончите, так что перестаньте притворяться, что вы это делаете. Захватите то, что вы выяснили так хорошо, как можете. Используйте салфетку и карандаш, если нужно. В любом случае, мало кто понимает 90% UML. Используйте все, что вы можете, чтобы показать, что вам нужно показать. Я сосредотачиваюсь на том, чтобы показать свои интерфейсы и что знает о чем.
Пишите заметки, когда вы прекращаете кодировать
В тот момент, когда вы снимаете пальцы с клавиш, вы в последний раз поймете, что вы сделали (и что вы запланировали), а также что вы делаете сейчас. Запишите это понимание как можно лучше в некоторых заметках. Если у вас есть только комментарии, то вы все еще привязаны к компьютеру и, скорее всего, оставите лужу на стуле. Опять же, иметь ноутбук - это классно.
Таким образом, вы можете изящно посадить свой мозг, спасти свой мочевой пузырь и снова взлететь позже, не прибегая к кофеину и стискиванию зубов.
источник
Don't start anything that can't be finished in one sitting. If it's to big for that then break it down into smaller steps.
. Это одна из самых важных вещей, которые я узнал в промышленности.«Все должно быть построено сверху вниз, кроме первого раза», - говорят они.
Я бы начал с самого низкого уровня (например, базовой векторной математики), и убедился, что хорошо его понимаю и у него хорошее тестовое покрытие. Затем я построил бы еще один слой поверх этого, позволяя выполнять более абстрактные операции (например, группы / объекты, обнаружение столкновений, механика столкновений). Опять же, я бы покрыл это тестами; это помогло бы мне подумать о реальных случаях использования этих абстракций в движке.
Если у вас нет очень хорошего понимания всего движка (например, когда вы повторно внедряете хорошо известный существующий движок), обычно хорошо иметь эти слои; это позволяет вам думать о конкретном слое с точки зрения предыдущего слоя, и, как правило, не намного глубже. Вы можете экспериментировать и создавать слой с новыми полезными абстракциями; то, что оказывается практичным в реальности, часто отклоняется от первоначальных идей.
Надеемся, что каждый слой достаточно мал, чтобы вам не требовалась сложная схема, или просто создать полезную.
Я никогда не сталкивался со сложной диаграммой кода, которая была бы полезна. Тем не менее, полезны диаграммы взаимодействия и жизненного цикла . Довольно часто такая диаграмма ограничена 1-2 слоями и поэтому проста.
Что я обычно нахожу наиболее ценным, так это описания интерфейсов и гарантии, предоставляемые каждым уровнем. Например, формат векторной математики и то, что происходит при числовых ошибках; формат более крупных описаний объектов (всегда выпуклый, всегда по часовой стрелке, как пересекаться и т. д.), механические параметры взаимодействия (как продвигается время, как обрабатывается масса, всегда ли сохраняется импульс, как рассчитываются силы?), тогда собственно взаимодействия (как справиться с трением? деформация? фрагментация? превращение механической энергии в тепловые потери вещь?).
Каждый слой должен быть достаточно маленьким, чтобы иметь заметное количество вещей, которые он вводит, и гарантирует, что он обеспечивает. Это описание может быть составлено даже без написания кода реализации (пока). Это снижает вероятность того, что вы сделали что-то ужасно неправильное в трех слоях; если бы вы это сделали, это было бы видно не более двух слоев глубиной уже.
источник
Составьте схемы архитектуры! Трубопровод OpenGL диаграммы FrustratedWithFormsDesigner размещены в комментарии являются отличным примером для программы потока , но это только один тип диаграммы , которые могут быть полезны.
При разработке диаграмм вы хотите сделать понимание кода простым и интуитивно понятным; это может включать как высокоуровневые концепции (например, верхнюю линию узлов в этой конвейерной диаграмме OpenGL, что-то сказать), так и очень детальные технические детали (например, полный график вызовов функций).
В идеале ваша документация должна также облегчить понимание кода другими людьми; это может упростить проверку кода или совместную работу с открытым исходным кодом. Посмотрите на большие проекты, чтобы увидеть, как они этого добиваются - при работе с сотнями тысяч или миллионами строк кода понимание того, как работает программа без необходимости ее чтения, чрезвычайно важно для отслеживания базы кода или представления ее другим. , В репозитории Vim с 1,3 млн. LOC есть отличная документация высокого уровня (IMO) для этого в /src/README.txt . Это вводит:
Если я хочу добавить патч, я обычно знаю, какой файл мне нужно изменить, чтобы достичь своих целей без особых усилий.
Одна из лучших особенностей Vim -
/src/README.txt
это то, насколько легко ее найти и насколько она всеобъемлющая; в любом случае это не гранулярно, но если вы щелкнете поsrc
папке на Github, она автоматически загрузится и даст указание найти другой код или документацию. Сравните это с репозиторием Powershell, который я искал в качестве примера, но не смог найти какой-либо эквивалентный файл или файлы Vim's/src/README.txt
. (Плохой знак для проекта с 988 тыс. LOC!)Некоторые вещи, которые вы можете захотеть построить в виде диаграммы или документа:
Как вы можете сделать эти диаграммы? На вашем уровне, и для первых проектов, карандаш и бумага, вероятно, лучший / самый быстрый метод. Когда диаграммы и документация станут более четкими, вы можете изучить:
.dot
файлов.egypt
крючках вgcc
и выводит.dot
граф вызовов. Может быть автоматизирован или встроен вmake
команду, что приятно!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 .
источник