CleanCode

Hoy en día, el mayor problema en el desarrollo y mantenimiento de aplicaciones empresariales es sin duda la complejidad del código. La legibilidad del código es el primer objetivo que debemos transmitir al equipo para la construcción de software de calidad y evitar escribir código difícil de entender y mantener.

A lo largo de mi carrera profesional he aprendido y «sufrido» que diseñar, programar, mantener y evolucionar software es una actividad muy compleja y lo más importante, es que nuestras decisiones de diseño siempre tienen que depender del contexto, me explico, como buenos profesionales debemos conocer lenguajes actuales, tecnologías, frameworks, librerías, etc. las cuales cambian y evolucionan muy rápido y muchas veces en los proyectos, no aplicamos de forma directa la solución óptima, nos guiamos por modas/tendencias/recetas, dejando la aplicación sin desarrollar el código lo más limpio posible para facilitar su entendimiento y asegurar su mantenibilidad en el futuro.

CleanCode - portada

El Clean Code nos ofrece unos principios básicos para programar día a día, crear código de calidad, fácil de mantener y testear en las aplicaciones.

Robert C. Martin, en su libro Clean Code, explica las partes más importantes a tener en cuenta a la hora de programar, que son los malos olores y como afecta a la pérdida de calidad y generación de deuda técnica en las aplicaciones que con el paso del tiempo se convierte en un gran coste empresarial en horas de mantenimiento de los proyectos.

 

Pragmatic programmer-libro

Otro libro imprescindible, es The Pragmatic Programmer, nos cuenta como lidiar con la creación y mantenimiento de código,  buenas prácticas en nuestras tareas diarias y mi apartado preferido «Don’t Live with Broken Windows – Fix bad designs, wrong decisions, and poor code when you see them».

En Coding Horror, podemos encontrar una guia de referencia de este fantástico libro donde comentan todos los aspectos resumidos y una lista de consejos a tener en cuenta para ser mejores desarrolladores:  A Pragmatic Quick Reference, hecharle un vistazo porque vale mucho la pena.

Malos olores para detectar codigo «sucio»

  • Alto acoplamiento (bajarlo)
  • Baja cohesión (subirlo)
  • Código dificil de entender y poco expresivo
  • Código duplicado (unificarlo, principio DRY)
  • Código muerto (quitarlo, estará en TFS,GIT,CVS)
  • Nombres poco significativos (usar nombres descriptivos)
  • Clases y métodos con código muy largo (dificil entender)
  • Clases demasiado grandes (no cohesionadas)
  • Funciones y métodos largos (extract method)
  • Demasiados parámetros (juntar en una clase)
  • LLamadas a metodos de subclases (Ley Demeter)
  • Divide y vencerás (refactoring/abstracción/encapsulación)
  • Instrucciones switch y condicionales complejos (if..else..elseif)
  • Usar codigos de error en nuestras clases (quitarlos, usar excepciones)
  • Gestión y tratamiento de excepciones (hacerlo correctamente)
  • Poner try…catch para ocultar fallos/errores (tema infraestructura)
  • Long Loops and Nested Loops son malos (blocking – green threading)
  • Reflection es caro (usarlo solo cuando sea necesario)
  • Comentarios inútiles (quitarlos, código autodocumentado)
  • Comentarios permitidos (temas legales, advertencias, tareas TODO)
  • Codigo inseguro – la seguridad importa (Secure code is good code)
  • Codigo inseguro – configs… muy peligroso (pass, secrets,sha1,github,etc)
  • No te fíes de los comentarios… !! Sólo el código dice la verdad !!
  • No tener test que validen nuestro código (imperdonable)
  • Otros malos olores: top-10-of-software-design-evilness

SourceMaking Reference

Un sitio web con un montón de informacion para diseñar buen software!!

¿Que son los Principios SOLID?

