Architectural Review Board - Please visit my project!
I've been writing and rewriting Nama[1,2,3] for several years now. It's been my introduction to intermediate concepts in computer science.
Nama is an audio recording, mixing and editing application, using Ecasound[4] as the audio engine.
I'm proud of how it has evolved. At first it was all procedural, driven by a command processor loop. Then I added a Tk-based GUI, my first GUI. I added a text interface with a command grammar based on Parse::RecDescent. I introduced OO to separate the code for two different UIs. Then I added classes for tracks, buses and other entities. I added an event system (actually two), serialization, a help system, tests. I created a build system to automatically generate parts of the grammar, the help system, and to merge various files. The code for audio routing has gone through three different design interations: hardcoding, routing by rules, and now, routing by creating and transforming a graph.
I've cleaned up, commented, refactored wherever it could help. I profiled and memoized to speed up my code. I refer to a shelf full of well-respected Perl books, follow PerlMonks and other forums of the Perl community. Most of the really hard stuff I've solved by accreting other programs and libraries, largely from CPAN.
It's been exciting, exhiliariating, and at times laborious, confusing and opaque. I've had users helping to test, suggest features, and occasionally hold my hand.
Despite all my work to keep the code legible, even users familiar with perl have a hard time reading the code. I'm feeling ready for a visit by the architectural review board!
After reading a number of articles advising against the use of global variables. I'm wondering: Should I be encapsulating the 250 or so global variables into objects? (Clearly, yes.)
What about the way classes reach into each other for data?
Maybe I should be re-architecting my tests? Expanding test coverage is hard, but necessary. I'll need a way to build a test environment that includes (or fakes) some WAV files and other project data.
Welcome, ARB, especially those of you who are musicians!
I blog about Perl.
Most of the questions you ask are utterly irrelevant to musicians. If I want a mixer, do I care whether or not its tests are "re-architected," or that the code is all object-y? No.
I would work on improving the documentation, perhaps dividing it into a page for people wanting to use Nama, and one or more for people wanting to extend it.
Hi,
You are correct; the questions are relevant to myself, as dev and maintainer.
Actually, Nama has extensive docs. The only area not described in detail is the GUI. That neglect is deliberate. Most of my users are console users. GUI users are generally interested in more graphics-rich apps. They definitely want to see waveforms, which Nama doesn't offer (yet).
The alternative to globals is passing everything by parameters - i.e. Dependency Injection. I recommend all the writings by Misko Hevery on this subject: http://misko.hevery.com/.
I read a lot, understood a little.
As a first step, I divided my app's core code into 19 modules. While these modules mostly share the main namespace, I added 'our' declarations to each one indicating the variables that that module touches.
Now I can review these functional subsystems, and consider ways to use parameter-passing to replace accessing global variables.
This intermediate step turns out to be very important. Otherwise it's impossible to look at the code and decide where there should be interfaces.