Olas Septiembre 2012 / Sopelana

Hacía años que no dedicaba algo de tiempo al bodyboard, por suerte, he tenido unos días libres y me ha cuadrado algún bañito... Divertido!!!

Resumen Clean Coders capitulo 6: TDD Parte 1

Continuamos con las acciones de mejora / compartiendo videos cleancoders. En esta ocasión toca el resumen del Capitulo 6 Parte 1

Clean Code, Episode 6 - TDD - Part 1

• Reglas TDD
• No escribir código de produccion excepto para hacer pasar un test que esta fallando
• Escribir solo lo suficiente de un test como para demostrar el fallo
• Escribir solo lo suficiente del código de produccion como para pasar el test
• Pasos TDD
• Red
• Green
• Refactor
• Miedo y Descomposición del código (Code Rot)
• El código y el diseño de un sistema suele irse deteriorando si no lo limpiamos de forma continua.
• Esto hace que el sistema sea rigido, fragil y dificil de cambiar y que las estimaciones cada vez sea más imprecisas y dificiles de hacer.
• No lo limpiamos, pq tenemos miedo (de romperlo)
• Un esfuerzo de limpieza que no sea constante no tiene sentido (normalmente cuesta mucho más y si no tenemos como validar que todo sigue funcionando, suele terminar en desastre).
• Eliminando el miedo a cambiar el código
• Gran cobertura de tests
• Que se ejecutan en muy poco tiempo
• Que se ejecutan con solo pulsar un boton o escribir un comando
• Con una buena cobertura de tests, se puede llegar a un estado en el que no se tiene miedo a que si pasan los tests, simplemente se libera la versión.
• Ventajas de disponer de una buena cobertura de tests
• No hay miedo para cambiar el código
• No hay miedo a limpiar el código
• No hay miedo a liberar una versión
• Número de bugs muy bajo

• Usando TDD en su experiencia
• El proyecto se desarrolla más rápido
• Nos ahorran tiempo
• Se desarrolla con mucha mas fiabilidad
• Muchos menos errores
• y se dedica menos tiempo a depurar
• Y la estrcutura resultante es mejor

• Las tres reglas del desarrollo TDD
• Es una disciplina y tiene una serie de reglas
• Las tres reglas
• No se puede escribir código de producción excepto para pasar un test que está fallando
• Escribe solo lo suficiente de un test para demostrar el fallo (no compilar es un fallo)
• Escribe solo lo suficiente del código en producción como para pasar el test fallando
• El ciclo debe ser de unos pocos segundos... algo de test, algo de código, algo de test, algo de código, …
• Con TDD, siguiendo estas reglas se obtiene:
• Tiempo de depuración reducido por un factor de 10
• Documentación (actualizada y funcional) con ejemplos
• El código está mucho más desacoplado dado que tiene que ser testeable, es decir un sistema mucho más flexible
• No tenemos miedo a cambiar el código
• No tenemos miedo a limpiar el código
• Es decir, el TDD, evita que el código se vaya corrompiendo

Resumen Clean Coders capitulo 5: Estructura (Form)

Una vez más, siguiendo con la acciones de mejora / compartiendo videos cleancoders, continuamos con los resumenes de los capítulos de Clean Coders
Hoy toca el Capitulo 5

Cap 5 - Estructura / Form

Este capitulo se centra en todo lo que tiene que ver con la estructuración que realizamos del código de nuestras aplicaciones, comenzando con el formateo del propio código fuente y terminando por algunos consejos sobre cómo definir los límites de los diversos componentes y capas de la aplicación, comenzando de esta forma con algunos temas de arquitectura.

Comentarios en código

