1. Every customization must be Feature based solution. Doesn't matter if it’s a Webpart/Event Handler/InfoPath/Content Types or file system change. You can group the features together as solutions. Solution should have event handlers for "Feature activating" and "Feature Deactivated" events wherever applicable. Place the appropriate code in respective blocks. It’s a best practice to have un-installation module in place.
2. Be Descriptive: Ensure that all the features has a appropriate name, description, updated version number, optionally icons.
3. Follow the Four part naming or at-least Three part naming in Name Spaces, Solution names, and in the Target location of the solutions. Don’t just place them inside features folder, But create a four/three part naming folder for each feature and place the supported files inside.
for e.g., rather "statusreport", It would be more meaningful, if it is: Company.Sales.StatusReport.WebPart, Isn't it? This will avoid conflicts and provides better manageability.
4. Follow coding standards. Each and every Solution must be thoroughly evaluated line-by-line and tested in DEV, TEST and then moved to PROD environments. We will do the code review before moving to DEV even. Follow the coding standards(even in variable naming! Preferably PascalCase/camelCase)
5. Avoid de-bugging solution in PROD environment. You can write your code in such a way, Errors are getting logged in to the Event Log / Custom Log file. Fix them in DEV at least. So that it would be easier for de-bugging.
6. We must not deploy debug mode assemblies in PROD - Remove all your Break-Points, and debug codes before packing for PROD. Make sure your code and packages are compiled in release mode.
7. Avoid any manual changes. All changes must be automated. Even a web.config changes should be scripted. Adding Configurable Properties to a SharePoint Web Part’s Tool Pane is preferable.
8. Pay more attention to the Documentation!!!. Pretend like you are giving instructions to the Person who doesn’t know anything about the particular solution.
we need guides which should contain
- Solution abstract, flow, name and version number.
- Activities, configurations, packages, etc. that should be installed or performed before/after the package installation.
- Deployment steps: Detailed steps to deploy or retract the package.
- Unit Test: How to validate that the package is deployed successfully.
- provide the exact steps.
9. Never deploy SharePoint DLLs along with your WSP!!! – what’s the consequences – You will damage SharePoint. How? Your different versions DLL’s from Development box will cause In-compatible operations with PROD SharePoint environment.
10. Never Modify SharePoint’s files in File system. If you must modify have a backup and make the change as solution. E.g. Changing the Core.CSS file for branding.. If you Change the file, It may be overwritten when applying service pack. Never Modify SharePoint Databases!
11. Use WSP Builder Project Template, Use Visual Studio 2008 – No Manual DDF files generation! Use Relative Links Whenever Possible.
12. Maintain versions along with change history in solutions. The assembly version number should be as the solution version number and should be incremented (format V#.#.#). So that we can do upgrade solution, which is faster than going through the complete cycle, it does only upgrade existing features.
13. Use version control system, Like SVN, CVS, TFS and keep all the related artifacts there.
14. Double check your Object disposals. use http://code.msdn.microsoft.com/SPDisposeCheck
15. Don't hard code the parameters in the code, But make them configurable properties.
16. Handle the exceptions properly. Use Try{} Catch{} Finally{} Blocks.
17. Use SPQuery instead of SPList.items when retrieving from Large lists/libraries.
18. Last but not least: Provide excessive comments, Summary in code wherever applicable E.g. Use summary on functions like this:
/// <summary>
/// Function's Summary
/// < /summary>
/// <param Name="param1">
/// Why we need param1?
/// < /param>
/// <returns>
/// What we get from the function
///</returns>
14. Double check your Object disposals. use http://code.msdn.microsoft.com/SPDisposeCheck
15. Don't hard code the parameters in the code, But make them configurable properties.
16. Handle the exceptions properly. Use Try{} Catch{} Finally{} Blocks.
17. Use SPQuery instead of SPList.items when retrieving from Large lists/libraries.
18. Last but not least: Provide excessive comments, Summary in code wherever applicable E.g. Use summary on functions like this:
/// <summary>
/// Function's Summary
/// < /summary>
/// <param Name="param1">
/// Why we need param1?
/// < /param>
/// <returns>
/// What we get from the function
///</returns>
No comments:
Post a Comment