Solucionar el problema y buen diseño

Imagen de http://www.nydailynews.com

 

Cuando tenemos que añadir una nueva funcionalidad en nuestra aplicación tenemos que pensar desde el principio en como vamos añadirla y en el diseño que vamos a utilizar para implementarlo. Con diseño quiero decir los nuevos objetos de tipo servicio que vamos a utilizar, los nuevos objetos de dominio, como vamos a conectar todo esto con el código actual y un largo etcétera.

Normalmente tenemos que pensar en el diseño desde el principio porque posteriormente nos va a resultar trabajo el hacerlo después. Por ejemplo, si nos damos cuenta al final que un patrón encaja perfectamente con la solución que hemos implementado tendremos que testear que la nueva funcionalidad sigue funcionando de la manera adecuada. Y si hay algún error tendremos que depurar el código para ver donde está el error. Ocasionando una gran pérdida de tiempo.

Si estamos utilizando lenguajes estáticos como Java los IDE como IntelliJ o Eclipse nos permiten hacer cambios de diseño de forma automática (como renombrado de clases) lo que hace que el cambio no provoque casi nunca que el código no funcione como deseemos. Pero posiblemente queramos asegurarnos que el cambio no ha provocado un problema, lo que hace que tengamos que testear la aplicación de forma manual.

En resumen, cuando estamos empezando a codificar una nueva funcionalidad tenemos que pensar en la solución y en un diseño porque los cambios en el diseño posteriormente son costosos.

 

Cuando empecé a practicar TDD lo hice porque estaba cansado de que cada vez que arreglaba un problema había añadido dos más o que en un futuro apareciera de nuevo el mismo problema.

Pero cuanto más he ido practicando TDD una de las ventajas que más me gustan es que puedo enfocarme en una sola cosa a la vez porque tengo fases en las que me enfoco solo en diseñar y hay fases en las que me enfoco solo en solucionar el problema / añadir la nueva funcionalidad.

Las fases de TDD son tres:

  • escribir un test que falle
  • añadir código para que el test pase
  • refactorizar

En la primera y segunda fase nos dedicamos principalmente a solucionar el problema porque cada test que añadimos es un paso adelante hacia la solución y porque el código que añadimos es el mínimo para que pase el test. No nos tenemos que preocupar en el diseño de nuestro aplicación. Hay una excepción que es cuando escribimos el primer test ya que en el primer test decidimos el nombre de la clase, su método y los parámetros de entrada y salida.

En la tercera fase hacemos pequeños cambios en el código que hacen que el diseño general vaya mejorando y evolucionando en el tiempo.

Así que tenemos una parte en la que nos enfocamos en solucionar el problema y otra en la que nos enfocamos en el diseño. Enfocándonos en una cosa a la vez. Las técnicas de productividad que conozco como pomodoro o GTD se basan en hacer una cosa a la vez para mejorar la productividad. Así que tiene sentido el hacer diseño o solución del problema pero no las dos a la vez.

Además, si vemos que después de terminar tenemos dudas del diseño el hacer cambios en el código nos va a resultar más seguro y fácil porque tenemos un conjunto de tests que nos van a dar seguridad que no estamos rompiendo nada.

 

Resumiendo, que podamos preocuparnos solo por solucionar el problema entre manos o por el diseño pero no los dos a la vez es una de las grandes ventajas de TDD. Además, debido a que tenemos un buen número de test unitarios podemos hacer cambios posteriores en el código con seguridad.

 

Código como parte de entrevistas técnicas

Imagen de http://theodysseyonline.com/suny-new-paltz/interviews-the-bane-of-everyones-existence/249182

En los últimos meses he hecho unas cuantas entrevista en diferentes empresas españolas o que tienen sede en España y comparándolas con las que he hecho en Holanda lo que más me ha llamado la atención es que en ninguna española me han pedido código. Me llama la atención porque es algo que frecuentemente me han pedido en Holanda.

Pensando sobre esto me pregunto si puedes decir que un programador es bueno sin haber visto una línea de código que ha escrito.

Pongamos como ejemplo las entrevistas que he hecho para una empresa en España. Hice tres, una técnica, otra con mi posible futuro jefe y en la última con alguien de recursos humanos.

En la entrevista técnica respondí a muchas preguntas y en la parte final tuve que resolver problemas utilizando Java. En esta entrevista pudieron ver mis capacidades para resolver problemas y mis conocimientos de forma general sobre la informática.

