Buenas prácticas de desarrollo en SharePoint

Desde Creative SharePoint nos llega una lista de buenas prácticas de desarrollo en SharePoint. Seguro al leerla, estarás de acuerdo con algunas y en desacuerdo con otras, pero lo más importante es que se trata de buena información, para analizarla, tenerla en cuenta, profundizar o preguntarnos: ¿Había yo pensado en eso? Transcribo parte del artículo, pero les recomiendo que lo lean en: http://creativesharepoint.posterous.com/sharepoint-development-standards.

Que lo disfruten:

My Current SharePoint Development Standards List
General

• All custom SharePoint work must be deployed through SharePoint solutions (.wsp files)
• We will not import or restore any backups of sites developed by third parties. This shouldn't be a problem as all custom work will be deployed through solutions and features anyway. I wanted to avoid importing hidden designer hacks, but J.D. Wade brought up a good point, we might need to import actual content, so we can't completely write this off.
• All functionality and customizations must be documented
• Site and list templates must be created through code and features (site and list definitions). STP files are not allowed as they are not updatable.

Code

• Web parts must be deployed using our custom feature receiver (we can provide source to third parties working with us).
• Custom code must be checked for memory leaks using SPDisposeCheck.
• For site definitions, use a minimal site definition with feature stapling.
• Use best practices when accessing data using the SharePoint object model. See Working with Large Lists, Common Coding Issues When Using the SharePoint Object Model, and Using Disposable Windows SharePoint Services Objects

12 Hive Deployment

• No out of the box SharePoint files in the 12 hive will be overwritten
• Images deployed must be deployed into an RGA/ProjectName folder

SharePoint Designer

• SharePoint designer updates are generally not allowed. The only exception to this rule is for creating DataForm web parts.
• DataForm web parts must be exported through the SharePoint GUI and solution packaged for deployment as a feature.
• Editing out of the box master pages is not allowed. Instead, duplicate an existing master page, make edits, then solution package the master page for feature deployment.
• No SharePoint Designer created workflows. These are not portable and cannot be packaged for solution deployment.

InfoPath

Continuar leyendo en: http://creativesharepoint.posterous.com/sharepoint-development-standards.

Artículos relacionados:

• surpoint- Middle Tier (un método alternativo para desarrollar en