• Se deben tener pocos comentarios en código
• Cada vez que escribimos un comentario es que hemos fallado en en expresar con nuestro código, luego tenemos que trabajar muy fuerte para que eso sólo sea necesario en raras ocasiones (ejemplo una expresión regular complicada, …)
• Se deben escribir lo más cerca posible del código al que hacen referencia. 
• Nunca comentarios superfluos que no añadan nada a lo que ya dice el código. 
• Los comentarios nunca deben ser obligatorios 
• Nunca comentarios sin código, ni comentarios tipo banner, ni TODOs, ni FIXMEs (somos profesionales y si no está terminado, seguimos trabajando)
• El código comentado se elimina (sin mirarlo).
• Comentarios legales: 
• Copyright
• Documentación de API publico (con herramientas automaticas) aunque es preferible los APIs que no requieren ni siquiera esa documentación. 

Formateo de código

• Guía de estilo: 
• No existe como documento 
• Todo equipo tiene una 
• El código del equipo es el ejemplo de la guia de estilo
• El equipo debe ser consistente y compartir ese estilo (si usa un IDE, debe compartir la configuración para que el estilo sea coherente). 
• Importante tener una convención para el uso de lineas de separación, el recomienda una linea para separar cada método, cada grupo de variables, etc. Hay que ser consistentes en su uso. Las lineas en blanco son un elemento más de formateo.
• Logitud de linea. Nunca scrolls horizontales, entre 40 y 80 caracteres... en algún caso se podría ir a 120 caracteres, pero nunca más. 
• El tamaño de fichero medio, puede ser por debajo de 100 lineas, y nunca superar a las 500 lineas. 
• Para formateo de Java el usa/recomienda: 
• Estilo K&R 
• Indentación por espacios 2 espacios de indentación 

Clases vs Estructuras de Datos 

Las clases nos protegen de nuevos tipos
Las Estructuras de Datos nos protegen de nuevas funciones

Clases

• Tell don’t ask (con métodos con alta cohesión con respecto a las variables de la clase)
• Evitando usar getter y setters, si en algún caso es necesario usar un getter es importante ocultar los datos, dando el interfaz más abstracto posible (getPercentFuelRemaining no getGallonsOfGas...)
• Protegen de nuevos tipos

Estructuras de Datos

• Sacos de datos con métodos con baja cohesión
• No se ponen reglas de negocio en este tipo de estructuras
• Se pueden manipular con switchs si es necesario
• Protegen de nuevas funciones, pero no de nuevos tipos

Límites (Boundaries) 

Los limites dentro de la aplicación separan las diversas partes, y siempre tienen las siguientes caracteristicas:

• Una parte tiene una definición abstracta
• Otra parte es concreta e implementa la definición abstracta de la otra parte
• Las dependencias de fuentes van parte concreta ---> parte abstracta
• No existen dependencias de fuentes en el sentido inverso

Los Objetos de dominio y las tablas de BD no son lo mismo, en realidad, ni están fuertemente relacionadas.
Los Objetos de dominio deben estar separados de las tablas de BD mediante una capa de abstracción que debe depender de las abstraciones de la aplicación (la parte con los objetos de dominio) y de las tablas de BD. Los objetos de dominio (y el resto de la aplicación) nunca deben depender de esta capa (y por supuesto, menos de las tablas que están por debajo).

Instalación de stack python independiente...

Tal como comente en el post sobre uso de paquetes deb de python no oficiales en la mayor parte de los casos, para el desarrollo de aplicaciones de servidor, lo normal es disponer de una stack python independiente del de sistema, por ello, lo normal es descargar y compilar python y utilidades básicas para gestionar paquetes y entornos virtuales.

En este ejemplo, vamos a instalar la última versión de Python 2.7 en el directorio /opt/py2.7

Python 2.7.3 for old gnu/linux systems (test debian/ubuntu)

Una vez que hemos realizado la instalación y verificado que el interprete python funciona correctamente, podemos pasar a instalar las setuptools, pip y el virtualenv.

setuptools, pip and virtualenv installation

En este punto ya disponemos del interprete de python y de las herramientas mínimas para poder crear entornos python, instalar paquetes, etc...
Este proceso permite usar un stack python moderno en servidores que dispongan de una versión obsoleta de sistema operativo.
Aun en el caso de que nuestro servidor disponga de una versión moderna de python, es bastante conveniente disponer de nuestra propia versión controlada del interprete y de las herramientas separada de la que viene con el sistema operativo...

