Arquitectura, buenas prácticas y desarrollo sobre la nueva herramienta de Microsoft SharePoint 2016

La calidad si importa, analiza tu desarrollo en SharePoint

Recientemente hemos abordado diversas auditorias para solucionar los problemas que algunos clientes están teniendo en su SharePoint. Muchos afirman que SharePoint no es el sistema adecuado para nuestras aplicaciones y que va muy lento. Esta afirmación la realizan desde el desconocimiento de la plataforma y sobre todo porque no conocen las particularidades que tiene SharePoint para desarrollar. En este post vamos a intentar detallar estos motivos y el por qué es conveniente llevar a cabo un análisis de nuestros desarrollos.

Cuando abordamos un desarrollo con SharePoint, la primera premisa que tenemos es saber el contexto en el que se va a ejecutar nuestra aplicación. Hay muchas soluciones que son correctas bajo un determinado contexto, que aunque quizás no sean la mejor opción tecnológica, si lo son para el caso que estamos tratando. Un claro ejemplo de ello es el debate/post que tuvimos mi compañero Alberto y un servidor sobre cuál es el mejor método para realizar búsquedas a múltiples sitios.

Posibles problemas

Partiendo de esta premisa, es posible que periódicamente analicemos el volumen de información que tenemos almacenados dentro de SharePoint. Es algo muy normal que a la hora de abordar una aplicación tengamos una entidad que inicialmente estaba pensada para pocos elementos. Por ejemplo, nosotros tenemos una lista de clientes con los que colaboramos. Tiempo atrás pensamos que, en el caso más optimista, íbamos a tener a 100 clientes, pero lo cierto es que a lo largo de este año nuestro negocio ha ido muy bien y, en lugar de tener 100 clientes, tenemos 1.000. Entonces, si el desarrollo no se ha realizado de forma correcta y no limitamos el número de elementos… ¿Qué ocurre? Pues que la carga de la página tarda muchísimo en cargarse.
¿Cómo podemos solucionarlo?
Está claro que el problema que estamos teniendo es debido a que no hemos utilizado correctamente el SSOM (Server SharePoint Object Model) y no hemos limitado el número de elementos a mostrar. Para acceder correctamente a las listas recomiendo que repasemos este post.

Buenas prácticas a la hora de desarrollar

Como bien indica el título del post, la calidad en nuestro desarrollo es algo que no es negociable. Es algo que es OBLIGATORIO.

Ahora bien, para realizar desarrollos con calidad tenemos que saber unas «buenas prácticas». Por un lado, tenemos las propias del lenguaje de programación que estamos desarrollando. Por ejemplo, estamos desarrollando en C# y queremos hacer uso de elementos Using, var, dynamic y diversas propiedades que tiene este lenguaje que le dan una potencia enorme. Si estamos desarrollando en JavaScript, seguiremos otras pautas a la hora de desarrollar acorde con este lenguaje de programación. Finalmente, tenemos que tener en cuenta que estamos desarrollando en SharePoint y tenemos que saber cómo hacer un uso correcto de sus objetos . Por ejemplo, no elevaré los privilegios cuando quiera insertar un elemento, no dejaré conexiones del SPSite/SPWeb abiertas, no eliminaré el contexto de SharePoint, realizaré consultas CAML Query correctament, etc…

Herramientas para analizar nuestras soluciones

Para poder analizar los desarrollos tenemos dos opciones:

  1. Directamente en el código mediante Visual Studio
  2. Analizar el .wsp con herramientas específicas

1.- Directamente en el código de Visual Studio
En Visual Studio tenemos diversos plugins/herramientas que nos permiten verificar nuestro código. Estas herramientas que recomiendo las podéis encontrar en este post previo.

2.- Analizar el .wsp con herramientas específicas
Principalmente utilizamos dos herramientas: MSOCAF (desarrollada por Microsoft) y SPCAF (desarrollada por Matthias Einig MVP de SharePoint).
Haciendo uso de estas herramientas, introduciendo una solución .WSP, nos analizan los posibles problemas que tiene ese código y qué acciones realizar para solucionarlo.

Resumen

Cualquier desarrollo en SharePoint, antes de ponerlo en un entorno de desarrollo, tenemos que asegurarnos de que sea apto para ello. Un mal desarrollo puede penalizar mucho el rendimiento de nuestro SharePoint y puede provocar que nuestro entorno tenga muchos errores y que trabajar con la plataforma sea algo tedioso. Tal y como hacemos en nuestra vida cotidiana, en la que con cierto tiempo vamos al dentista, al médico, etc… con nuestro servidor favorito debemos hacer lo mismo. Debemos analizar el estado en el que se encuentra, tanto a nivel de infraestructura (tal y como aconseja el maestro Alberto), como a nivel de los desarrollos.

Recomiendo, con una frecuencia mínima de un año, realizar un análisis exhaustivo del estado de SharePoint. De esta forma ayudamos prevenir posibles problemas que tengan un imparto en nuestro sistema.

En ENCAMINA te ayudamos, te invito a leer nuestra propuesta de Análisis de Salud.

análisis-de-la-salud-banner-derecha

mm

Sobre Adrián Díaz

Adrián Díaz es Ingeniero Informático por la Universidad Politécnica de Valencia. Es MVP de Microsoft en la categoría Office Development desde 2014, MCPD de SharePoint 2010, Microsoft Active Profesional y Microsoft Comunity Contribuitor 2012. Cofundador del grupo de usuarios de SharePoint de Levante LevaPoint. Lleva desarrollando con tecnologías Microsoft más de 10 años y desde hace 3 años está centrado en el desarrollo sobre SharePoint. Actualmente es Software & Cloud Architect Lead en ENCAMINA.
Esta entrada ha sido publicada en buenas practicas y etiquetada como , . Enlace permanente .
Suscríbete a Desarrollando sobre SharePoint

Suscríbete a Desarrollando sobre SharePoint

Recibe todas las actualizaciones semanalmente de nuestro blog

You have Successfully Subscribed!

ENCAMINA, piensa en colores