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:
Esta es una iniciativa de un grupo de miembros de la Comunidad Agile Peru para difundir el pensamiento Craftsmanship, si sabes de algún evento relacionado a la programación avísanos para publicarlo, este espacio es para ti.
viernes, 29 de junio de 2012
martes, 12 de junio de 2012
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...
sábado, 19 de mayo de 2012
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:
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)
- 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.
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
Suscribirse a:
Entradas (Atom)