The Art Of Software Development (part 2): Designing For Simplicity - Building Blocks (Page 3 of 7 )
Once the software development plan is complete, it's time to address thefirst item in your schedule - the software architecture. With therequirements document as your base, you can proceed to develop astructure for your application that meets each of the items within it.
One of the first things you need to do is design your data storagecontainers. These may be either database tables or flat files; youshould select an appropriate container type depending on the performanceand client access requirements. If you're using a database, take timeout to normalize and optimize your design and eliminate redundancies; ifyou're going with flat files, remember to pay adequate attention to filelocking issues.
Break your application up into discrete components or modules - thissimplifies development by allowing you to focus on smaller pieces of thepuzzle at any one time, and also makes the code easier to maintain.Consider using OOP techniques wherever possible. Remember to clearlydefine the input and output interfaces of each object, and theinterfaces between objects. Create standard APIs so that you canimplement "black box" techniques and thereby minimize the impact of achange in one module on other modules.
Make it a point to separate the application's business logic from itsuser interface - this makes it easy to update one without impacting theother. Consider using an interface abstraction layer, like a templateengine, to perform this separation. If your application uses a databaseand you anticipate needing to change it as you scale up, make suredatabase calls are routed through a database abstraction layer so thatRDBMS changes can be accomplished with minimal effort.
Exception handling is a critical part of application design. Ensure thatyour application code uses a flexible exception handler, and spend sometime identifying and listing the various types of errors that couldoccur - this list will come in very handy when you sit down to codeyour exception handler. If your application needs to generate reports orlogs, study the various standard log formats, as well as therequirements of your customer, and develop a report format that is bothunderstandable and easily extensible, so that extra information can beeasily included at a later stage.
You should also spend some time identifying the complete set ofvariables to be used within your application, and making a distinctseparation between configuration and user data. If you have transientdata flowing through your application, make sure that you have a clearplan for how this data is to be created, handled and destroyed. Alsomake a note of which variables are global variables (accessible in allmodules) and which ones are local (accessible only to one specificmodule).
Think about the coding standards to be followed when developing thisapplication (block indentation, script header and footer blocks, scriptrevision logs, comments for variable and function definitions and so on)and ensure that it is consistent and easy to understand and use. Ensurethat your coding standard describes the format, style and length offunction names, variable names, file names, and database and tablenames.
If your application needs to be installed to a customer system, spendtime on the application packaging and delivery mechanism. Ensure thatyour packager contains all the functions you will need for a successfulinstallation, and spend time understanding how the application will beinstalled, erased and upgraded with minimal difficulty to its users.
Last but not least, the nitty-gritty of application structure andstorage. Spend some time developing a suitable directory structurewithin which your application code will reside, and clearly demarcatethe locations in which different bits of data are to be stored. If yourapplication files will be named according to a specific notation,consider all cases when defining this naming convention and ensure thatit covers all possible situations.
I should stress at this point that it's important to spend as much timeas possible in this design phase, and to ask yourself fundamental designquestions while developing the system architecture. Sound design can goa long way towards reducing the size and number of bugs; experiencedprogrammers know this, which is why they spend almost sixty to eightypercent of their time on this phase of the development cycle.
Make it a point to review and re-review your initial design to ensurethat there are no flaws in it; it's almost certain that the first ideayou come up with is flawed in some aspect, and you must be prepared todeal with this and improve on your first cut until you're satisfied thatnothing is left to improve on. Simplify as much as possible - and whenin doubt, remember the immortal words of Albert Einsten: "Things shouldbe made as simple as possible, but not any simpler."
Again, all this thinking needs to be captured in a software designdocument, which serves as the base for the actual implementation of thecode. Let's look at that next.
Next: Drawing Class >>
More Practices Articles
More By Vikram Vaswani, (c) Melonfire
/ 4 
