Dojos y Niveles

Hola en la comunidad Agile Peru se organiza muchos dojos, de hecho se viene una semana de dojos facilitados por diferentes miembros de la comunidad,  he visto que se están armando con niveles (básico, intermedio y avanzado) (actualizacion: se han retirado los niveles) pero no se ha indicado en que consisten estos niveles, esto es un poco difícil pues los dojos son para aprender/practicar algo, y esto es muy difuso pues este algo puede ser desde un lenguaje, framework o técnica pero seria bueno tenerlo en algún lugar para saber si estoy interesado y cual me conviene mas

Sin embargo creo que principalmente nos centramos en habilidades de programación asi que quiero proponer una escala:

Mas que un nombre

Hace un par de semanas tuve un pequeño debate con el DBA del lugar donde trabajo, sobre el uso de convenciones a la hora de usar Nhibernate en un proyecto nuevo.

Cuando me pidió un ejemplo de como se llamarían las tablas y las columnas del nuevo sistema, le mostré los resultados, a los 2 mins de ver los nombres de las tablas resultantes después de crear el esquema con Nhibernate, la cara de asombro poco a poco fue tornándose en una cara de angustia, estupor y finalmente contrariedad, y a los pocos segundos dijo:

NOOOOOOOOOO!!!! Eso esta mal, las tablas y columnas no pueden nombrarse así, para eso esta el estándar!!!, ya hay un documento donde se explican los mnemotécnicos a usar.... esto esta muy mal!!!.

Primero hablamos acerca del estándar al que hacia referencia, el cual había sido utilizado en un proyecto legacy que se había construido hace casi 5 años y que lamentablemente en ese proyecto se había descuidado el tema sobre las convenciones de programación, nombres, etc...

Y que en el nuevo proyecto habíamos decidido aplicar clean code en el sentido completo de lo que ello implica.

A todo esto indico que, estaba mal porque no podía aplicarse a tablas y columnas ya que no eran programas y que los mnemotécnicos eran más que claros,

a esto le replique que leyera tal cual los nombres de las tablas del anterior sistema, para lo cual el leyó usando ya su previo conocimiento del dominio del sistema, por lo que no leyó si no interpreto los nombres, le replique que eso estaba mal y le dije que si una tabla se llama rcmcred se leía ere-ce-eme-ce-ere-e-de (exagere un poco) pero quería demostrar mi punto de vista... el soltó una risa burlona y dijo que la leyera como debería ser es decir erecemecred... le dije que no era así.... luego le mencione que el nombre podría ser "deudoresregistrocrediticio" y me dijo que muy largo yo le dije que podría ser registrocrediticio a lo que el replico, ya ves ya tiene 2 nombres posibles, en cambio con los mnemotécnicos solo tendría uno y estaría en el diccionario de datos.....

Y le dije, bueno no tiene dos nombres por el momento tiene 2 posibles nombres aun no la habíamos bautizado =D, entonces él dijo: pero entonces el nombre podría ser toda la descripción que esta en el diccionario de datos y con ello estaría bien...

le replique que eso era un extremo y que los extremos no son buenos, y además que una ventaja de nombrarlo RegistroCrediticio, ya por si mismo daría una noción de lo que es según el contexto (dominio) y no tendría que hacer un select adicional para buscar en el diccionario de datos para poder consultar la descripción de la tabla, a lo que agregue que lo mismo ocurre con los campos no tiene ningún sentido poner c_codper para guardar el código de la persona debería ser "codigopersona" o "id", además c_codper es un campo con solo números y ceros a la izquierda que tal vez después cambiemos el tipo por temas de negocio y la c_ no tenga nada que ver con el tipo de dato ya que esa es la intención de pre-fijarla c_, y le hice ver que lo mismo ocurría las variables, métodos, clases etc...

El asintió pero dijo "entonces para que estaría el diccionario de datos si la descripción ya no seria necesaria?"

Le dije pues que para información complementaria u otro fin que permitan un mejor entendimiento si no conoces muy bien el dominio del sistema.

