Guidelines: For better Software Development
back to content
Main principles: >>
Unit Tests:
- Four kinds of tests: unit, system, integration, acceptance
- Automate your test as much as possible on the dev-environment
- All UI development should follow the MPV pattern for ease of testing
- Make "clean-build" before checking file to avoid error with can arise with the dependent code
Test coverage:
- 90%+ is the goal
- NCover runs as part of the build, and reports are generated
Buy, Not Build:
- Take full advantage of the platform, even if it only solves the 80% case
- Don't write a single line of code you don't have to
- Take full advantage of .NET 3.0, SQL 2005, Windows 2003 Server, plan for- and test on Longhorn.
- Don't invent new solutions to solved problems.
Fewer assemblies is better:
- There should be a VERY good reason for creating a new assembly
- The assembly is the smallest deployable unit, so it's only worth creating a new assembly if it means NOT shipping something else
- Everything not owned by us should be behind an interface and a factory method
- Define data contracts for all persistent storage. It should be abstracted using logical interfaces
- Namespace != assembly name. Roll up many namespaces into one physical assembly if they all must be deployed together.
- Use IoC/Dependency injection for loosely coupling
Only the public interface should be public:
- Only make classes and interfaces public if absolutely necessary
- Test code should take advantage of InternalsVisibleTo attributes
- VS 2005 defaults to creating internal, not public classes for a reason
- If it's public, you have to support it for ever
Windows authentication (good):
- Just say no to connection strings
- Windows authentication should be used to talk to SQL, ADAM, the file system, etc.
- You can take advantage of impersonation without impersonating end users
Tracing:
- Think long and hard about trace levels
- Use formatted resource strings everywhere for localization
- For critical, error, or warning, your audience is not a developer
Error Handling:
- Method names are verbs
- If anything breaks the contract, throw an exception
- Put only GUID to the EventLog, which refers to the log file with the detailed stack-trace logs in the special application folder
The "done" definition - how do know when a task is ready for QA?
- Any significant design decisions have been discussed and approved by the team
- For each MyClass, there is a corresponding MyClassFixture in the corresponding test assembly
- MyClassFixture exercises all of the functionality of MyClass (and nothing else)
- Code coverage of MyClass is >=90%, excluding only lines you are confident are unreasonable to test
- No compiler warnings are generated by the new code
- Before committing anything to source control, update to get all recent changes, and make sure all unit and integration tests pass
- FxCop should generate no new warnings for your new code
- Compiling with warnings as errors will flush out any place you forgot documentation comments, which must be included for any new code
back to content