Initial Tips before developing any project 1

[FoxKid]

Hi Guys,
I am going to start developing new project in vfp8.0. Now I want to know some things which should be in mind before starting it.
Its a company having about 100 computers in network.
Now, what comes in my mind is as follows :

1. Make a single directory in my computer with the name of the project.
2. Make different sub-directories such as forms, tables, reports, prgs, menus, bmps, project etc..... and keep files according to that only. i.e keep all forms in forms directory and reports in report directory and so on.
3. make one top-level form.
4. Make its exe and install it on the main server and give shortcut at different workstation or install exe at every workstation with having its default data file in server.

There may be many things which may be missing. Please suggest the ideas to make it more better project.....

Thanks and Regards

 

[darrellblackhawk]

1- Subclass the base classes

2- Use some type of version control repository if the budget allows (i.e. Source Safe, CVS, etc.)

3- Study "Data access patterns" (see note)

4- Design in multi-tiers (see note)

5- If you're running the data and apps off of the server, maybe look into "Terminal Services" if the server is fast enough - the application will be much more responsive.

6- If you don't use "Terminal Services", use mapped drives versus URI's (i.e. p:\pathname\ .vs. \\servername\pathname\)

(Note vis-à-vis items 1, 3, and 4 above, make sure the "User Interface", "Business Rules" (functionality), and the "Data access code" is separate - it'll make life easier when you have to maintain/modify/expand your apps

Darrell

 

[craigsboyd]

darrellblackhawk,

Some wonderful suggestions. Could you expand on the reason for #6? Thanks.

[sub]craig1442@mchsi.com[/sub][sup]

"Whom computers would destroy, they must first drive mad." - Anon​

[/sup]

 

[RickSchummer]

1) Create a common folder with the same subdirectories. As you recognize code/modules/class/reports/etc. that is reusable, move the code to the appropriate common folder. You can start out with your custom set of base classes.

2) Adopt and create some development standards. There are plenty of documents already out there for you to borrow and adopt.

3) If you have not already done so, subscribe to FoxTalk 2.0 and FoxPro Advisor. They will become invaluable resources.

4) Check into going to a conference if you or your employer can afford it, it will repay you many times over.

5) Data drive as much of the application as practical. Set up a configuration table or INI file so you can alter behavior without changing code.


_RAS

http://www.whitelightcomputing.com

VFP MVP

 

[foxwizard]

Foxkid,

Additional tips aside from the above suggestions:

Database:

1. As much as possible, make sure that your tables are normalize so that you can minimize harddisk consumption.

2. Establish a relationship between tables so that you can have a high data integrity of your database and at the same time minimize coding.

Coding:

1. If you are a team and your working with another programmers, establish a common style of programming for easy debugging and easy maintenance of codes.

2. Standardize the structures, coding and logic of an application.

3. Make sure that you have common ways of conventions such as:

3.1 naming
3.2 variables
3.3 constants
3.4 functions
3.5 procedures


Hope these may helps.


Bren
Project Team Head
Philippines

 

[FoxKid]

Thankyou all for your wonderful suggetions.....

Thanks and Regards

Santosh

 

[darrellblackhawk]

craigsboyd:

Sorry for taking so long to get back to you.

I've found that using mapped drives versus uri's is faster most of the time - especially when client machines are authenticated on a domain controller.

That's about it.

Darrell

 

[Olaf Doschke]

I've found that using mapped drives versus uri's is faster most of the time

additional to that: If the server changes in the future, most probably it will have another name, but you could map that new server to the same letter, then migrating to another server is less complicated, although there may be some additional directory structure changes. Always be prepared, that all paths are flexible and put them in a configuration table.

I'd not include the data directory in the project, but put it seperate. Try to reflect the later situation best. Maybe that way:

/vfpprojects
/vfpprojects/project1/backend
/vfpprojects/project1/backend/test
/vfpprojects/project1/backend/production
/vfpprojects/project1/frontend
/vfpprojects/project1/frontend/libs
/vfpprojects/project1/frontend/prgs
etc.
/vfpprojects/project2/backend
etc.

This way you won't get problems with DEs storing relative paths and some other things that get quite hard to change when you first go into production. Or you'll stumble over problems earlier. Even better would be to store the development/test backend on a fileserver, which also makes teamwork easier, because everybody uses the same database version.

You should very early compile a pseudoproductive frontend/backend, which will save you from the horror many people get, when they don't know about READ EVENTS or installshield merge modules for the runtime modules.

Nothing is more depressing than being done with the project itself and then not being able to run the compiled version or distribute the application.

Plan tests with your client at the client site to have early tests of network load etc.

Bye, Olaf.