This was an email I sent to my team today on some project standards
This should probably be a wiki, or a word document on SharePoint but I’d like to get the ball rolling for a list of ‘standard features’ we want to require/design for in all our applications.
I’m using the term business project to refer to anything related to a given assignment , can anyone think of a better term that would encapsulate the possibility of multiple solution files, multiple visual studio projects, documentation, images, etc..
I think of BLib as a business project which would encapsulate BLibTester, BLib.dll, BLib.vbproj, etc..
This idea should make sense in light of the recent folder structure discussion where you might have multiple solution files.
Also your (UI, database/persistence, and Business Logic/app Domain).
· Multiple projects
o business projects should be at least broken into 3 pieces
§ UI
§ Database/persistence
§ Business Logic/App Domain (should have no dependencies on the other layers)
§ Other Possible layers:
· Controller (UI logic that would be consistent between multiple UI types)
· Testing (this could be a separate test layer, or integrated into the projects themselves, not sure where this would best be placed?)
o Benefits
§ If the dependencies are done right this greatly reduces the number of changes needed to swap out parts
· from one UI type to another
o Asp.net Web forms
o Asp.net MVC
o SilverLight
o Windows Forms
o Windows Workflow
· From one persistence layer to another
o SQL server
o Mainframe
o ISeries
o Teradata
§ Readability/Maintenance – if the UI is malfunctioning check the UI project first, if the business logic needs updating, go to the business logic section, etc..
· Exception logging
o All application should have an error log, or communications log
o Blog for most apps, and most log data
§ Some data may be more appropriately held in the repository, or a local data store on the user’s machine
o Benefits
§ Full logging system with automatic repository fallback is written in BLib.dll
§ Anyone of us can view log information when a program is malfunctioning to speed up the problem location, and possible functions in the code that were involved.
· About section (help->about in most apps)
o Should include detailed dependency information ( a list of all Dlls, their file version, assembly version, and modified date)
o Benefits
§ Anyone can look at the application and see versioning information easily without leaving the program
§ Anyone of us can check the version number of an application with a problem and see if it’s the latest version
§ Anyone of us can look at the dependencies and see if the current problem could be the result of out-dated references
· Business project folder structure consistency
o All solutions and related resources (documentation, images shared between multiple projects in the business project
o All visual studio projects (.vbproj, .csproj, etc..) should reside in subfolders in this folder
o Benefits
§ Consistency greatly improves maintainability, everyone knows where to look on your machine if they sit at your desk to help or just beta test your program for you.
§ Pulling down the entire business project, solution, or just VS project from the version control repository would come down in a consistent layout between projects.
· Version Controlled
o All projects/solutions should be version controlled
o Benefits
§ Anyone of us can pull down the latest source code and review it.
§ Breaking changes can be very easily undone.
§ Multiple levels of undo across months of work instead of just since your last save to disk.
§ You can pull a library into your code and debug your code alongside the library without fear of an auto build saving that out to the main copy
§ I make some important changes to BLib or BDartLib, and don’t save them, there’s a bug in BDartLib or a change to the mainframe, someone else needs to fix it while I’m out of the office, when I come back into the office, I get to compare and merge all 3 change sets(the previous commit, my changes, and your changes) nothing is lost.
§ Automatic change log, all changes can be seen for each commit, so please commit often.
· Common library references to the latest Z drive version
o References should point to the Z drive, not an old project or old dll that was copied from before
o Code should be updated whenever you are opening it for a recompile or change to match the new libraries
o Benefits
§ Instead of digging for an old copy of the project we can use the newest one
§ A system-wide change (think mainframe field movement) would require a change to the single newest-code library and then solutions that depend on it recompiled
§ A systematic change (for example if all libraries have had a bug that wasn’t noticed) would require a change to the single newest-code library and then solutions that depend on it recompiled
§ New features requests (think multiple projects need to show a new field) would not require double or more efforts to update both the newest library, then the older copies, then testing for each, separate recompiling of the dependent solutions for each
· Pivotal Tracker Tracked
o Features, chores, bugs should be entered in Pivotal Tracker for all projects
o Benefits
§ The ticketing system will be able to create tickets in it
§ Any ideas for the project that got pushed aside don’t get forgotten
§ Historical feature, chore, and bug tracking
§ Historical comment/discussion preservation
§ New team mates can get up to speed on a project more easily (we can hope for new team mates in the coming year right?)
· Last use and last user tracking
o Benefits
§ At a glance we could see the last time a business project or specific version/type of business project was used.
§ Already designed for .net3.5 apps
§ We could easily spot users that are continuing to use old versions or whose automatic updates has stopped functioning
§ If audit tracking is also added, we could see frequency
· Test Mode – useful? Worth the large development costs?
o A test mode enables a tester or developer to click around in the application to their hearts content without being afraid something will be permanently changed(mainframe saves, sql server updates/deletes, etc..)
o Drawbacks: difficult to implement
o Benefits: a tester, or developer can fire up the application, place it in test mode and get familiar with it by using it instead of trying to read all the code.
Can anyone think of anymore? Thoughts on any of these?
No comments:
Post a Comment