En la segunda entrevista estuve hablando en ingles con mi posible jefe por teléfono. Fue una conversación sobre temas poco relacionados sobre mi trabajo, excepto por las preguntas que hice sobre la empresa. En esta entrevista pudieron comprobar cómo me manejo con el inglés y seguramente algo sobre mi carácter y forma de ser.

En la ultima entrevista hablé con alguien de recursos humanos sobre las cosas que le interesan a la gente de recursos humanos. Me imagino que van dirigidas a intentar conocer cuáles mis habilidades no técnicas, lo que en inglés se llama soft skills.
Teniendo en cuenta las tres entrevistas esta empresa sabe de mí:

  • Mi capacidad de resolver problemas
  • Mis conocimientos sobre informática
  • Como me comunico en español y en inglés
  • Mi forma de ser
  • Mis habilidades no técnicas

Con esta información, ¿pueden saber si soy un buen programador? En mi opinión, no. Paso una parte importante de mi tiempo escribiendo código por lo que sí no ven nada de lo que he escrito es imposible que sepan que soy un buen programador.

Y si no saben si yo soy un buen o mal programador es posible que halla pasado lo mismo con los que serían mis futuros compañeros. Eso es muy peligroso porque significaría que la gente con la que estaré rodeado no son buenos y que por lo tanto podré aprender poco de ellos. Es un problema ya que aprender es muy importante para un profesional y más para un informático.

En conclusión, las empresas que no preguntan por código o no hacen pruebas de código no pueden garantizar que sus empleados sean buenos programadores. Personalmente, no me fío de este tipo de empresas porque pueden tener gente con la que podría trabajar y que me no aporten nada a mi aprendizaje.

Si eres indispensable estas haciendo mal tu trabajo

Imagen de http://www.newyork.com/

Te quieres ir de vacaciones tres semanas y se lo comentas a tu jefe. Te dice que ahora imposible porque el proyecto en el que estás trabajando eres el único que puede hacer una parte que es crítica. Al escucharle te sientes decepcionado al perderte tus vacaciones pero a la vez orgulloso porque eres una persona importante en tu empresa y porque eres imprescindible, ya que sin ti tu empresa no funciona.
Si este es tu caso no deberías sentirte orgulloso porque no estás haciendo bien tu trabajo.

Hay muchas razones por la que eres imprescindible pero seguramente que lo que está sucediendo es que eres la única persona en tu empresa que tiene el conocimiento de cómo realizar esa tarea.
Hay muchas razones por lo que esto puede suceder. Algunas son:

  • La tarea es de vital importancia y no confías en nadie para hacerla.
  • Tú eres la única persona con los suficientes conocimientos sobre el tema para entender el que hacer si surgen problemas.
  • Tus compañeros no son lo suficiente buenos o profesionales para hacer (o eso es lo que tú piensas).
  • No has tenido tiempo en compartir lo que sabes porque ha surgido algo urgente.
  • Has pensado que no era importante el compartirlo.
  • Tu jefe te ha dicho que es una perdida de tiempo.
  • En un caso extremo de egoísmo, has decido el no compartirlo para convertirte en imprescindible y que no te puedan echar.

En cualquiera que sea tu caso no estás pensando en tus compañeros, ni en tu empresa y ni siquiera en ti.

De primeras te has quedado sin vacaciones, así que la playa y los mojitos tendrán que esperar. Además te has quedado sin aprender, porque no se tu pero cada vez que comparto información con mis compañeros siempre aprendo algo nuevo de ellos. Puede que aprenda algo pequeño pero siempre aprendo, y si eres informático como yo el aprender debería ser algo muy importante porque a los pocos años te quedas desfasado.
Si no eres informático el aprender también debería ser importante porque así te podrá diferenciar de tus compañeros y tener más posibilidades de destacar.

Desde el punto de vista de tus compañeros, toda la información debe estar compartida al menos por dos miembros de tu equipo. Así sí uno de ellos está enfermo, está de vacaciones o deja la empresa siempre habrá otra persona con esa información.
Por ejemplo, imagínate que has estado enfermo y debido a ello tu equipo ha estado casi parado. Lo que ha provocado que el proyecto no se ha terminado a tiempo y tu empresa ha perdido tiempo y dinero. Y todo ello por tu culpa, por no hacer bien tu trabajo y no compartir lo que sabes con tus compañeros.

Si no te he convencido y crees que eres intocable porque eres el único con esos conocimientos, recuerda que el mundo de la informática todo cambia muy rápidamente y que en 2, 5 o 10 años ese conocimiento no valdrá nada, tus jefes querrán despedirte, ninguna empresa querrá contratarte y lo vas a pasar mal. El que avisa no es traidor.