¿Que dos cosas le pediría a un programador?


Bueno dos cosas, entre otras muchas cosas. Pero sin duda les pediría y preguntaría:

  1. ¿Si en su carrera profesional han llegado a implantar un proyecto?. Es decir, han llegado a ponerlo en producción y liberarlo con éxito para que los usuarios los utilicen en su vida diaria.
  2. ¿Si han desarrollado algún proyecto para usuarios que lo van a utilizar porque les gusta o interesa y no por obligación?. Es decir, no un proyecto para un usuario de intranet de empresa que tienen la obligación de utilizarla si o si.

Y en ambos casos: ¿cual ha sido el resultado?. Aunque este es un aspecto un poco menos importante.

Si una persona en su vida profesional me responde afirmativamente a las dos preguntas anteriores me generara mucha más confianza como profesional que otros.

Liberar un proyecto no es una tarea fácil. El que crea que ya ha terminado un proyecto cuando los usuarios todavía no lo están utilizando de forma habitual se equivoca. El objetivo del proyecto es precisamente ponerlo en producción y que el usuario lo utilice.

Que las personas que trabajan en el proyecto sean capaces de tener esto claro no es una tarea sencilla. Y no lo digo por decir, estoy actualmente en un proyecto en el que prácticamente nadie a puesto un proyecto en producción. Y algunos de ellos son gente que ya llevan 6 años o más trabajando. Pero son personas que en sus 6 o más años de vida laboral no han hecho más que saltar de proyecto en proyecto y de empresa en empresa y nunca han terminado nada. Les falta por tanto ese “toque”, esa “mentalidad” que te permite “terminar” el proyecto. Son personas para las cuales termina el proyecto cuando se van o los cambian, no cuando lo entregan. Y esto termina suponiendo un montón de problemas.

La respuesta afirmativa a la segunda pregunta me garantiza calidad y preocupación por lo que estas haciendo. Me garantiza que has tenido que pensar en el usuario y que te lo estas intentando ganar con la aplicación: porque es usable, porque va rápida, porque esta llena de funcionalidades que te agradan, etc.

!! Que diferentes serían muchos proyectos en los que he trabajado!! para intranets de algunas empresas, si no viésemos al usuario de la aplicación como un empleado que tiene que usarla si o si. Que parece que le puedes colocar cualquier cosa. Los usuarios de aplicaciones de Internet no se andan con tonterías: si no funciona no la utilizan y ya esta. Te dejan ahí con dos palmos de narices. Los tienes que cuidar y ofrecer lo mejor de lo mejor.

En resumen, me gustaría trabajar con gente:

  • Que sepa que el objetivo del proyecto es un “producto” puesto en producción y funcionando.
  • Que debemos hacer la aplicación como si fuésemos a cobrar por ella y por tanto, cuidando y mimando al usuario.

Siempre nos estamos quejando (con razón en muchos casos) de otros elementos que interfieren en el proyecto, cuando todavía queda mucho por mejorar en nosotros mismos.

El otro día leía en twitter “Con la tecnología actual se pueden hacer las cosas mejor y mucho más rápido ” y estoy seguro y convencido de que es así.

Anuncios
¿Que dos cosas le pediría a un programador?

Algunos consejos para ser un buen programador.

Hoy solo os dejo 2 enlaces. Dos enlaces que me han encantado y que están relacionados con las aptitudes de un buen programador y con lo que debería hacer a lo largo de su vida profesional para conseguirlo.

Los 4 pilares del buen programador

http://www.contentedcoder.com/2012/08/the-four-pillars-of-good-software.html

En el primer artículo, nos explica que para ser un buen programador no podemos conformarnos simplemente con escribir código, que debemos preocuparnos por:

  • La calidad.
  • La corrección.
  • La productividad.
  • La performance.

El conjunto de estas 4 pilares determinará si se es o no un buen programador y lo más recomendable es estar en la intersección de esos 4 puntos.

Aprende a programar en 10 años

http://loro.sourceforge.net/notes/21-dias.html

En el segundo artículos, el autor Peter Norvig, se mofa un poco de los libros que dicen enseñar un lenguaje de programación en 7 o 21 días.

Según el autor, algunos investigadores (Hayes , Bloom) han mostrado que toma aproximadamente diez años desarrollar habilidades en cualquiera de una amplia variedad de áreas y por tanto en la programación.

Nos recomienda que debemos hacer durante estos diez años:

  • Interésate en la programación.
  • Habla con otros programadores.
  • Programa.
  • Si quieres, dedica cuatro o cinco años en una universidad (o más en una escuela de graduados).
  • Trabaja en proyectos con otros programadores.
  • Trabaja en proyectos después que otros programadores. Proponte entender un programa escrito por otra persona.
  • Aprende por lo menos una media docena de lenguajes de programación.
  • Involúcrate en un plan de estandarización de algún lenguaje.
  • etc.