Paquetes Python no oficiales para Ubuntu

En cada versión de ubuntu suele existir un par de versiones de Python soportadas de forma oficial, normalmente una de la rama 2.x y otra de la rama 3.x. En algunas ocasiones puede ser conveniente disponer de paquetes para otras versiones de Python para poder hacer pruebas de aplicaciones, depurar paquetes deb o para poder generar paquetes que puedan ser usados en varias distribuciones de forma simultanea. Para estos casos nos puede venir muy bien el respositorio de launchopad https://launchpad.net/~fkrull/+archive/deadsnakes Este repositorio contiene gran cantidad de paquetes de Python con distintas versiones capaces de convivir con los paquetes de Python oficialmente soportados en esa versión de ubuntu.... Para poder acceder a esos paquetes, lo primero es añadir ese repositorio a nuestros sources, por ejemplo ejecutando:

sudo add-apt-repository ppa:fkrull/deadsnakes

Una vez hecho esto, podemos por ejemplo instalarnos un Python 2.5 en una Ubuntu lucid 10.04, con los siguientes comandos:

sudo apt-get update
sudo apt-get install python2.5

Este repositorio contiene paquetes Python desde la versión 2.4 hasta la 3.2 para distribuciones ubuntu desde Lucid 10.04 hasta precise 12.04 Recomiendo el uso de este repositorio para el caso de que tengamos que trabajar con los paquetes Python oficiales por algún motivo, o si estamos trabajando con paquetes deb de programas hechos con Python y necesitemos probarlos en varias distribuciones o hacer las primeras pruebas de cómo funcionarían con otras distribuciones o cuando queremos hacer un backport de un paquete que nos de problemas por la versión de python. Por supuesto, si tenemos una aplicación de servidor, lo más normal es usar nuestro propio stack para el deploy usando virtualenv y no usar ninguna de las versiones de python y de paquetes de python del sistema.

Resumen Clean Coders capitulo 4: Estructura Funciones (Conclusiones)

Siguiendo con la acciones de mejora / compartiendo videos cleancoders, continuamos con los resumenes de los capítulos de Clean Coders.
En este caso, nos toca el Capitulo 4. Como este capitulo es bastante denso es posible que termine haciendo varios posts relacionados, pero de momento, en este post me voy a centrar en las conclusiones más importantes del capitulo.

Cap 4 - Estructura Funciones (Conclusiones)

• Los prototipos de funciones deben ser pequeños, pocos argumentos (<=3), no pasar booleans, ni usar argumentos que puedan ser null, no argumentos de salida
• Las funciones se organizan siguiendo la regla de step down, lo publico primero, lo privado después y siempre intentando que las funciones a las que llama cada función estén debajo de la definición de esta primera función y descendiendo cada vez en abstracción.
• Switch va en contra del paradigma OO e interfiere en el despliegue independiente de componentes (y por tanto en el desarrollo independiente) .
• Debemos remplazar los switchs por polimorfismo o por lo menos mover los switchs a sitios donde no generen ese problema de dependencias (por ejemplo a una factoria o al main).
• El Temporal coupling en muchos casos se puede limitar o eliminar usando el patrón de pasar un bloque.
• Conviene separar las funciones de query (consulta) de las de comando (modificación) (CQS)
• Tell don’t not ask
• No hacer cadenas de queries, evitar que una sola linea tenga gran conocimiento de la estructura de la aplicación o de gran cantidad de objetos. Recordando la Ley de Demeter... No se habla con extraños.
• Limitar el uso o eliminar de salidas de bucle desde dentro (break). Hacen menos entendible el código.
• Pensar en el control de errores antes que en el código normal
• Usar excepciones para el control de errores. (no devolver error codes)
• Las excepciones deben ser de la clase o modulo que las lanzas
• No check exceptions.
• funciones o gestionan errores o hacen cosas, no las dos cosas.