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.
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.
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!!
- AntiPatterns: https://sourcemaking.com/antipatterns
- Design Patterns: https://sourcemaking.com/design_patterns
- Code Smells: https://sourcemaking.com/refactoring/smells
- Refactoring: https://sourcemaking.com/refactoring/refactorings
- UML: https://sourcemaking.com/uml
¿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.
- SRP: Single Responsibility Principle / SingleResponsibilityPrinciple
- OCP: Open Closed Principle / OpenClosedPrinciple
- LSP: Liskov Substitution Principle / LiskovSubstitutionPrinciple
- ISP: Interface Segregation Principle / InterfaceSegregationPrinciple
- 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
- (REP) The ReuseReleaseEquivalencePrinciple
- (CCP) The CommonClosurePrinciple
- (CRP) The CommonReusePrinciple
Principles of package coupling
- (ADP) The AcyclicDependenciesPrinciple
- (SDP) The StableDependenciesPrinciple
- (SAP) The StableAbstractionsPrinciple
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:
- Fast
- Isolated/Independent
- Repeteable
- Self-validating
- Thorough/TimelyFuentes: sukumar y writing your first unit-tests
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.
Principios Básicos
- DRY – Don’t Repeat Yourself
- KISS – Keep It Simple, Stupid o Keep It Short and Simple
- YAGNI – You Ain’t Gonna Need It
- GRASP – General Responsibility Assignment Software Patterns
- REFACT – Refactoring de Software
- SOLID – Acrónimo de estos 5 prinicipios
Principios Codificación
- Agrupar clases por paquetes/namespaces/grupos de clases
- Refactoring
- Legibilidad y Mantenibilidad del Código
- Los comentarios dentro del código son basura
- Usar constantes para rutas y URLs
- Usar StringBuilder en lugar de concatenar string
- Encapsulación: encapsular y encapsular siempre
- Encapsulación: Construcciones Complejas
- Excepciones Propias y Excepciones de Aplicación
- Enum alternatives in C# (enum safe)
- Proteger Base de Datos mediante procedimientos almacenados
- Top 10 of software design evilness
- Top 12 buenas prácticas en ASP.NET MVC
- Evitar código del tipo “Recetas de Cocina”
- Guard Protector: Using Guard pattern to simplify code contracts
¿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.