Home > SSW Standards > Rules > SSW Rules for Developers
Do you agree with them all? Are we missing some? Let us know
what you think.
-
Do you know how to manage your files?
We need to differentiate between web projects and Windows projects. But we want
the two different types of projects to exist in basically the same location. So
we use the following method.
Create a folder on your working drive (usually C: drive) called
Data<firstname><lastname>
using your first name and last name.
e.g.
C:\DataAdamCogan
Then create the following folders underneath that folder
- ProjectsWinTFS - To store Windows Project / TFS e.g.
C:\DataJohnPrince\ProjectsWinVss
- ProjectsWin - To store Windows Project / Non-TFS e.g.
C:\DataJohnPrince\ProjectsWin
- ProjectsWinTemp - To store Windows Project / Demo/Temporary e.g.
C:\DataJohnPrince\ProjectsWinTemp
- ProjectsWebTFS - To store Web Project / TFS e.g.
C:\DataJohnPrince\ProjectsWebVss
- ProjectsWeb - To store Web Project / Non-TFS e.g.
C:\DataJohnPrince\ProjectsWeb
- ProjectsWebTemp - To store Web Project / Demo/Temporary e.g.
C:\DataJohnPrince\ProjectsWebTemp
What projects do we use Team Foundation Server with:
- Yes - .NET. The master version for VB6 and .NET projects should be kept in
TFS.
If the settings are in Access then the .mdb is in TFS
- No - Access Frontends. As it corrupts the .MDB with all the forms in it
The .MDB and associated files should be stored on a network share
- No - Web Site. Stops you from using front page
- For further information see
Do you know how to use source control properly?
-
Do you keep Backup Versions?
Often we will be asked to "fix up" existing Web or Windows applications. We should
always keep a copy of the original version so we can compare the latest version
with the original. We also keep a rolling 4 versions of the application saved on
a weekly basis. The versions should be saved as following:
- ApplicationName - Current version
- ApplicationName_v001 - Original version - This is NEVER deleted
- ApplicationName_v008 - Oldest version apart from the original
- ApplicationName_v009 - Second oldest version apart from the original
- ApplicationName_v010 - Second youngest version apart from the current version
- ApplicationName_v011 - Youngest version apart from the current version
At the end of the forth week the oldest version is deleted (in the above example
_v008) and the youngest version saved (_v012).
-
Do you create product documentation and make it easily accessible?
- For client projects:
- Make a HTML file for the Client to read. E.g. http://www.ssw.com.au/projects/PA_FRDC
- On that page refer to the:
- For internal products:
-
Do you do Continuous Integration when Developing and Testing? (aka Don't use TFS
as a Network Share)
What is Unit and Integration Testing?
Erich Gamma and Kent Beck started a framework for writing tests during your design
phase. These are widely accepted as very good programming practice (in fact, some
may consider it extreme).
Some background for these people. Erich is a major contributor of the book "Design
Patterns" (must read!). Kent is the author of "Smalltalk Best Practices"
. These are some of the very smart people who pulled together
years of experience and patterns that can be used in the design and development
of goods software.
Their work is JUnit on http://sourceforge.net/Projects/junit/
but that is a framework for Java.
A .NET implementation has been ported, and is at http://sourceforge.net/Projects/nunit/
.
There is a very good article you should read http://junit.sourceforge.net/doc/testinfected/testing.htm
|
Development is to be done in pairs. The process is:
- Check out code
- Do the development (you write test code first)
- Run your tests - keep the errors to 0 - (unit testing)
- Get Latest
- Run your integration tests - keep the errors to 0 - (checks the new build including
setup.exe) (daily)
- Check in code (aim for twice a day, lunch and prior to going home)
Add version numbers to your application. If the code is reviewed by a manager it
must be commented that it has been reviewed. Every application should have a version
table. For every change a new version number with comments should be added into
the version table.
Modules/Classes should have enough comments to explain the logic for a second developer
to understand. After commenting put your initials, this way other developers know
who made the changes.
The project manager should check it before you release the first few versions to
the client, he should finds things like tab order etc...
-
Do you enforce Collective Ownership of code by all developers?
- Developers should not have ownership of code - if you see something wrong fix it
and them email the original developer the fix you made (with the aim he/she learns).
- Pair Programming - two people together write production code
- People move around e.g. Work on other people's code, that way they see all the code
and they work with all the developers
- Developers must write readable code
-
Do you use the SharePoint image as a test environment when you work on sharepoint?
Once you work on sharepoint,you will ask the sharepoint manager for the SharePoint image(about 14GB) to quickly setup a SharePoint test environment.
Please see Product Managers page to find out who is the sharepoint Manager.
-
Do you make sure you have a Release plan for any project longer than 3 days?
Get an OK on a "Test Please" email
Release with a "New Release and Debrief" email generated by Incident PRO
(prefered) or Time PRO! Smart Tags.
So, this is the basic release pattern:
Send Pre-Release Summary for Release 1 to Primary Contact
Complete Release 1
Send "Quick Test Email" to one Tester/Customer - wait for "OK"
Send "New Release and Debrief" to SSWAll/Customer
Send Pre-Release Summary for Release 2 to Primary Contact
Complete Release 2
Send "Quick Test Email" to one Tester/Customer - wait for "OK"
Send "New Release and Debrief" to SSWAll/Customer
And so on.... for the other releases
-
Do you give customers a daily update (aka Reply "Done" to your emails
every day)?
Keep the customer informed. Every time a feature is complete (1 to 3 days)
then let the customer know. You don't have to do this but keeps the customer confidence.
As per above there are a minimum of 3 mini releases (see the breaks in the bullet
list).
See Rules to
Successful Projects regarding project plans and deadlines.
Acknowledgements
Adam Cogan
Cameron Shaw
Tim Fletcher
Edward Forgacs