Some Guiding Principles for Software Development June 13, '07 Comments [22] Posted in Learning .NET | Musings | Programming Sponsored By Patrick Cauldwell is one of the architects on our Next Generation Banking System. A while back I asked him to write up our guiding principles for not only educating new developers but also for indoctrinating existing team members into our world view. He published it on his blog as This I Believe...The Developer Edition. It's a great list. Here's a partial listing of the first two levels of his outline. Be sure to visit his post for the complete outline. It's bent towards .NET, because the stuff he's doing is .NET, but the general ideas are usable elsewhere. Our "guiding principles" Test Driven Development Continuous Integration Unit Tests Two kinds of tests Automation is equally possible for both sets of tests All UI development should follow the MVP pattern for ease of testing 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. Limit compile time dependencies on code you don't own Everything not owned by us should be behind an interface and a factory method Define your data contracts in C# (think "active record") All persistent storage should be abstracted using logical interfaces 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 Namespace != assembly name. Roll up many namespaces into one physical assembly if they all must be deployed together. 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 The definition of "done" (or, how do I 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 What guiding principles do you follow at your development shop? Technorati Tags: Code, Programming, Development, List, Principles « The Value of Writing Windows PowerShell ... | Blog Home | A Toy Train for Z » About Scott Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author. About Newsletter Sponsored By Hosting By