Best Practices for any Sitecore Project

With every new project, the situation is a little bit different, some times you feel like you have the whole time in the world and sometimes time is just not enough no matter what.  It depends on timeline, scope, budget and many many other things actually.

In my recent Sitecore project I am working on, fortunately I am getting enough time to craft and think about every single decision on my way.  This feels so good as I can beautifully craft a solution that is great functionally and from marketing perspective.

With start of every build phase of the project, based on team and project, I make a quick checklist for Developers and team to go over before they submit for code review.  It does not  take a lot of time, but, will go long way to ensure we are implementing Sitecore to take advantage of out of the box functionality it has got, it is important to remember why Clients chose Sitecore and ensure the set up is done right to satisfy their needs, both functionally and from content authoring/Marketing perspective.

Below is one such list and I make effort to keep that updated as the team moves towards attempting complex modules.  The mantra is to build out smaller and keep updating it based on pitfalls you generally see in your team.

1.  Follow Technical Breakdown as closely as possible, if something should be done differently, please collaborate with Technical lead that had done the breakdown and mention the same, so he/she is aware
2. Assume that any or every object could be null and ensure null checks are in place on your controller or business logic code.
3. Minimize code or branching in view, in fact, we recommend to have literally no code, except for simple if statements that would check before editable/property is outputted on the view.  Everything should be available on Model or View Model that is passed and logic should reside in Controller.
4. Create and check in all sitecore items on to project that the module or feature would need.
5. Ensure Helix patterns and principles are followed and applied.  Technical breakdown should provide guidelines on the same as well.
6. Do not forget to set proper Insert Options and Standard values based on functional requirements.  This is a must for a seamless content author experience
7. Datasource and Data Template are required and is usually specified on datasource driven modules on the Technical Breakdown
8. All fields such as pickers like Multilist, droplist or Images should be having a source assigned to ensure proper funneled content is shown to content author when trying to load content and keeping media and datasources organized and secured.
9. Helptext, which are hints for the content author should be added when ever there is back end logic to decide on priority between two fields or specific scenario happens when user fills in a specific content field.  Talk to your Technical lead when in question.
10. Every thing that is stated editable should be allowed to be editable and unit tested on Experience Editor, consider adding custom experience buttons / Edit frames to edit background images and pop over text when applicable. Other options could be explored if scenario could not be addressed with such easy to configure tools.
    1. If there is a drop list or a picker on content editor, such as theme selection or pattern selection, etc., consider adding a custom experience button to ensure content author could edit the same from Experience Editor.  Refer :  https://community.sitecore.net/technical_blogs/b/maximizing_usability/posts/enhancing-the-page-editor-experience-with-custom-experience-buttons
11. Ensure your module implemented works on Experience Editor and in fact editable entities are correctly edited and saved via the platform.
12. Ensure to upload a new image for Thumbnail for ease of use by content author and to look professional and intuitive.  Look in to document uploaded on sharepoint for instructions on how to do the same.  Document Name:  Steps To Upload Thumbnail Image For Rendering.docx
13. Do error handling when needed and may be a back end service is being used to gather information on controller.  Use methods available on Sitecore.Diagnostics to ensure to push the error to logs, it would be helpful while debugging an issue on upper environments
14. If there an RTF, ensure a source is set up that pulls up capabilities listed on documentation.
15. At early stages of the implementation, I would recommend for ease of checking and testing process, the new rendering/module should have at least one set of sample content checked in and this rendering should be added to standard values of Generic Template, a new content page should be instantiated under Home node of the instance and if not dynamic data source, a specific data source should be picked to ensure when the page is accessed the module would show up on the website.
16. Use the power of Glass to load everything you need on your datasource object or TDS Class, it is easy to extend and tell Glass what type of object you want and map it with few attributes and as simple as that, you get everything you need and controller is clean. Avoid writing code when you don’t have to.