La respuesta corta, SOLID es un acrónimo creado por Robert C. Martin, que representa cinco principios básicos de la programación y que nos dice que si aplicamos en nuestros desarrollos tendremos un buen diseño sólido y robusto.

La respuesta detallada sobre SOLID, implica muchas cosas, tiene que ver con tener una buena/mala arquitectura de software, la calidad del código, acoplamiento, dependencias, mantenibilidad, deuda técnica, testing y otros temas que comentaré en otro post del blog.

  1. SRP: Single Responsibility Principle  / SingleResponsibilityPrinciple
  2. OCP: Open Closed Principle  /  OpenClosedPrinciple
  3. LSP: Liskov Substitution Principle  /  LiskovSubstitutionPrinciple
  4. ISP: Interface Segregation Principle  /  InterfaceSegregationPrinciple
  5. DIP: Dependency Inversion Principle  /  DependencyInversionPrinciple

Ejemplo Telerik: why-solid-matters

Coupling and Cohesion

  • A modular design is better than a monolithic design.
  • Some modular designs are better than others.
  • Good modular designs: Loose coupling and high cohesion.

Principles of package cohesion

Principles of package coupling

Fuente: http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

Inyección de Dependencias

  • Mantenibilidad: facilitar el mantenimiento del sistema
  • Testeabilidad: test unitarios de nuestras aplicaciones
  • Extensibilidad: sustitución de piezas de software
  • Bajo aclopamiento: no hacemos new dentro de las clases
  • Desarrollo en equipo: separar responsibilidades entre miembros
  • Configuración y uso de interfaces
  • Conocer grafo de dependencias o usar Framework IoC
  • Perdida de productividad en tiempo de diseño
  • Depuración de clases ya compiladas

¿Que son los Principios FIRST?

La respuesta corta, FIRST es otro acrónimo también comentado por Robert C. Martin, que tiene que ver con la forma de construir y lanzar los test unitarios y el uso de TDD a la hora de trabajar en los proyectos de software y deben cumplir estas caracteristicas:

From STUPID to SOLID Code

Otro artículo muy recomendable su lectura es este sobre STUPID vs SOLID del autor William Duran: https://williamdurand.fr/2013/07/30/from-stupid-to-solid-code

 

Buenas Prácticas en Desarrollo

Por buenas prácticas, se entiende un conjunto de acciones de programación que han rendido bien en un determinado contexto y que se espera que, en contextos similares, rindan similares resultados. Estas prácticas dependen de las épocas, de las modas y hasta de la empresa consultora o del autor que las preconiza. No es de extrañar que algunas sean incluso contradictorias entre ellas. (Wikipedia)

A mi entender, así como conocer las reglas del ajedrez no nos convierte en buenos jugadores, lo mismo sucede con los principios, patrones y buenas prácticas, no basta solo con conocerlos, hay que aplicarlos y utilizarlos con sentido común y crear buenos diseños para desarrollar aplicaciones mantenibles, extensibles y robustas.

Pirámide del Desarrollador

Con esta pirámide tenemos una visión global de todos los skills y técnicas que debemos aprender para convertirnos en un buen desarrollador.

Piramide-Developer

Principios Básicos

Principios Codificación

¿Porque los condicionales ensucian nuestro código?

  • Al usar if anidados estamos complicando la legibilidad y mantenibilidad del codigo, por lo tanto, haciendolo mas confuso.
  • Al usar condicionales estamos duplicando el nº pruebas y elevando al cuadrado la cobertura de las mismas.
  • Las herramientas de testing y cobertura nos indicarán el % de código cubierto.

Reflexiones Finales

Para finalizar, normalmente en la universidad no enseñan a programar con estos principios y buenas prácticas, pero no vale de excusa, nuestra obligación como desarrolladores profesionales es entregar código con la máxima calidad, ya que, realmente somos escritores de código, otros miembros del equipo tienen que leerlo y entenderlo de la forma más comprensible posible si tienen que mantenerlo en el futuro.