Hey nysus,
I don't mean to take away from other suggestions here, so I'm going to divert into something I've learned when I set out to re-invent the wheel for learning purposes.
First thing that's a good idea, is to literally write out a point-form list of ALL of the functionality you want to include, including sub-points for top-level ones if they are complex. Don't think about every single detail here, just the general overall functionality you want to provide. You can add/subtract items later.
Next, because apparently you'll be including several other distributions to fulfill your overall objective of consolidation, document down what distributions and functions/methods you'll need for each point you created above. If you know you'll need to add your own or write wrappers around what currently exists, document this. A spreadsheet (or project doc or equivalent) really helps at this point.
Third, go over it all thoroughly. You may spot things you forgot, or need to change.
Fourth, ask around for advice on your plan now that you've completed and revised it. People may know things you're missing, forgetting or essentially just don't know (none of us know everything!).
After that, dig into the code of the modules you'll be using to pull together your plan, and start designing a consistent API around all of the things you plan on putting together. A good idea is to write some tests against your initial functionality as you envision it (a couple of functions at a time), then start writing the code.
Because you've written your tests from the perspective of a "user" using your software, you can then proceed to start writing actual code to match up with the tests. As the tests pass, write your documentation, even if it's in a basic form. I've found that if this isn't done early (even if it needs to be re-written), it often doesn't get done, or is done incorrectly (causing frustration from your users).
On the testing part, don't get ahead of yourself. A few test files for a few pieces of functionality isn't too bad in if you change your mind and then have to re-write everything. Writing too many tests at first may cause you frustration if you do decide to change the API mid-flight (because you haven't even really fully designed it yet). You may have to start over a few times, but at least you've got test code that can be easily modified to fit API changes.
Get some feedback at this point on your API, then start moving forward with more tests, more functionality, more tests, more functionality etc.
Just my 5 cents (because anything below that is rounded nowadays anyhow... at least in Canada (Go Leafs Go! ;)
-stevieb
In reply to Re: Swiss army knife module for files?
by stevieb
in thread Swiss army knife module for files?
by nysus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |