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:
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”.
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.
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.
Dentro del Objeto SPWeb.SiteGroups consultamos la información de los miembros del grupo.
Dentro del Objeto SPWeb.Groups consultamos la información de los miembros del grupo.
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.
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
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.
Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando, estás dando tu consentimiento para aceptar las cookies y también nuestra política de cookies (esperemos que no te empaches con tanta cookie 😊)