Me parece muy acertada la parte en la que dice:  “Sé el mejor programador en algunos proyectos; sé el peor en otros. Cuando eres el mejor, tienes que poner a prueba tus habilidades para liderar un proyecto y para inspirar a otros con tu visión. Cuando eres el peor, aprendes lo que los maestros hacen, y aprendes lo que a ellos no les gusta hacer (pues te ponen a hacerlo por ellos)”.

En definitiva 2 grandes artículos que nos pueden ayudar a ser mejores programadores.

Adiós.

Algunos consejos para ser un buen programador.

Explicando la complejidad ciclomática mediante gráficos

Como una imagen vale más que mil palabras, esta es la mejor forma que he encontrado de  explicar a mis compañeros que es al complejidad ciclomática de forma rápida,concisa y sobre todo impactante.

En primer lugar, una pequeña introducción

La Complejidad Ciclomática (en inglés, Cyclomatic Complexity) es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa.

El resultado obtenido en el cálculo de la complejidad ciclomática define el número de caminos independientes dentro de un fragmento de código y determina la cota superior del número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez, (es decir, mira if, else, for, while, etc)

En segundo lugar donde la pueden visualizarla en el Sonar

En el Sonar esto se puede ver en el cuadrado denominado “Complexity“:


Donde podemos observar que tenemos 2.6 de media por método y 9.9 de media por clase (cifras ambas muy engañosas). Ya que si pulsamos sobre métodos (por ejemplo) podemos ver que hay métodos que suben hasta un valor de 61 en la complejidad ciclomática.

Explico un poco lo que significan esas cifras

Si tenemos en cuenta el siguiente ranking:

  • 1-10       Programa Simple, sin mucho riesgo.
  • 11-20     Más complejo, riesgo moderado.
  • 21-50     Complejo, Programa de alto riesgo.
  • 50           Programa no testeable, Muy alto riesgo.

Pues podemos ver que hay métodos que superan el “peor escenario imaginable”. Supongo que los números os indican poco, pero si miráis este gráfico en el que se pinta el flujo de un método con una complejidad ciclomática de 48, pues acojona un poco (ojo, insisto que es flujo de un solo método):

Y en último lugar una imagen (el incentivo definitivo) que muestra gráficamente que puede significar ese número

 

 

NOTA:

La imagen ha sido creada a partir del programa Understand una aplicación de SciTools que nos permite realizar un análisis estático del código. No es gratuita, es de pago, pero tiene una versión de pruebas de 15 días. ¿conocéis de alguna otra herramienta que permita realizar este tipo de gráficos?.

Un saludo.

Explicando la complejidad ciclomática mediante gráficos

¿Qué herramientas utilizáis para controlar la calidad de vuestro código?

En genbeta:dev han lanzado hace un día esta pregunta:

¿Qué herramientas utilizáis para controlar la calidad de vuestro código?

Esta ha sido mi respuesta. Reconozco que me he dejado llevar y al final he hablado un poco de todo. En cualquier caso esta es la respuesta, desordenada y escrita en 5 minutos, pero creo que puede ser útil.

1.-En primer lugar Eclipse bien configurado.

Como por ejemplo nos indica aquí Sanjeev Kumar.

https://sites.google.com/a/javagyan.com/javagyan/useful-tips/usingeclipseeffectively

Esto lo podemos acompañar del algún plugin que nos mire las métricas mientras desarrollamos tipo: CodePro AnalytiX

https://developers.google.com/java-dev-tools/download-codepro

Y terminaría la configuración del eclipse con un conjunto de templates que me faciliten la escritura de cierto tipo de estructuras habituales:

http://eclipse.dzone.com/news/effective-eclipse-custom-templ

2.-Un buen entorno de integración e inspección continua con Jenkins y Sonar.

http://jenkins-ci.org/
http://www.sonarsource.org/

https://jbravomontero.wordpress.com/2012/02/18/ecosistemas-de-desarrollo-de-software-lineas-de-automatizacion/

Y el Sonar enriquecido con los siguientes plugins:

  • Timeline Plugin
  • Useless Code Plugin
  • SIG Maintainability Model Plugin
  • Quality Index Plugin
  • Technical Debt Plugin

http://onlysoftware.wordpress.com/2012/01/01/51-sonar-plugins-you-must-not-miss-2012-version/

Aunque para gestionar la deuda técnica también este estupendo plugin COMERCIAL 😦 que ayuda con la implementación de SQALE)

http://www.sonarsource.com/products/plugins/governance/sqale/

3.- Fomentar de “buen rollo” (no se puede ir diciendo este código es una mierda) entre los miembros del equipo las buenas prácticas.

Recomendando las lecturas de ciertos libros imprescindibles.

Y reuniendonos de vez en cuando para analizar ciertas partes del código en equipo.
Reflejar esta información y las conclusiones en un Wiki.

Fomentar cuando sea necesario:

  • La programación por pares.
  • Y siempre, siempre la revisión por pares. No dar por bueno un código hasta que otra persona no lo ha verificado en su máquina.

4.- Un buen conjunto de test que nos quite el miedo a la refactorización cuando sea necesario.