Y me dijo NOOOO!!!! el diccionario tiene su función, además las buenas practicas (según un fabricante muy renombrado en el mundo de las BD), menciona que es una buena practica el uso de mnemotécnicos, y hay documentos que sustentan lo que digo, y bla y bla y bla... todo ello orientado a la base de datos que usamos aquí.

le comente además que si hacia una búsqueda usando el buscador de objetos o una búsqueda de texto dentro de los objetos del diccionario de datos, consultar seria sencillo porque sabría el significado de los resultados de la búsqueda con solo leerlos, sin necesidad de ir al diccionario de datos.

a lo que finalmente termino la conversación diciendo "yo no estoy de acuerdo. y quien debería definir esto es el gerente de TI, pero YO NO ESTOY DE ACUERDO... y solo aceptare eso si el gerente de TI me dice que lo haga, debe usarse el diccionario de datos".

a lo que quiero llegar es que un nombre bien escrito, auto-descriptivo, ya sea de una variable, método, clase, interfaz, archivo, tabla, campo, esquema, librería, namespace, test, etc... permite que el Código sea legible

Código legible no necesita comentarios explicativos, es entendible por si mismo.

Código legible es mas fácil de entender por ende mantener PERO es uno de los atributos que ayudan al mantenimiento hay muchos mas, de los cuales hablaremos en este blog.

Código legible parte de la documentación, complementando a los test, historias de usuario, etc.

con ello mejora:

la calidad del ambiente de trabajo, no tienes que perder horas de horas tratando de Descifrar el código, vas de frente a la vena ;-)

el código es leído y entendido por todo el equipo

incluso para el nuevo staff la transición es mucho más sencilla

por tanto mi recomendación es que piensen en lo nombres que le ponen a sus variables, clases, test, namespaces, métodos, etc...

porque los nombres son importantes, y el nombre que les den deben estar dentro del contexto de la solución que están desarrollando y su significado solo trasciende hasta esos límites

el nombre debe ser un elemento diferenciador entre elementos dentro de mismo ámbito.

no hay una regla general para esto y tampoco mi intención es dar un estándar, el equipo debe ver la forma de como ese estándar, esas convenciones emerjan.

así que piensa en un nombre ;-) no lo tomes a la ligera...

Reuniones

Hola a todos se ha formado un grupo para empezar a conversar sobre el tema, realizar ejercicios y ayudarnos en nuestro camino a la mejora profesional, especiales agradecimientos a Lennon Shimokawa quien nos facilita tener un local en La universidad UPC para poder efectuar las reuniones y publica algunas fotos de las mismas entre las principales cosas que sucedieron:

• Se tomo conciencia de que hay mucho que aprender sobre buenas practicas de desarrollo de software
• Es necesario tener voluntad de aprender lo cual es algo muy personal y que no puede aprenderse pero si desarrollar e inculcar en otros
• Se decidió empezar a hacer katas para practicar patrones de diseño de Software tomados del libro: Design Patterns de "The Gang of Four"

Charla y conversatorio sobre Software Craftsmanship con @grubhart, a set by lshimokawa on Flickr.

Y estas son fotos de la segunda reunion :)

los invitamos a participar, solo esten atentos a la lista de la comunidad agile peru en la que lanzamos los anuncios sobre las reuniones (aun no te has inscrito? que esperas solo tienes que entrar aqui: agileperu)

Hola Mundo

Hola a todos espero que entiendan el guiño del titulo del primer post ;) . este es un blog sobre Software Craftsmanship si no sabes que es esto puedes ver la definición en wikipedia o revisar la charla que publiqué en slideshare (al final del Post)

El objetivo del blog es ir recopilando información sobre las actividades del grupo craftsmanship (que ya tuvo sus 2 primeras reuniones) así como ir poniendo a disposición de quien lo desee material como katas realizados, puntos de vista, recursos sobre como mejorar la calidad del trabajo que realizamos dia a dia y asi poco a poco cumplir con el lema: "Raising the bar".

Entonces bienvenidos, tomen asiento, enciendan su equipo y a practicar.

Software Craftsmanship

View more PowerPoint from Edson Chávez