'Прямо совместимое' проектирование программы
Большинство моих вопросов, которыми я попросил здесь до сих пор относительно StackOverflow быть, как реализовать отдельные понятия и методы к разработке основанного на программном обеспечении клона NES через среду XNA.
Небольшие выборки, которые я бросил вместе на свой ПК, относительно работают отлично и все. Кроме я врезался в кирпичную стену. Как я объединяю все эти образцы вместе.
Наличие подтверждения концепции удивительно, кроме тех случаев, когда Вам нужно оно для движения вне просто этого. Мне теперь разбросали образцы об этом, я пытаюсь объединиться, некоторые из них неполный. И теперь я застреваю с chicken-and-the-egg ситуацией того, где я хотел бы включить эти образцы вместе, удостовериться, что они работают, но я не могу без данных тестирования. И у меня нет инструментов для создания данных тестирования, потому что они должны были бы базироваться прочь отдельных частей, которые должны быть соединены.
В моем уме у меня есть кошмары с циклической ссылкой. Для моих демонстрационных данных я надеюсь сохранить его в XML и записать спецификацию - и затем сделать демонстрационные данные вручную - но я слишком параноик из ручного создания XML-файла, полного неправильных данных и возложения ответственность за него на моем коде, или наоборот. Не помогает, что конечный результат моей работы графически ориентирован, который делает это interseting, как диаграмма на экране может визуализироваться в Узлах XML.
Я предполагаю, мой вопрос - это: Какие шаблоны разработки и дисциплины существуют в мире кодирования, которые обращаются к этому типу беспокойства? Я всегда полагался на кодирование "в лоб" и перезапуск проекта с совершенно новой кодовой базой в попытках к далее вдоль моих целей, но я сомневаюсь, что это было бы лучшим способом сделать так.
В рамках моей карьеры колледжа большинство моего программирования должно было работать над простыми проектами, которые вышли из книги, или с данным корректным набором данных и результатом поддающимся проверке. У меня нет этого, поскольку мои собственные документы дизайна, что я прохожу, могли быть ужасно неправильными.
3 ответа
Лично мне нравится заниматься большими проектами, сначала создавая скелетные компоненты и тесты графического интерфейса, а затем постепенно заполняя внутренности серверной части, чтобы убедиться, что тесты проходят и графический интерфейс начинает вести себя должным образом. Начните с простых тестов; даже если они ошибаются, это лучше, чем вообще не иметь тестов.
Для чтения я бы предложил следующее:
- http://en.wikipedia.org/wiki/Rapid_application_development
- http://en.wikipedia.org/wiki/Agile_software_development
Кроме того, я настоятельно рекомендуем вам поместить все в репозиторий с исходным кодом, если вы еще этого не сделали. Google Code хорош, если вы не против того, чтобы он был открытым и общедоступным; origo.ethz.ch имеет хороший бесплатный сервис, который может быть публичным или частным.
Во-вторых, я настоятельно рекомендую вам документировать все по ходу работы и сделать это совместимым с таким инструментом, как doxygen. Большие проекты действительно выигрывают от дополнительной документации. Если вы используете Microsoft Visual Studio и C ++ или C #, ознакомьтесь с их форматом XML-документации:
http://msdn.microsoft.com/en-us/library/b2s063f7.aspx
Удачи!
Похоже, вы пытаетесь откусить сразу слишком много. Если XML-файл слишком велик для уверенного создания вручную, создайте его часть и проверьте это. Ваши первые схемы должны быть очень небольшим подмножеством того, что вы пытаетесь создать. Протестируйте фрагменты сами по себе. Гораздо легче определить, являются ли тестовые данные или ваш код проблемой, если разбить проблему на более мелкие части.
То же самое и с графикой. Если конечный продукт слишком сложен для тестирования, разбейте его на части.
Это не обязательно то же самое, что изолированное тестирование компонентов (хотя это тоже было бы хорошей идеей). Использование того, что у вас уже есть, для создания упрощенных кейсов значительно упрощает тестирование того, что у вас есть, чем попытки создать все сразу.
Вы правы в том, что сами тесты могут быть неправильными, но ваш единственный вариант, когда вы столкнетесь с неудачным тестом, - это определить, был ли базовый код или тестовый код / документы ошибочными. Чаще всего это тестовый код, но у вас не будет уверенности в базовом коде, пока у вас не будет набора проходящих тестов. Как только вы достигнете этой точки, вы сможете более уверенно вносить изменения в базовый код, зная, что у вас есть набор тестов (документов), с помощью которых можно проверить изменения.
В общем, не позволяйте тому факту, что ваш тестовый документ может быть неправильным, удерживать вас от их написания.