«Вперед-совместимый» дизайн программы - PullRequest
1 голос
/ 17 июня 2010

Большинство моих вопросов о StackOverflow, которые я задал здесь, были о том, как реализовать отдельные концепции и методы для разработки программного клона NES через среду XNA.

Небольшие сэмплы, которые я собрал на своем компьютере, работают относительно хорошо и все такое. За исключением того, что я ударил кирпичную стену. Как объединить все эти образцы вместе.

Наличие доказательства концепции - это удивительно, за исключением случаев, когда вам нужно выйти за рамки этого. Теперь у меня есть образцы, которые я пытаюсь объединить, некоторые из них неполные. И теперь я застрял в ситуации "курица и яйцо", когда я хотел бы объединить эти образцы вместе, чтобы убедиться, что они работают, но я не могу без данных испытаний. И у меня нет инструментов для создания тестовых данных, потому что они должны быть основаны на отдельных частях, которые должны быть собраны вместе.

По-моему, мне снятся кошмары с круговой привязкой. Что касается моих примеров данных, я надеюсь сохранить их в XML и написать спецификацию, а затем создать образцы данных вручную, но я слишком параноидален, чтобы вручную создавать файл XML, полный неверных данных, и обвинять его в своем коде, или наоборот. Не помогает то, что конечный результат моей работы ориентирован на графику, поэтому он пересекается с тем, как графика на экране может быть визуализирована в XML-узлах.

Полагаю, у меня такой вопрос: какие шаблоны проектирования и дисциплины существуют в мире кодирования для решения этой проблемы? Я всегда полагался на кодирование методом перебора и перезапуск проекта с совершенно новой кодовой базой в попытках продвинуться вперед в достижении моих целей, но я сомневаюсь, что это был бы лучший способ сделать это.

В моей карьере в колледже большая часть моих программ заключалась в работе над простыми проектами, которые вышли из книги, или с заданным правильным набором данных и поддающимся проверке результатом. У меня этого нет, поскольку мои собственные проектные документы, по которым я работаю, могут быть ужасно неправильными.

Ответы [ 3 ]

1 голос
/ 17 июня 2010

Лично мне нравится заниматься большими проектами, сначала создавая компоненты и тесты для скелетного графического интерфейса, а затем постепенно заполняя внутренние функции, чтобы убедиться, что тесты пройдены и графический интерфейс начинает работать так, как нужно.Начните с простых тестов;даже если они ошибаются, это лучше, чем вообще не иметь тестов.

Для чтения я бы предложил следующее:

Кроме того, я настоятельно рекомендую вам поместить все в репозиторий с управлением источниками, если вы еще этого не сделали.Google Code хорош, если вы не возражаете, что он открытый и открытый;У origo.ethz.ch есть хороший бесплатный сервис, который можно сделать общедоступным или частным.

Во-вторых, я настоятельно рекомендую вам документировать все, что вам нужно, и совместить его с таким инструментом, как doxygen.Крупные проекты действительно выигрывают от дополнительной документации.Если вы используете Microsoft Visual Studio и C ++ или C #, прочитайте их документацию в формате XML:

http://msdn.microsoft.com/en-us/library/b2s063f7.aspx

Удачи!

1 голос
/ 17 июня 2010

Вы правы в том, что сами тесты могут быть ошибочными, но единственный вариант, когда вы сталкиваетесь с ошибочным тестом, - это определить, был ли основной код или код теста / документы ошибочными. Чаще всего это тестовый код, но вы не будете уверены в базовом базовом коде, пока не получите набор проходных тестов. Достигнув этой точки, вы сможете более уверенно вносить изменения в базовый код, зная, что у вас есть набор тестов (документов) для проверки изменений.

Скажем так, не позволяйте факту, что ваш тестовый документ может быть неправильным, удерживать вас от их написания.

0 голосов
/ 17 июня 2010

Похоже, вы пытаетесь откусить слишком много сразу.Если файл XML слишком велик, чтобы его можно было уверенно создать вручную, создайте его и протестируйте.Ваши первые схемы должны быть очень маленьким подмножеством того, что вы пытаетесь создать.Проверьте фрагменты сами.Намного легче определить, являются ли тестовые данные или ваш код проблемой, если разбить проблему на более мелкие части.

То же самое относится и к графике.Если конечный продукт слишком сложен для тестирования, разбейте его на куски.

Это не обязательно то же самое, что тестировать ваши компоненты изолированно (хотя это тоже было бы неплохо).Использование того, что у вас уже есть для производства упрощенных кейсов, намного проще проверить то, что у вас есть, чем пытаться произвести все это сразу.

...