Técnicas TDD, etc.

5.- Y dejar claro cosas como:

  • Las prisas no justifican un mal código.
  • Poco a poco, la deuda técnica se acumula en las zonas que ya estaban llenos de deuda.
  • La programación puede ser divertida, también lo puede ser la criptografía, sin embargo es recomendable no combinarla.
  • “¡No me importa si funciona en tu máquina! ¡No estamos vendiendo tu máquina!”.
  • Codifica siempre como si la persona que finalmente mantendrá tu código fuera un psicópata violento que sabe dónde vives (Martin Golding).
  • etc

Y muchas cosas más…………….

Evidentemente he sido incapaz en los proyectos que he estado de implementar todas estas técnicas o teorías.. pero creo que el concepto esta claro y se podría resumir en estos puntos:

  • Formación continua entre los miembros del equipo.
  • Fomentar la premisa de buscar la excelencia en el código trabajando en equipo.
  • No esconder la información y fomentar el compartirla.
  • Fomentar un buen entorno de trabajo: Gamification (http://vimeo.com/32435331)
  • Y automatizar la generación e inspección del código.

Un saludo.

¿Qué herramientas utilizáis para controlar la calidad de vuestro código?

Resumen semanal de temas de Java

Resumen de algunos de los enlaces relacionados con Java y desarrollo Web que he ido recopilando estos días.

Hay un poco de todo, pero el que me ha encantado especialmente la introducción a las BBDD NoSQL que han realizado desde la Web de la Pastilla Roja.

Y también destacaría el de Clincker un ecosistema de software de la empresa Klicap, una empresa andaluza.

Dicho ecosistema está formado por el sistema de control de versiones Subversion, aunque permite conectar con otros externos como por ejemplo Git. Integración continua con Jenkins, gestión de proyectos con Trac o Redmine, control de calidad de nuestro código y estadísticas con Sonar, etc. Todo esto integrado con un sistema de autenticación unificada para facilitar el trabajo de gestión de usuarios y accesos.

Aquí os dejo los enlaces.

Más enlaces en https://twitter.com/#!/jbravo.

Resumen semanal de temas de Java

Ecosistemas de desarrollo de software: lineas de automatización.

Todo este tema de los Ecosistemas de Software y la Integración Continua me encantan y me fascinan.

Se por experiencia que la mayor parte de los problemas y retrasos que se producen en los proyectos actuales es por no poner cuidado y el suficiente cariño en estos temas. No se les da la importancia adecuada y luego pasa lo que pasa.

  • Se puede llegar a estar hasta varios días sin poder realizar el build del proyecto.
  • Los errores y problemas se detectan demasiado tarde, lo que multiplica exponencialmente el coste de su solución.
  • Las modificaciones y correcciones no producen más que nuevos errores que, como indico en el punto anterior, se detectan tarde.
  • Los programadores tardan horas en desarrollar sus tareas por trabajar en un entorno poco optimizado.
  • Los programadores se desmotivan, se van del proyecto, con la perdida de conocimiento que ello implica en algunos casos.
  • Se pierde una cantidad enorme de horas en procesos manuales facilemente automatizables.
  • Se produce un “proceso de involución en el proyecto” en el que parece que este empeora en lugar de mejorar. Digo “parece” porque realmente no solemos tener herramientas fiables y “sinceras” que nos proporcionen la situación del proyecto. He puesto la palabra “sincera” a propósito, porque en la mayor parte de las ocasiones, quien proporciona esta información es una persona que miente descaradamente.
  • El proyecto se llenan de auditores y “tecnocratas” que con sus Word, Excel y Projects intentan solucionarlo. Y entonces se pieder el norte, ya no se sabe si el objetivo es el proyecto, o todos los informes que debes pasar a estas personas… que cuestan un montón de horas y dinero.
  • Etc, etc, etc…

Y si,  estoy convencido que muchos de estos problemas se podrían evitar si se decidises invertir tiempo en estos temas:

Ecosistema de software

 Un ecosistema de desarrollo software es un espacio de trabajo en el que conviven una serie de herramientas que acompañadas de unas buenas prácticas permiten a un equipo de desarrollo modelar una metodología de trabajo.

Integración continua

La integración continua es una práctica en el desarrollo de software que consiste en poner en común todos los cambios que afecten al resultado final de nuestro proyecto de una forma frecuente con el objetivo de ver la evolución de sus efectos.

Automatización

Y en la automatización  de estas 5 líneas que se suelen recomendar para conseguir un nivel óptimo de madurez en el desarrollo de software:

  • Build (compilación, empaquetado y distribuibles)
  • Automatic Documentation Generation
  • Testing
  • Continuous Inspection
  • Continuous Deployment

De todo esto es de lo que nos habla Manuel Jesús Recena Soto en esta estupenda presentación que realizo el pasado 14 de Febrero como ponente invitado al Máster de Ingeniería y Tecnologías Informáticas que se imparte en la Universidad de Sevilla.

Ecosistemas de desarrollo de software: lineas de automatización.