Continuando con la serie de artículos sobre buenas prácticas, vamos a ver un caso práctico de porqué nuestro código debe de ser legible y mantenible con la finalidad de ahorrarnos trabajo y, sobre todo, de ahorrarnos malentendidos sobre el funcionamiento. En este artículo, vamos a ver un caso en el que escribir código de forma incorrecta hace más difícil el desarrollo y puede ocasionar posibles bugs.
¿Qué es Clean Code?
La lectura del código es una de las actividades a la que más tiempo dedicamos, incluso para escribir nuevo código tenemos que leer lo que ya hay implementado. La diferencia entre un buen y un mal código no es el tiempo que se tarda en realizarlo, sino el pensamiento sobre el mismo. Un mal código puede dificultar las modificaciones y alarga los plazos de entrega. Muchos desarrolladores no tienen este concepto generalizado y unas veces por desconocimiento y otras por formación, no son conscientes de que su código no es del todo «limpio». Pero… ¿qué es código limpio?
Según varios autores conocidos, las características del código limpio son:
- Fácil de leer, expresivo y sencillo
- Probado mediante tests automáticos
- Hace una única cosa
- No existe duplicidad en él
- Utiliza el menor número de elementos posibles
- Realiza abstracciones de elementos similares
El código limpio no se genera la primera vez que escribimos, sino que se va mejorando y refactorizando a medida que vamos avanzando. Éste es el proceso de mejora continua que va sufriendo nuestro código desde el momento que se crea y como va evolucionando. En este caso se conoce como la regla de los Boy Scouts: “Hay que dejar el código mejor de cómo lo encontraste”.
Código que no es Clean Code: la API de SharePoint
Muchas veces ponemos ejemplos de código que hemos implementado nosotros, pero incluso en código «profesional» nos damos cuenta de que no cumple este objetivo. En teoría, el código de una API profesional debe de ser lo suficientemente descriptivo para que cualquier desarrollador con el intellisense, pueda ser capaz de llamar al método necesario. Ahora bien, vamos a repasar algunos ejemplos en los que tenemos ciertas confusión.
Caso de Estudio
Tenemos que implementar un WebPart que, dado si un usuario pertenece a un grupo o no, puede realizar unas acciones u otras. Ahora bien, el grupo se va a definir a nivel de la colección de sitio de forma que esté centralizada esta acción.
Supuesto
- Elevamos los privilegios para garantizarnos que se pueden consultar los miembros de los usuarios.
- El Objeto SPWeb es el sitio raíz.
Opción 1:
Dentro del Objeto SPWeb.SiteGroups consultamos la información de los miembros del grupo.
Opción 2:
Dentro del Objeto SPWeb.Groups consultamos la información de los miembros del grupo.
¿Cuál es la opción buena y por qué?
Si seguimos las prácticas para escribir buen código, los nombres de las funciones deben ser lo suficientemente explícitos para que cualquier persona sepa lo que hace esa función y no tenga que ir a la documentación o al propio código (en caso de que se tuviera éste).
En estos casos concretos, la opción 1 devolvería los Grupos del Sitio y en la opción 2 devolvería los Grupos del Web (que en este caso es el mismo que el del sitio). Por lo que a primera vista ambas opciones son igualmente validas, ¿no? Pues como supongo que habéis deducido, hay truco. En algunos ocasiones, la Opción 2 no funciona.
¿Por qué no funciona?
La función Groups nos devuelve los grupos que están activos en ese SPWeb. Con lo cual, si nos creamos un grupo específico para nuestro desarrollo y sólo lo utilizamos para ello, este grupo nunca existirá dentro de Groups. Aquí está claro que el nombre debería ser GroupsActive. Para saber su correcto funcionamiento, está claro que tenemos que echar un vistazo a la MSDN
Conclusión
Hay mucha gente que tiende a restarle importancia al Clean Code, hasta que se encuentra con un código que no es suyo (como en este ejemplo). Muchas veces decimos que hacerlo bien y hacerlo mal, cuesta lo mismo y es verdad. ¿Cuánto tiempo más hubiera tardado la persona que implementó el método Groups en ponerle GroupsActive?
Escribir código legible y mantenible es una opción que todo desarrollador debe de tener en mente. En primer lugar, por su capacidad profesional y, en segundo lugar, por el beneficio del propio equipo.
¡Suscríbete a nuestras RRSS!
