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).
