1. Reuseability
Helper.js is a good thing to share code within a bundle - but not across many bundles. I think a strong library concept is still missing. Actually it's not possible to use CDN due to CSP but they are planning to introduce whitelists. It even looks like whitelists could be already possible:
Requesting CSP Exceptions
If your app is not working due to a CSP violation, contact Salesforce
to request a CSP exception for your org. Include the violation message
from your browser's developer console in any communication.
You can use Static Resources to provide libraries (package- or org-wide).
2. Testing
since it's very js-centric you might use some JS testing frameworks - but I expect salesforce to deliver here somthing.
3. Metadata / IDEs
All the Lightning metadata is available via Tooling API:
Alternatively access via Metadata API is working, too.
As far as I know, Force.com IDE still missing Lightning support. I think they are still on v30 or v31
You might also try a plugin for sublime/Mavensmate.
And CodeFusion actually does support Lightning since last year - however by design still without local files ;-)
But you need this package for lightning support - both, metadata and tooling API (v32) is supported.
I always planned to write a version control integration, but probably before that happens I'm going to open source the project.
A really cool thing about Lightning is the speed for saving files. It's not like apex or visualforce which needs about 3 to 10 seconds to save. Try saving a Lightning file it usually takes 0.300 to 0.800 seconds. First time fun coding! Doug's team unleashed a turbo here.
Best Answer
In addition to what everyone else has said...
The helper is designed to have shared code in it. So, you could have code shared by your renderer and your controller or by multiple controller functions. That should go in the helper JS file.
I think that a good practice is to let the controller respond to events, possibly perform some amount of control flow, and delegate business logic to the helper as a separation of concerns. It also sets you up to be able to reuse your business logic in other parts of the component in the future.
Helper code can be shared among components when they are related through inheritance. If one component extends another it inherits its super component's helper and can override it.
Sub components can call super component controller methods, but that may be deprecated in the future according to the documentation in the Lightning Components Developer's Guide.
Components can communicate with each other via events to "share" code. For example, if you have a component that handles writing business logic errors in a uniform way in your app, and handles some sort of error related event, you could fire an event to trigger it to handle an error.