'Forward-Compatible' Program Design_问答_开发者

The majority of my questions I've asked here so far on StackOverflow have been how to implement individual concepts and techniques towards developing a software-based NES clone via the XNA environment.

The small samples that I've thrown together on my PC work relatively great and everything. Except I hit a brick wall. How do I merge all of these samples together.

Having proof-of-concept is amazing, except when you need it to go beyond just that. I now have samples strewn about that I'm trying to merge, some of them incomplete. And now I'm stuck with the chicken-and-the-egg situation of where I would like to incorporate these samples together, to make sure they work, but I cannot without test data. And I don't have tools to create test data, because they'd need to be based off of the individual pieces that need to be put together.

In my mind, I'm having nightmares with circular reference. For my sample data, I am hoping to save it in XML and write a specification - and then make sample data by hand - but I'm too paranoid of manually creating an XML file full of incorrect data and blaming it on my code, or vice-versa. It doesn't help that the end-result of my work is graphic-oriented, which makes it interseting how a graphic on the screen can be visualized in XML Nodes.

I guess, my question is this: What design patterns and di开发者_高级运维sciplines exist in the coding world that address this type of concern? I've always relied on brute-force coding and restarting a project with a whole new code base in attempts to further along my goals, but I doubt that would be the best way to do so.

Within my college career, the majority of my programming was to work on simple projects that came out of a book, or with a given correct data set and a verifyable result. I don't have that, as my own design documents that I am going by could be terribly wrong.

Personally, I like tackling large projects by first creating skeletal GUI components and tests, and then gradually filling in the backend guts to make sure that the tests pass and the GUI starts to behave as desired. Start off with simple tests; even if they're wrong it's better than having no tests at all.

For reading, I would suggest the following:

http://en.wikipedia.org/wiki/Rapid_application_development
http://en.wikipedia.org/wiki/Agile_software_development

Also, I strongly suggest that you put everything in a source-controlled repository if you haven't already done so. Google Code is good if you don't mind it being open-source and public; origo.ethz.ch has a good free service that can be made public or private.

Secondly, I strongly suggest that you document everything as you go and have it compatible with a tool like doxygen. Large projects really benefit from incremental documentation. If you're using Microsoft Visual Studio and C++ or C#, read up on their XML documentation format:

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

Good luck!

You are correct that the tests themselves could be wrong, but your only option when you encounter a failing test is to determine whether the base code or the test code / documents were in error. More often than not, it is the test code, but you won't have confidence in the underlying base code until you have a set of passing tests. Once you reach that point, you'll then be able to more confidently make changes to the base code knowing that you have a set of tests (documents) against which to verify the changes.

All to say, don't let the fact that your test document might be wrong deter you from writing them.

It looks like you're trying to bite off too much at once. If the XML file is too large to confidently create by hand, create a piece of it, and test that. Your first schemas should be a very small subset of what you are trying to create. Test the fragments by themselves. It is much easier to determine if the test data or your code is the problem if you break the problem into smaller pieces.

The same applies to the graphics. If the final product is too complex to test, break it into pieces.

This isn't necessarily the same as testing your components in isolation (although that would be a good idea too). Using what you already have to produce simplified cases makes it a lot easier to test what you have than trying to produce the whole thing all at once.