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)
  • Comentarios inútiles (quitarlos, código autodocumentado)
  • Comentarios permitidos (temas legales, advertencias, tareas TODO)
  • No te fíes de los comentarios… !! Sólo el código dice la verdad !!
  • No tener test que validen nuestro codigo (imperdonable)
  • Codigo inseguro – la seguridad importa (Secure code is good code)

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

Reflexiones

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.