| How do I come up with a good design and how do I know it is good? There is no magic series of steps that will guarantee a successful application. Following I have listed some tips from personal experience that will hopefully get you started thinking about how you currently design programs and how you can improve. TIP 1: Understand the Requirements in Detail Obviously, you have to know what problem the application is supposed to solve before you can write the application. The person for which you will be writing the application, or end user, will know non-technical business requirements such as "I need to track customer orders" and hopefully even have some detailed specifications or processes in mind. As the designer of an application, it is your responsibility to expand the level of detail in the end user requirements enough so that an appropriate software system can be developed. Bridging the gap between the end user's business knowledge and your technical knowledge is very important. Keep in mind, end users don't know programming or understand the significance of making different types of changes. For instance, a typical user might not dare to ask you to change a field caption (which is an easy change in Visual Basic), but on the other hand they might involuntarily omit a critical requirement of the system, which totally invalidates your design! The symptom of this problem is after delivery of your program the end user has a lot of questions that begin with "But what about ...?" The way to avoid these problems is to spend a lot of time planning and discussing the requirements of the program with the end user to make sure that both of you understand them completely. Altering a design during the planning stages of a project is a lot cheaper and faster than altering it after the project is finished. A good rule of thumb is to ask questions until you are tired of it, then keep on going! Even though you may not understand all aspects of the user's business, and they will certainly not understand all the technical aspects of programming, it is important to keep an open line of communication. One design tool that may help everyone understand the application is the use of a prototype. A prototype is a partially functional or nonfunctional version of the application to give the user an idea of what the final product will look like. This is easy to do in Visual Basic and can be useful in extracting more requirements from the user. TIP 2: Make Your Design Flexible Flexibility refers to the ability of your programs to adapt to a changing environment. End users will often come up with new requirements as the problem or process the software supports changes over time. A flexible program is able to accommodate minor changes in requirements with minimal or no code changes. For example, suppose you are writing a database application that needs to store when a customer order is placed and shipped. You could store these dates in the following database table: Order# OrderDate ShipDate 12345 1/1/99 1/2/99 Suppose in the future, the users of the program want to add a delivery date. With the previous table design, you will have to add a new column to the database, altering the table design. However, suppose you had originally created the table as follows: Order# DateType AssociatedDate 12345 ORDER 1/1/99 12345 SHIP 1/2/99 12345 DELIVERY 1/3/99 With this more generic table design, the additional requirement of a delivery date is accomplished by simply adding another record to the database. (Of course you may still need to modify the user interface, but these modifications will be easier because it is based on the same underlying database.)  Please Although the second design is more flexible, the first one has the potential to be faster, because everything about an order is stored on one database record instead of three. The key is to understand the requirements well enough to achieve the appropriate balance of flexibility and speed. TIP 3: Keep Code Maintainability in Mind When you writeVisual Basic code, you should try to make it as clear as possible so that yourself and others can maintain it in the future. This means it is important to have documentation at all levels, from comments in the code itself to pictures, flowcharts, and user instructions. Although coding style itself is not necessarily a design issue, making decisions during the design process to use standard coding practices and naming conventions will have a direct impact on a program's maintainability. This is especially important if you work on a development team where more than one person will be working on the same program. Consider, for example, the following section of code: Public Sub ChangeCount(ID as String, NewValue As Integer) Dim OldValue As Integer OldValue = GetCurrentCounter(ID) If OldValue < NewValue then Call UpdateCurrentCounter(ID,NewValue) End Sub This code in the previous function is very simple; it accepts an ID and a new value, and calls some other functions to update a counter if the new value is greater than the old value. However, the purpose behind the function is not very clear. Now, read the following version of the function, which has been rewritten in a clearer style: Public Sub ChangeCount(astrUserID As String, aintNumLogins AS Integer) 'This function updates the login counter for the given user Dim lintCurrentLogins AS Integer lintCurrentLogins = GetCurrentCounter(astrUserID) 'Only update if passed value is greater than current value If lintCurrentLogins < aintNumLogins Then Call UpdateCurrentCounter(astrUserID, aintNumLogins) End If End Sub For more information on declaring variables, p. 140 Notice that there are comments to explain both the general purpose of the function and any sections that may not be already clear to the reader. The variables have been declared with a prefix to indicate the scope (l for local, a for argument) and data type (int for Integer, str for string). The use of indentation, blank lines, and a multi-line If statement makes the code visually easier to comprehend. By deciding on techniques such as these you can create code that people can understand quicker. TIP 4: Design for Reuse Another tip that applies to group application development is reuse. If you write a lot of the same types of programs, you do not want to "reinvent the wheel" each time. For example, if you write a function that connects to a database and returns a recordset, you should be able to use it on all your database projects. If you keep the modules of your program well separated by functional requirements and avoid hard-coding values where appropriate, you can create code that you can use again and again. TIP 5: Test Your Design After you write a program but before it is technically finished, there is usually a testing process to find bugs in the program. The primary goal of testing is, of course, to validate that the program successfully performs the desired tasks. Another goal of an application tester is to attempt to break your application through the use of borderline and invalid input. The same types of "testing to break it" techniques can apply to the design of your program. This is especially applicable in database design because you can often look at the table layouts and joins to see limitations. If you can get the end users to agree to as many absolute facts as possible ("No, there will never be two active management types at the same time") then you can verify that your database design will accommodate their needs. Discussing your plan with other competent developers and trying to shoot as many holes in it as possible also can be a useful activity.
|
