I've been thinking heavily about Internet information flow, and software design for the past few weeks. I took some time this morning to put some of those abstract thoughts into words. Much of my recent effort has been consumed by setting up proper development environments for a Ruby on Rails based project which Tyler Gillies has architected.
Start With a Simple and Solid Foundation
A pro move is to begin with a firm understanding of your building blocks, your lower level objects and functions and library utilities. Your confidence in how fundamental objects interact and affect data flow through your system will shorten the often painful process of debugging. It will also provide you with a clearer picture of modular components for higher level design.
Taking the time to unit test (piece wise) your code is also a great way to incrementally approach a more complex problem. Rails framework is complimentary to this method, as component testing is hard wired into the project directory structure. Although unit test writing takes time away from new development, most experts agree the time saved in debugging is well worth the effort. As a guy who's spent TOO MUCH time debugging software, I can respect this outlook.
Levels of Code Design
Most desktop applications have various levels of functional flow. Visual user interfaces wait patiently for user interaction to drive some form of processing, analysis, or visualization forward. Command line programs may have a huge hierarchy of input file control mechanisms. Libraries can be static or dynamic and may well depend on a complex and deep set of other libraries and code.
In the case of web programming, Rails implements a MVC (model view control) design. The library functionality of ruby is based on compiled gems. You can zoom into the model handling (data interfaces), the view (visualization), or the algorithm and program flow (control). This helps to isolate the various components into more manageable byte sized concepts.
Pulling it all together, keep program flow in your conscious mind
This is where much of the above practical habits pay off.
If you started with:
- simple reliable structures and libraries
- and implement unit tests to ensure modular functionality
- and separated out the highest level program flow into data, visualization and control segments
You give yourself, and your team the best chance at producing effective and efficient software quickly, and reliably. When it comes to "zooming out" functionally to the highest level program flow, the above practices allow software designers to have a confident image of their entire system. This is a priceless quality when it comes to planning and implementing changes to a code base, and understanding how those changes will affect the stability of the software.
This is a continuation of practical programming tips from the design under stress series, with a correlation to work flow state.
Related articles by Zemanta
- Assertive Code (avdi.org)
- Pigs may not have wings, but I can Ride the Rails with a flu (victusspiritus.com)
- Simplicity is Complicated (avdi.org)
- Codepad (techhotspot.com)
- JetBrains upgrades Ruby IDE (infoworld.com)
- Agile development, startups and government policy (joi.ito.com)