Clean Code

A lo largo de mi carrera profesional he visto y aprendido 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 se aplica de forma directa la solución óptima, guiándonos por modas o dejando la aplicación sin desarrollar el código lo más limpio posible para facilitar su entendimiento y asegurar mantenibilidad en el futuro.

El Clean Code es una práctica de programación que invita al desarrollador a seguir unos principios básicos y buenas prácticas en su día a día programando para crear código de calidad y evitar escribir código difícil de mantener y testear en las aplicaciones.

Según Robert C. Martin en su libro Clean Code, nos explica que son los malos olores y como afecta a la pérdida de calidad y generación de una deuda técnica en nuestras aplicaciones que con el paso del tiempo se convierte en un gran coste empresarial en horas de mantenimiento de los proyectos.

Malos olores

  • Alto acoplamiento (bajarlo)
  • Baja cohesión (subirlo)
  • Código duplicado (unificarlo, principio DRY)
  • Código muerto (quitarlo, estará en TFS,GIT,CVS)
  • 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)
  • Poner nombres no significativos (cambiar nombre, ver guías-reglas)
  • Instrucciones switch y condicionales complejos (if..else..elseif)
  • Usar codigos de error en nuestras clases (quitarlos, usar excepciones)
  • Usar try…catch para ocultar fallos/errores (tema infraestructura)
  • Gestión y tratamiento de excepciones (lanzar excepción s/n)
  • Comentarios inútiles (quitarlos, código autodocumentado)
  • JavaScript intrusivo, mezclado con el documento HTML en BODY
  • No te fíes de los comentarios… !! Sólo el código dice la verdad !!
  • No tener test que validen nuestro codigo (imperdonable)

SourceMaking

Resumiendo, nuestra obligación como desarrolladores profesionales es entregar código con la máxima calidad, ya que, realmente somos escritores de código, otras personas del equipo van a leerlo y tienen que entenderlo de la forma más comprensible si necesitan mantenerlo y modificarlo.

¿Que son los Principios SOLID?

La respuesta corta, SOLID es un acrónimo creado por Robert C. Martin, que representa los cinco principios básicos de la programación y que nos dice que si aplicamos en nuestros desarrollos tendremos un diseño orientado a objetos 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

Principios AOP

Principios IoC/DI

Implementar codigo entendible

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