Definición de mantenimiento

Antes de avanzar con los distintos tipos de mantenimiento, es buena idea unificar criterios y asegurarnos de que estamos de acuerdo en la definición.

El mantenimiento es la acción de modificar la versión en producción software con el fin de corregir errores, subsanar problemas o realizar cambios enfocados en conservar la capacidad de prestar el servicio para el cual fue diseñado.

Tipos de mantenimiento

Y ahora que tenemos claro qué es el mantenimiento del software, repasemos qué tipos hay.

Mantenimiento preventivo

Si visualizamos el mantenimiento desde un prisma general y no solo desde el punto de vista del desarrollo de software, la mayoría de nosotros pensaremos en un conjunto de acciones proactivas enfocadas a evitar el deterioro de la cosa mantenida.

Si hablamos de software es exactamente igual, el mantenimiento preventivo es la acción de modificar el software proactivamente con el objetivo de evitar su deterioro o de mejorarlo sin alterar su funcionamiento.

Podemos realizar este tipo de mantenimiento por varios fines como corregir olores en el código, mejorar la comprensión, optimizar el funcionamiento, optimizar el consumo de recursos, etc

Llegados a este punto quizás te estés preguntando cuál es la diferencia entre el mantenimiento preventivo y la refactorización, pues a mi modo de ver ninguna, son la misma cosa. Así que te invito a leer el artículo Refactorización de código para ampliar conocimientos.

Mantenimiento correctivo

El mantenimiento correctivo se sitúa justo en el lado opuesto del mantenimiento preventivo: si en el mantenimiento preventivo actuamos de forma proactiva para evitar que se produzca el error, en el mantenimiento correctivo lo hacemos de forma reactiva y reaccionamos a los o errores que aparecen.

Los errores son inevitables y por más que intentemos desarrollar software libres de bugs, tarde o temprano y en mayor o menor medida éstos van a aparecer. Por lo tanto, para minimizar el tiempo que invertimos gastamos corrigiendo errores y sufriendo los efecto de sus consecuencias debemos enfocar nuestros esfuerzos en tres tareas:

• Disponer de un proceso de desarrollo adecuado con el fin de minimizar el número de bugs desde el primer momento. Puedes echarle un vistazo a la entrada entorno de desarrollo.
• Realizar mantenimiento preventivo (ó refactorización).
• Disponer de herramientas adecuadas para la notificación, clasificación y seguimiento de los errores.

Mantenimiento adaptativo

El mantenimiento adaptativo consiste en modificar el software, sin alterar su funcionamiento, con el objetivo de dar respuesta a cambios en el entorno de la aplicación. El objetivo es que estos cambios no afecten a la capacidad del programa de prestar el servicio.

Algunos ejemplos de este tipo de mantenimiento pueden ser:

• Modificar el software para adaptarse a cambios en una API de terceros.
• Adaptar un software para soportar una nueva versión del lenguaje de programación.
• Actualizar la versión de una librería o de un framework.
• Soportar cambios en el sistema operativo o en el hardware.

Mantenimiento perfectivo

En la literatura que he consultado identifican el mantenimiento perfectivo como un tipo de mantenimiento con un doble objetivo: por un lado la incorporación de nuevas funcionalidades o la modificación de las existentes, y por otro las adaptaciones necesarias para asegurar el rendimiento cuando existe un incremento del volumen considerable.

Mi opinión es que teniendo en cuenta el auge de los modelos de desarrollo ágiles y su filosofía de entrega de valor rápida basada en ciclos de desarrollo cortos, el mantenimiento perfectivo queda absorvido por la propia fase de desarrollo.

Y en cuanto a las adaptaciones necesarias para asegurar el rendimiento por aumento de volumen, creo que pueden ser perfectamente incluidas como mantenimiento preventivo, si se atajan a tiempo, o en caso contrario como mantenimiento correctivo.

Dónde comienza el mantenimiento

La versión en producción de un software es el producto de un proceso complejo formado por varias etapas conocido cómo ciclo de vida del software. Por lo tanto, la calidad del software final está altamente condicionada por la calidad individual de cada una de las etapas.

Por lo tanto, con el fin de minimizar el esfuerzo que hacemos en mantener el software podemos dar por válida una pequeña mentira: el mantenimiento del software comienza en el mismo momento en el que comienza el análisis de viabilidad del software. Es decir, invertir el tiempo necesario y hacer las cosas bien en cada una de las etapas nos garantiza, entre otras muchas ventajas, gastar menos tiempo en el mantenimiento del software .

Mantenimiento, evolución y metodologías ágiles

Como hemos visto con el mantenimiento perfectivo, las metodologías ágiles hacen que los conceptos de mantenimiento y evolución, en algunos casos, estén separados por una delgada línea gris que invita a hacer interpretaciones subjetivas de qué es qué. Éste es un tema sobre el que podríamos escribir largo y tendido, y sobre el que en esta ocasión no vamos a entrar pero si creí necesario mencionar.

Créditos, referencias y artículos relacionados

• Imagen de portada por Steve Buissinne en Pixabay
• Guía del buen programador
• Deuda tecnológica o deuda técnica
• Refactorización de código
• Cohesión y acoplamiento

A mi modo de ver, estos tres principios pueden ser tratados como tres magníficos consejos para compartir con los desarrolladores más noveles, e incluso a veces con algunos mucho más experimentados.

KISS

KISS es un principio de diseño muy popular tanto en el desarrollo de software como en otros muchos ámbitos. Es el acrónimo de «Keep It Simple, Stupid», y es una forma coloquial de decir que las cosas sencillas funcionan mejor.

Es uno de los mejores consejos se le puede dar a cualquier persona que diseñe o cree algo, ya sea relacionado con el desarrollo del software o no: hazlo sencillo, evita complicaciones innecesarias.

Y ya centrándonos en el desarrollo de software, evitar aumentar el nivel de complejidad cuando no es estrictamente necesario trae consigo múltiples ventajas, entre las que destacar la mejora de la comprensión y el mantenimiento, sin olvidar la sensación de satisfacción de haber escrito un código elegante.

No seguir este principio, en cambio, propiciará tener una estructura y un código engorroso y con olores. Si eres lector habitual de este blog, recordarás que hace varios meses escribíamos sobre el código limpio en el artículo ¿A qué huele el código fuente?, dónde mencionábamos la complejidad innecesaria como un motivo de olor.

A modo anecdótico añadir que KISS es un principio que no proviene del desarrollo de software, su origen se atribuye al ingeniero aeroespacial americano Kelly Jonhson, quien contribuyó al desarrollo de varias aeronaves para el ejército de su país.

DRY

DRY hace énfasis en la importancia de evitar la duplicidad en el código fuente, siendo el acrónimo de «Don’t repeat yourself» y estando sustentado por la afirmación de que cada pedazo de código debe tener una representación única, inequívoca y autoritaria en el sistema.

Los padres de DRY son Andy Hunt y Dave Thomas, quienes publicaron este principio en el libro The Pragmatic Programmer, en 1999, y del que en el momento de escribir estas líneas han publicado una edición conmemorativa del veinte aniversario.

Es un principio que está estrechamente ligado con la calidad del código y que, al igual que sucede con KISS, también mencionamos en el artículo ¿A qué huele el código fuente?.

Y cuando no cumplimos con el principio DRY, se suele decir que cumplimos con el principio WET, por el juego de palabras en inglés, dónde WET sería el acrónimo de «write every time» o «we enjoy typing».

YAGNI

Tercer principio, tercer consejo y para cerrar el círculo tercer acrónimo, en este caso de «You aren’t gonna need it».

Este principio invita a no desarrollar «por si a caso», ¿cuantas veces nos han pedido una funcionalidad determinada y hemos excedido los requisitos en previsión de algo que nunca ocurrió? Pues bien, YAGNI propone hacer exclusivamente lo solicitado y necesario.

YAGNI tiene su origen en la programación extrema, dónde prima la simplicidad y dónde se opta por no invertir tiempo en dar solución a necesidades todavía inexistentes. La programación extrema se guían por la afirmación «Do The Simplest Thing That Could Possibly Work», de la cual han creado un acrónimo DTSTTCPW que desde mi punto de vista excede lo razonable y roza el absurdo.

Este principio es sin duda alguna el que más me ha costado aceptar de los tres que hemos visto hoy, de hecho, aunque estoy muy de acuerdo con él y creo que por norma general deberíamos cumplirlo, considero que la intuición de un desarrollador o un analista suficientemente experimentado, en combinación de un profundo conocimiento del negocio y del cliente, pueden dar pie a que nos saltemos este principio en ocasiones puntuales.

Créditos, referencias y artículos relacionados

• Imagen por Inactive Account en Pixabay.
• ¿A qué huele el código fuente?
• Patrones de diseño de software
• Refactorización de código
• Cohesión y acoplamiento
• Deuda tecnológica o deuda técnica

Qué son los patrones de diseño

La RAE define patrón como un «Modelo que sirve de muestra para sacar otra cosa igual», una definición muy acertada si la aplicamos al diseño de software.

Los patrones de diseño de software son un conjunto de estrategias de programación diseñadas para dar solución a problemas comunes. Cada patrón se centra en resolver un problema determinado, de forma que disponemos de una solución estándar que garantiza la resolución eficaz de un problema particular.

Podemos decir que existe un catálogo de patrones de diseño de software, aunque hasta dónde he podido investigar, no existe una lista oficial, pero si una serie de comunidades y organizaciones enfocadas en la investigación, aprendizaje, inventariado y comunicación de las mismas. Entre ellas podemos destacar The Hillside Group.

Otro aspecto más a destacar es que los patrones de diseño no son un ente estático, sino que evolucionan atendiendo a los nuevos retos que surgen con los avances en el área de la programación. Así, vemos como cada cierto tiempo se amplia el catálogo de patrones con algunos nuevos.

Un poco de historia

Podemos decir que los patrones de diseño fueron popularizados en la década de los noventa por un grupo de programadores conocido como ‘Gang of Four’ formada por: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.

La banda de los cuatro, traducción de Gang of Four, publicaron el libro ‘GoF Design Patterns’ en el año 1990. No obstante, debemos destacar que no fueron los primeros en acuñar el término.

El libro ‘GoF Designa Patterns’ está disponible en OpenLibra bajo licencia Creative Commons Attribution-ShareAlike 3.0.

Beneficios de los patrones de diseño

Estandarizar la estrategia de resolución de algunos problemas comunes aporta varios beneficios, estos son algunos de ellos:

• Ahorro de tiempo en el planteamiento y el diseño de la solución, pues no es necesario reinventar la rueda.
• Existencia de extensa documentación.
• Resultados previsibles y garantizados.
• Traspaso ágil de conocimientos.
• Estandarización de vocabulario.
• Facilidad para obtener soporte comunitario.

Tipos de patrones de diseño

El libro ‘GoF Design Patterns’, definía un total de 23 patrones divididos en tres categorías, pero desde su publicación han pasado casi treinta años, y como hemos comentado hablamos de un ente en constante evolución, así que tanto el numero de patrones como el número de tipologías en los que están segmentados han crecido considerablemente. A día de hoy, podemos dividir los patrones en las siguientes categorías:

• Patrones creacionales
• Patrones estructurales
• Patrones de comportamiento
• Patrones funcionales
• Patrones de concurrencia
• Patrones de arquitectura
• Patrones de computación distribuida
• Otros

De las cuales las tres primeras eran las que aparecían en el libro ‘GoF Design Patterns’.

Patrones de diseño

A pesar de no existir un catálogo oficial, a continuación veremos una lista de los principales patrones segmentados según las distintas tipologías que hemos visto.

Pensaba acompañar cada patrón de una breve descripción, pero teniendo en cuenta que mencionaremos más de cien, no acabaría nunca de escribir esta entrada. Así pues, tomaremos esta entrada como introducción e índice para futuros artículos dedicados a patrones de diseño específicos.

Los nombres de los patrones los especificaremos en inglés, aunque muchos de ellos tienen su traducción en castellano.

Patrones de diseño creacionales

• Abstract factory
• Builder
• Dependency injection
• Factory method
• Lazy initialization
• Multiton
• Object pool
• Prototype
• RAII
• Singleton

Patrones de diseño estructural

• Adapter
• Bridge
• Composite
• Decorator
• Delegation
• Facade
• Flyweight
• Front controller
• Marker interface
• Module
• Proxy
• Twin

Patrones de diseño de comportamiento

• Blackboard
• Chain of responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Null object
• Observer
• Servant
• Specification
• State
• Strategy
• Template method
• Visitor

Patrones de diseño funcional

• Closure
• Currying
• Function composition
• Functor
• Monad
• Generator

Patrones de diseño de concurrencia

• Active object
• Actor
• Balking
• Barrier
• Binding properties
• Coroutine
• Compute kernel
• Double-checked locking
• Event-based asynchronous
• Fiber
• Futex
• Futures and promises
• Guarded suspension
• Immutable object
• Join
• Lock
• Messaging
• Monitor
• Nuclear
• Proactor
• Reactor
• Read write lock
• Scheduler
• Thread pool
• Thread-local storage

Patrones de diseño de arquitectura

• ADR
• Active record
• Broker
• Client–server
• CBD
• DAO
• DTO
• DDD
• ECB
• ECS
• EDA
• Front controller
• Identity map
• Interceptor
• Implicit invocation
• Inversion of control
• Model 2
• MOM
• Microservices
• MVA
• MVC
• MVP
• MVVM
• Monolithic
• Multitier
• Naked objects
• ORB
• P2P
• Publish–subscribe
• PAC
• REST
• SOA
• Service locator
• SN
• SBA
• Specification

Patrones de diseño de computación distribuida

• Ambassador
• Anti-Corruption Layer
• Bulkhead
• Cache-Aside
• Circuit Breaker
• CQRS
• Compensating Transaction
• Competing Consumers
• Compute Resource Consolidation
• Event Sourcing
• External Configuration Store
• Federated Identity
• Gatekeeper
• Index Table
• Leader Election
• MapReduce
• Materialized View
• Pipes
• Filters
• Priority Queue
• Publisher-Subscriber
• Queue-Based Load Leveling
• Retry
• Scheduler Agent Supervisor
• Sharding
• Sidecar
• Strangler
• Throttling
• Valet Key

Otros patrones de diseño

• Business delegate
• Composite entity
• Intercepting filter
• Lazy loading
• Mangler
• Mock object
• Type tunnel
• Method chaining

Créditos, referencias y artículos relacionados

• Imagen por stux en pixabay
• ¿A qué huele el código fuente?
• Refactorización de código
• Cohesión y acoplamiento
• Deuda tecnológica o deuda técnica

Al igual que hicimos en la entrada Cohesión y acoplamiento, en la que puedes encontrar una buena descripción sobre estos dos conceptos, trataremos la cohesión única y exclusivamente a nivel de clase.

Y para no enrollarnos más, veamos el índice de contenidos y vayamos al lío.

Idoneidad de los tipos de cohesión

La cohesión dentro de una clase puede conseguirse utilizando diversas técnicas. Atendiendo a estas técnicas existen siete tipos de cohesión, algunas de las cuales son mucho más recomendables que otras. Así, si las ordenamos de más recomendable a menos recomendable tendremos lo siguiente:

• Cohesión funcional.
• Cohesión secuencial.
• Cohesión comunicacional.
• Cohesión procedimental.
• Cohesión lógica.
• Cohesión temporal.
• Cohesión casual.

Es más, si vamos un paso más allá y dividimos los tipos de cohesión en función de su idoneidad, podemos decir que existen tres grupos:

• Tipo de cohesión óptimo: funcional.
• Tipos de cohesión recomendados: secuencial, comunicacional y procedimental.
• Tipos de cohesión no recomendados: lógica, temporal y casual.

Tipos de cohesión

Veamos ahora los tipos de cohesión uno a uno.

Cohesión funcional

Es el tipo de cohesión óptimo, todos los elementos están relacionados para realizar una única tarea, lo que propicia el cumplimiento del principio de responsabilidad única (SRP). También favorecerá clases de fácil comprensión y mantenimiento.

Veamos un ejemplo:

public class updateStatusBar {
    

   private String message;
   private int level;

   public updateStatusBar(String message, int level) {

      this.setMessage(message);
      this.setLevel(level);

      this.clear();
      this.update();

   }

   private void clear() {

      this.message = "";
      this.level = 0;
      this.update();

   }

   private void setMessage(String message) {

      this.message = message;

   }

   private void setLevel(int level) {

      this.level = level;

   }

   private void update() {

      ...

   }    
    
}

Cohesión secuencial

Los métodos involucrados deben seguir un estricto orden de ejecución para completar la tarea. La cohesión se consigue tanto mediante la propia ejecución secuenciales de los métodos como mediante la utilización del mismo conjunto de datos, utilizando la salida de algunos métodos (return) como entrada por parámetros de otros.

Con el siguiente ejemplo lo veremos mucho más claro. Fijaos que ninguna de las instrucciones puede ser ejecutada sin antes haber hecho lo propio con la anterior, y cómo los resultados de la ejecución de los métodos pasan a los siguientes en forma de parámetros.

public class salesReport {

   private ReportType type;    

   public printOverviewReport () {

      Params params = this.getParams();
      String sql = this.generateSql(params);
      Result results = this.gelResults(sql);
      this.printReport(params, results);
      
   }

   ...
   
}

Cohesión comunicacional

Este tipo de cohesión se produce cuando los elementos se relacionan mediante el uso del mismo conjunto de datos, o dicho de otra forma, agrupamos en una misma unidad de software los componentes que hacen uso de un mismo conjunto de datos. Esto ocurre independientemente de que no estén relacionados funcionalmente.

Es un tipo de cohesión más habitual en un nivel superior de abstracción, por ejemplo, incluyendo en un mismo paquete distintos componentes, aunque puede darse perfectamente a nivel de clase.

En el siguiente ejemplo vemos como una misma clase realiza tareas funcionalmente diferentes: operaciones aritméticas y operaciones trigonométricas. La cohesión se obtiene mediante la utilización del mismo conjunto de datos.

public class numberOperations {
    
   private float numberA;
   private float numberB;

   public void setNumberA(float number) {

      this.numberA = number;

   }

   public void setNumberB(float number) {

      this.numberB = number;

   }

   public float sum () {

      return numberA + numberB;
      
   }

   public float subtract () {

      return numberA - numberB;
      
   }

   public double triangleHypotenuse() {

      return Math.sqrt(Math.pow(numberA, 2) + Math.pow(numberB, 2));

   }

   public float rectangleArea() {

      return this.numberA * this.numberB;

   }
    
}

Cohesión procedimental

Es bastante similar a la cohesión secuencial en cuanto que es necesario el seguimiento de un riguroso orden de ejecución, pero a diferencia de ésta, no existe una comunicación mediante parámetros.

public class salesReport {
    
   public assambly () {

      this.attachHeader();
      this.attachBody();
      this.attachFooter();
      
   }

   ...
   
}

Cohesión lógica

La relación entre los elementos es lógica en lugar de funcional. Por norma habitual los elementos pertenecen a la misma clase, las operaciones están relacionadas, pero las acciones que realizan varían significativamente en función de algún factor.

public class displayItemProperties {
    
   item Item;

   public displayItemProperties (item Item) {

      this.Item = Item;
      this.display();
      
   }
   
   private void display() {

      switch (this.Item.getType()) {

         case "shoes" : {
            this.displayShoesProperties();
            break;
         }
         case "shirt" : {
            displayShirtProperties();
            break;
         }
         case "trousers" : {
            displayTrousersProperties();
            break;
         }

      }

   }

   ...
    
}

En este caso quizás sería más acertado crear una subclase por cada tipo de producto y sobrescribir el método display().

Cohesión temporal

Es un tipo de cohesión nada recomendable, los elementos están cohesionados en base a un hecho que sucede en un determinado espacio de tiempo. Es habitual encontrar este tipo de cohesión en métodos de inicialización o finalización.

Con el siguiente ejemplo lo veremos muy claro, hemos incluido en la misma clase métodos funcionalmente muy dispares cuya única relación es que se ejecutan tras habernos autentificado en el sistema.

public class postLogIn {

   private int userID;
    
   public postLogInActions () {

      this.logAuth();
      this.retrieveNewAlerts();
      this.retrieveHewMessages();
      this.retrieveStats();
      this.printDashboard();
     
   }

   ...
   
}

Cohesión casual

Es el peor tipo de cohesión. Los elementos no tienen ninguna relación conceptual ni de ningún otro tipo de los que hemos visto hasta ahora, tan solo están agrupados en la misma unidad de software. Al igual que en la cohesión lógica, el resultado será siempre una clase multifuncional con una cohesión muy baja en el mejor de los casos.

public class posUtilities {
    
   public static float priceRound (float price) { ... }

   public static void updateTopBarPrice (float price) { ... }
    
   public static void cleanLogFiles () { ... }
    
   public static void reindexDb() { ... }

}

Conclusión

Lograr la cohesión a nivel de clase es relativamente sencillo, pero conseguir una clase funcionalmente cohesionada es algo más complicado y requiere de un mayor esfuerzo en la fase de diseño del software.

No obstante, ese esfuerzo extra invertido para conseguirlo se verá recompensado rápidamente, contribuyendo a evitar comprometernos con una deuda tecnológica que nos obligue a pagar intereses en el futuro.

Créditos, referencias y artículos relacionados

• Imagen de portada Manfred Steger
• Cohesión y acoplamiento
• Deuda tecnológica o deuda técnica
• Refactorización de código
• ¿A qué huele el código fuente?

A pesar de ser dos conceptos bien diferenciados, es muy habitual que al buscar información sobre la cohesión acabemos encontrando también información sobre el acoplamiento y viceversa. El motivo es que son dos conceptos que guardan una gran relación de complementariedad entre si. En esta entrada mantendremos ese mismo planteamiento y los abordaremos juntos.

Y antes de avanzar con la lectura, es importante puntualizar que aunque la cohesión y el acoplamiento pueden darse a distintos niveles, en esta ocasión analizaremos ambos conceptos única y exclusivamente a nivel de clase. Así que veamos el índice y vayamos al lío.

Qué son la cohesión y el acoplamiento

Cohesión y acoplamiento son dos conceptos distintos de gran importancia en el desarrollo de código de calidad, y están íntimamente ligados con el diseño del software y con la programación orienta a objetos. Veamoslos uno a uno:

Qué es la cohesión

La cohesión nos indica el grado de relación existente entre los distintos elementos de una clase. Una clase tendrá una cohesión alta cuando todos sus métodos estén relacionados entre si, bien mediante llamadas entre ellos o bien mediante el uso de variables cuyo ámbito se encuentre a nivel de clase. Y esto suele ocurrir cuando una clase realiza una única tarea.

Como habras podido intuir, cuanto más alta sea la cohesión mejor.

Qué es el acoplamiento

Y si la cohesión trata sobre la relación existente entre los elementos de la propia clase, el acoplamiento lo hace sobre el nivel de dependencia de la clase con respecto a otros elementos externos. Por lo tanto, diremos que una clase tiene un nivel de acoplamiento alto cuan hace uso en gran medida de otros componentes.

Nuestro objetivo será siempre construir clases con un nivel de acoplamiento bajo.

Beneficios de una alta cohesión y un bajo acoplamiento

Las ventajas de una clase cohesiva con bajo acoplamiento son muchas, pero podemos resumirlas como la mejora de la encapsulación, con todos los beneficios que ello conlleva.

Otro aspecto más a destacar es que el propio hecho de buscar la cohesión y evitar el acoplamiento ayuda a cumplir otros principios como SOLID o KISS, de los que probablemente escriba más adelante.

De cualquier forma, al ser dos conceptos distintos analizaremos sus beneficios por separado, aunque ya te adelanto que los podríamos haber tratado en conjunto, en unos instantes lo comprenderás.

Beneficios de una cohesión alta

Los principales beneficios de desarrollar elementos con un alto grado de cohesión son:

• Mejora de la mantenibilidad del código. Al realizar una única tarea, los cambios realizados sobre la propia clase afectarán en menor medida al código que hace uso de ella.
• Mejora de la lectura y comprensión. Es mucho más sencillo leer y entender una clase con una única responsabilidad, pues será más pequeña y simple.

Beneficios de un bajo acoplamiento

En cuanto al acoplamiento, los beneficios de desarrollar una clase con bajo acoplamiento son:

• Mejora de la facilidad de reutilización. Al no tener dependencia de elementos externos será muchos más sencillo portar nuestra clase a otros componentes.
• Mejora de la mantenibilidad. En este caso por partida doble: en primer lugar los cambios realizados en la clase no estarán condicionados por requisitos de estructuras de software externas, y en segundo lugar porque al no tener dependencias externas no se verá afectado por modificaciones en éstas.
• Mayor facilidad de comprensión. Pues no tendremos que buscar ni comprender otros módulos para aprender cómo funciona el que nos interesa.

Olores en el código

Si recordáis la entrada ¿A qué huele el código fuente?, hacíamos referencia a múltiples motivos que propiciaban la aparición de olores en el código fuente.

Pues bien, algunos de esos olores están estrechamente ligados con un bajo nivel de cohesión y/o con un alto nivel de acoplamiento: las clases multifuncionales, las clases brown dispatcher, o la envidia de funcionalidad son algunos ejemplos.

Como decíamos al comienzo del artículo, la cohesión y el acoplamiento tienen una gran importancia en el desarrollo de software de calidad.

Créditos y referencias

• Imagen de portada por truthseeker08
• Tipos de cohesión
• Deuda tecnológica
• Refactorización de código
• ¿A qué huele el código fuente?

La deuda

Y si una deuda económica la adquirimos a cambio de dinero, la deuda tecnológica la adquirimos a cambio de tiempo, el tiempo que ahorraremos a costa de planificar plazos imposibles de cumplir, de escatimar recursos en los procesos de testeo y/o refactorizacion, de no dedicar los recursos suficientes en el diseño inicial, o lo que es peor de no disponer de un diseño inicial, etc.

Es decir, adquiriremos una deuda al no hacer las cosas bien, y esto generalmente viene dado por dos motivos principales:

1. Omitir o reducir los recursos necesarios en las etapas fundamentales del proceso de desarrollo de software.
2. Existencia de una brecha de experiencia y/o conocimientos entre el equipo de desarrollo y el proyecto a ejecutar.

Cierto es también que en ocasiones la deuda técnica simplemente la heredaremos al hacernos cargo de un proyecto ya iniciado, pero el origen del problema es el mismo.

Los intereses

Y con la deuda vienen los intereses en forma de aumento de la complejidad en la mantenibilidad de la aplicación, y se manifestarán principalmente de dos formas:

1. Aumento de la complejidad del desarrollo. Cuanto más avancemos en el proyecto más complicado se hará seguir avanzando, invirtiendo mucho más tiempo del necesario en cualquier tipo cambio o nueva funcionalidad por pequeños que sean.
2. Incremento del número de errores. Lo que provocará que gastemos mucho tiempo subsanándolos en lugar de invertirlo en tareas que realmente aportan valor.

Es posible incluso que cuando empecemos a hacer uso del crédito tengamos un periodo más o menos largo de carencia, pero es seguro que los intereses aparecerán, y en ningún caso nos libraremos de pagarlos

Además, en función de las condiciones en que hayamos adquirido la deuda, y sobre todo si no la vamos saldando y dejamos que crezca, pueden aparecer una serie de consecuencias entre las que destacar las relacionadas con las personas, que en el caso del desarrollo de software son los distintos colectivos relacionados con el proyecto:

1. El cliente se quejará por falta de fiabilidad debido al número de errores de la aplicación.
2. Los programadores se quejarán porque son consciente de que no se están empleando buenas prácticas, cosa que les impide hacer su trabajo adecuadamente.
3. Los jefes se quejarán por el bajo rendimiento del equipo de desarrollo.

Una situación desagradable para todos y que deberemos evitar a toda costa.

Cómo evitar la deuda tecnológica

La buena noticia es que adquirir o no una deuda tecnológica, en muchas de las situaciones depende de nosotros y de nuestro equipo, y aunque no existe una receta mágica para evitarla, podemos tener en cuenta una serie de recomendaciones que contribuirán a evitarla.

En primer lugar hagamos una buena planificación y priorización. Si tenemos que adquirir una deuda que no sea porque hemos planificado mal, o lo que es peor aún, no adquiramos una deuda por mala planificación cuando además tenemos los recursos necesarios.

Y en el caso de no disponer de los recursos suficientes, debemos tener en cuenta que cada tarea conlleva su tiempo, que no podemos encajar cuatro en el hueco de tres y que si la planificación se complica siempre podemos:

1. Sumar más recursos al proyecto
2. Ampliar los plazos
3. Acotar el alcance

En segundo lugar creemos unas condiciones favorables para el desarrollo de código de calidad.

1. Establezcamos una metodología de desarrollo: Scrum, Kanban, Agile, Lean, en cascada o cualquier otra, y cumplámosla a rajatabla.
2. Asegurémonos de disponer de un circuito de entornos de desarrollo adecuado.
3. Escribamos código de calidad. Un código limpio y libre de olores favorecerá el mantenimiento y el crecimiento de nuestra aplicación.
4. Promovamos la refactoriza del código fuente. Recuerda la regla de los Boys Scouts, dejar el campo más limpio de lo que lo encontraste.

Preocupemonos de generar un buen ambiente de trabajo, hagamos que sea distendido, fomentemos las tareas en equipo y la participación.

Y si estas recomendaciones no son suficiente, siempre tenemos dos opciones más:

1. Adquirir una deuda, nos guste o no en ocasiones es necesario, en el siguiente apartado desarrollamos este planteamiento.
2. No ejecutar el proyecto. A veces decir no puede ser la mejor solución, no siempre todas las propuestas son viables, o simplemente puede la brecha entre recursos disponibles y recursos necesarios sea insalvable. Si es el caso, asegurémonos de haber analizado todas las posibilidades primero, seamos asertivos y sobre todo no usemos este recurso como excusa para librarnos de proyectos que no nos interesan.

Cuándo adquirir una deuda tecnológica

La respuesta sencilla sería nunca, pero como todos sabemos la realidad no es siempre tan favorable cómo nos gustaría, y el desarrollo de software no es una excepción. Por norma general, el desarrollo de software atiende a cuestiones de la vida cotidiana, y en un alto porcentaje de las situaciones a cuestiones relacionadas con el ámbito laboral, un ámbito muy exigente que requiere versatilidad e inmediatez.

Así que en ocasiones la necesidad de llegar a una fecha concreta con ciertas funcionalidades es imperativa. La adaptación del software a una nueva ley, la pérdida de la oportunidad si no llegamos a la fecha equis con aquella funcionalidad o dar solución a una problemática que por factores circunstanciales se ha convertido en crítica son algunas de los motivos que pueden hacernos decidir adquirir una deuda.

Lo realmente importante si adquirimos una deuda es ser conscientes de que lo estamos haciendo, comunicarlo a las partes implicadas y tener claro que vamos a tener que saldarla, obteniendo el compromiso tanto del equipo como de los superiores.

Conclusión

En esta entrada hemos visto que es la deuda tecnológica, cómo nos afecta y algunos consejos sobre cómo evitarla. Nos queda pendiente ver las estrategias que podemos seguir para saldarla, pero eso da para otra entrada.

Si te has sentido identificado al leer este artículo no pienses que eres uno de los pocos desafortunados que la sufren, lamentablemente y en contra de lo que cabría esperar, la deuda tecnológica es una situación mucho más generalizada de lo que imaginamos. Una gran cantidad de compañías se enfrentan a este fenómeno a diario, llegando a convertirse en un factor crítico en algunas de ellas.

Afortunadamente la industria del desarrollo de software ha vivido una evolución vertiginosa en los últimos años, y algunos de los aspectos que han generado más interés entre la comunidad han sido los relacionados con las técnicas de desarrollo de código de calidad, así que aprovechemos esta concienciación global y contribuyamos a desarrollar un código de mayor calidad.

Créditos, referencias y artículos relacionados

• Guía del buen programador
• ¿A qué huele el código fuente
• Patrones de diseño de software
• Refactorización de código
• Cohesión y acoplamiento
• Deuda tecnológica o deuda técnica

Al respecto de esto, uno de los aspectos al que más atención deberemos de prestar es al diseño de los distintos entornos que participan en el ciclo de vida del software y a los procedimientos que definen el flujo de trabajo entre ellos.

Y para que todos tengamos en mente el mismo concepto de la palabra entorno, lo definiremos cómo un sistema formado por hardware y software, así como la configuración, circunstancias y estados relativos a él. En el diseño de nuestro procedimiento podemos establecer varios entornos con distintos fines por los que debe pasar el software durante su ciclo de vida antes de llegar al definitivo entorno de producción.

Un diseño para cada necesidad

El número de etapas, los procesos que las definen y los softwares que utilizamos pueden variar en función de las características de cada proyecto y la idiosincrasia de cada compañía.

Algunos de los factores que pueden influir a la hora de decidir que entornos incluiremos en nuestro flujo de trabajo y que procedimientos los definirán son el tamaño del proyecto, la complejidad del software, las tecnologías utilizadas para el desarrollo, la cantidad de desarrolladores implicados en el proyecto, la metodología de desarrollo elegida o la criticidad del software.

Los tipos de entorno

En esta entrada repasaremos un conjunto de entornos bastante común, muy completo y que funciona bien en el desarrollo de aplicaciones web con equipos pequeños o medianos y  metodologías de desarrollo ágiles. Esta configuración es solo un ejemplo, es perfectamente adaptable a otras necesidades y trasladable otros proyectos con similares (e incluso distintas) características.

Entorno de desarrollo

Es el lugar dónde programamos, lo más habitual es que esté localizado en la propia máquina de cada desarrollador de forma que varias personas pueden estar trabajando en un mismo proyecto a la vez sin molestarse.

Para minimizar incidencias en etapas posteriores es recomendable que este entorno disponga de un software y una configuración lo más parecida posible a la que nos encontraremos en el entorno de producción. Situaciones como desarrollar sobre php 7.2 y que el entorno de producción se encuentre corriendo php 5.6 o hacerlo sobre windows con el driver «x» de sql server y que el servidor de producción sea una máquina linux con el driver «y» suelen acabar generando muchos quebraderos de cabeza fácilmente evitables.

Solo cuando el desarrollador completa un código perfectamente funcional e integrable en el entorno de pre-producción y tras realizar las pruebas necesarias para asegurar que el software desarrollado tiene la estabilidad suficiente  se podrá pasar al entorno de integración continua.

Entorno de integración continua

Este entorno cumple un triple objetivo:

1. Integrar el trabajo de los diferentes desarrolladores en un repositorio central, dando como resultado una versión del código actualizada y consolidada.
2. Automatizar las pruebas de integración y su validación antes de ser movido al siguiente entorno.
3. Enviar el código al siguiente entorno si las pruebas han sido superadas satisfactoriamente.

La forma más habitual de implementar este entorno es mediante un software de control de versiones, dónde Git es la opción más popular. Una vez consolidado el código utilizamos los hooks para ejecutar las pruebas definidas, notificar los resultados y enviar a pre-producción si es preciso.

Entorno de pre-producción

Una vez superadas las pruebas de integración en el entorno de integración continua, el código será movido al entorno de pre-producción. Aquí se realizarán las pruebas de validación al conjunto del software, teniendo como objetivo localizar cualquier error antes de llegar al entorno de producción y evitar así los problemas derivados de ellos.

Este entorno será completamente funcional a nivel de usuario, y si hemos recomendado que el entorno de desarrollo fuese lo más similar posible al entorno de producción, aquí se convierte en algo crítico. Tanto el software, dónde no solo hablamos de las aplicaciones si no también de sus versiones y configuraciones, como el hardware y los sets de datos. Cuanto mayor sea la similitud con el entorno de producción menor será el número de  incidencias que nos encontremos cuando el software esté en productivo.

Entorno de demo

Es un entorno muy similar al de pre-producción, y por lo tanto al de producción. Lo habilitamos para que el cliente final pueda probar la nueva aplicación o las modificaciones o correcciones realizadas a la aplicación existente. De aquí extraeremos las impresiones del cliente y localizaremos de una forma temprana posibles carencias en los requisitos iniciales, en el diseño o en su implementación.

Si en nuestro proyecto la validación del cliente es necesaria, no disponer de este entorno puede suponer que el cliente valide contra el entorno de pre-producción (o mucho peor aun contra el de desarrollo o de producción), en cuyo caso pueden darse varias situaciones:

1. Que todo salga maravillosamente bien, improbable pero posible.
2. Que una nueva actualización en el entorno de pre-producción, esté o no relacionada con la funcionalidad que estamos probando, provoque errores y demos la validación por fallida.
3. Que congelemos la actualización del entorno de pre-producción incurriendo en molestias y dificultades extra para el equipo de desarrollo y retrasando las fechas del proyecto.

Estos problemas se verán aumentados si trabajamos en base a una metodología de desarrollo ágil con entregas iterativas.

Entorno de producción

Es la culminación de nuestro esfuerzo, el entorno dónde se verán las virtudes y defectos de nuestro trabajo, el objeto por el que seremos valorados. Los cuatro entornos anteriores están pensados para llegar aquí de la forma más eficiente posible garantizando la fiabilidad, y la diferencia de calidad sobre el resultado final puede ser realmente significativa significativa de disponer de un circuito de entornos adecuado a no disponer de él.

Las pruebas

Uno de los aspectos más significativos de este circuito es que cada entorno debe tener su propio tipo validación y por lo tanto de pruebas. Lo más habitual es realizar test unitarios en el entorno de desarrollo, test de integración en el entorno de integración continua y pruebas de validación sobre el conjunto de la aplicación en el entorno de pre-producción.

Para los test unitarios existen varias herramientas entre las que destacar PHPUnit, aunque si usamos frameworks como Laravel, el propio framework ya nos proporciona herramientas para realizar este tipo de pruebas. A partir de ahí existe un amplio abanico de herramientas para ayudarnos a realizar todo tipo de comprobaciones, en la página PHP Quality Assurance podemos encontrar algunas.

Conclusión

Concedamos la importancia que se merece al diseño y la implementación de los entornos implicados en el desarrollo del software, de ellos dependerán en gran medida la calidad de los resultados y la velocidad de desarrollo.

Y como siempre me gustaría conocer sobre tu experiencia, ¿trabajas sobre un circuito con más o menos entornos? ¿qué tipo de pruebas realizas? ¿Con qué softwares?

Créditos, referencias y artículos relacionados

• Guía del buen programador
• ¿A qué huele el código fuente
• Patrones de diseño de software
• Refactorización de código
• Cohesión y acoplamiento
• Deuda tecnológica o deuda técnica

La elección de los nombres de los distintos elementos que intervienen en la programación es una de esas tareas que si bien no es técnicamente compleja, puede suponer un antes y un después en cuanto a la calidad del código que generamos.

En esta entrada veremos cómo la elección de nombres adecuados puede contribuir a reducir el número de comentarios necesarios en el código fuente, y por lo tanto a mejorar su limpieza, comprensión y mantenimiento.

Este artículo es el cuarto de una serie de entradas dedicados a los comentarios y cuyo índice podemos encontrar en la entrada Introducción a los comentarios en programación. Así que si estás interesado en mejorar no solo tus comentarios, si no tu programación en general, te recomiendo que leas los tres anteriores: Introducción a los comentarios en programación, Comentarios a evitar al programar, y Mantenimiento de comentarios en la programación.

Nombres descriptivos

Es  bastante común ver funciones o métodos precedidos de un comentario que explica cual es su cometido. Esta situación por si misma no es mala siempre que ayude a entender el código a otros desarrolladores. Sin embargo, en muchas ocasiones la elección de un nombre adecuado puede ser suficientemente descriptiva como para evitar el comentario.

Veamos un ejemplo inspirado en una aplicación TPV (Terminal Punto de Venta):

// Devuelve el precio de un producto valorando descuentos y
// rebajas para un cliente autentificado
private bool getPrice(int itemId, int userId) {
{
   ...
}

Como vemos el nombre del método es descriptivo hasta cierto punto, motivo por el que el comentario ayuda a complementarlo. Pero esto mismo podríamos hacerlo utilizando un nombre más adecuado:

private bool getAuthentificatedCustomerFinalPrice(int itemId, int userId) {
{
   ...
}

En este segundo ejemplo al leer el nombre del método sabemos exactamente que esperar de él, así que no es necesario el comentario.

Hemos podido utilizar esta técnica sin ningún problema porque cumplimos la regla que establece que cada función debe hacer una única cosa. Si no la cumplimos e intentamos escoger un nombre descriptivo nos encontraremos con nombres excesivamente largos. Veamos un ejemplo siguiendo el hilo anterior pero en esta ocasión el método realizará dos tareas:

private bool identifyIfCustomerIsLoggedAngGetFinalPrice(int itemId, int userId) {
{
   ...
}

Cuantas más cosas haga el método, más largo y difícil de elegir será el nombre y esto se traducirá en un código poco legible y difícil de trabajar, volviendo a ser necesarios los comentarios.

Y por supuesto que esta técnica es totalmente aplicable a variables y constantes, escogiendo nombre adecuados eliminaremos la necesidad de explicar el objetivo de las mismas con comentarios. No es lo mismo usar nombres poco descriptivos y acompañarlos de un comentario en la declaración:

// Coste de reposición de artículo
private float cost;

Que utilizar nombre descriptivos, prescindir de los comentarios y saber que contiene exactamente la variable en cualquier punto del programa:

private float supplierPriceOfList;

Sustituir un pedazo código por una función

En ocasiones explicamos pedazos de código porque queremos transmitir nuestra intención, porque ayuda a la comprensión de un algoritmo con cierta complejidad, porque nos parece que es engorroso de leer y un comentario lo facilitaría, etc. Pongamos un ejemplo muy sencillo, de nuevo sobre un programa TPV:

// Comprobamos si hemos introducido un descuento manual 
if(
   (item.price  > item.proposedPrice)  &&
   (discount.reason is null) &&
   (item.price != item.proposedPrice * customer.discount)
)
{ 
   ... 
}

El programador que ha escrito este código (yo) ha querido dejar claro que las tres condiciones que ha escrito tenían como intención averiguar si se había introducido un descuento manual.

Pero quizás sea mucho más claro leer el código de esta manera:

if(manualDiscountIsApplyed())  
{
   ...  
}

Y para ello solo tenemos que encapsular ese bloque lógico en otro método con un nombre adecuado:

private bool manualDiscountIsApplyed()  
{  
   bool discountIsApplied = false;  
   if(  
      (item.price > item.proposedPrice) &&
      (discount.reason is null) &&
      (item.price != item.proposedPrice * customer.discount)  
   )  
   {  
      discountIsApplied = true;  
   }  
   return discountIsApplied;  
}  

Aunque si lo pensamos un instante lo único que hemos hecho ha sido un uso correcto de la programación orientada a objetos, el resto ha sido de nuevo la elección de un buen nombre.

Conclusión

En el desarrollo de software, como en prácticamente todo, cuanto más simple y breve sea la solución, mejor. Lejos de de extender y adornar el código debemos procurar sintetizar y aclarar todo lo posible de forma que sea sencillo de comprender por si mismo, y para ello una elección correcta de nombres es fundamental.

Y como es habitual, sería muy interesante conocer tu punto de vista, ¿qué otra técnica utilizas tú para mejorar la legibilidad del código y evitar comentarios innecesarios? Comparte tu experiencia en un comentario.

En multitud ocasiones he visto y he escrito comentarios que ensucian el código y que en el mejor de los casos solo son una molestia visual. En cambio, otras ocasiones, me he tropezado con comentarios que pueden llegar a confundir al programador, sembrar la duda en él o hacer que gaste más tiempo del necesario intentando comprender la discrepancia entre el comentario y el código.

Esto ocurre principalmente porque al igual que sucede con el resto del código fuente, los comentarios requieren de un mantenimiento. Y para conseguirlo es necesario que el desarrollador sea mucho más estricto que con el resto del código: si el compilador no alerta tendremos que ser nosotros quien garanticemos que son correctos. Y el problema radica en que incluso si los comentarios son un verdadero desastre, si el código es correcto el programa funcionará, y muchas veces eso nos basta.

[the_ad id=»1018″]

Así que en esta entrada trataremos algunos aspectos que hemos de tener en cuenta a la hora de mantener nuestros comentarios. Este artículo pertenece a una serie cuyo índice podemos encontrar en la entrada Introducción a los comentarios en programación.

Comentarios a evitar

Hace una semana publicamos una entrada titulada Comentarios a evitar al programar.  En ella hablábamos de los comentarios que no deberíamos hacer que perduren en el código, y podemos decir que éste es el primer paso que debemos de tomar a la hora de mantener los comentarios. Haciendo un breve resumen hablamos de:

1. Código fuente comentado
2. Identificación de modificaciones
3. Código para debugar
4. ToDos y notas de tareas pendientes

Si todavía no has leído este artículo te recomiendo que lo hagas antes de continuar con el siguiente punto.

Copy & Paste

¿Cuantas veces has copiado y pegado un fragmento de código en el que existen comentarios? Pongamos el ejemplo de un método cualquiera, queremos crear otro bastante similar  y optamos por copiar y pegar en lugar de escribir desde cero. Acto seguido modificamos el nuevo método, pero, ¿cuantas veces hemos dejado un comentario sin modificar haciendo referencia al funcionamiento del método original?

Como primer planteamiento me preguntaría si el comentario es realmente necesario, pues si no le has dado la importancia adecuada quizás es simplemente porque no la necesita y puede ser eliminado. Pero en caso de que deba ser mantenido no olvides actualizarlo si es necesario. De lo contrario estarás mintiendo al programador que lo lea.

Modificaciones en el código

Lo más habitual cuando modificamos unos fuentes es que estemos alterando de una u otra manera su funcionamiento. Si existe un comentario realizado sobre el bloque de código que estamos modificando, deberemos de verificar que tras la modificación el comentario sigue siendo tan necesario y válido como era antes de cambiar una sola línea. De lo contrario volveríamos a tener un comentario erróneo.

Imaginemos que tenemos un método userIsAuthenticated() que devuelve la ID de un usuario en caso de que esté autentificado y 0 en caso de que no lo esté.  Imaginemos que modificamos ese método para que devuelva true si está autentificado y false si no lo está, y a su vez creamos otro método getUserId() que devuelve la ID de un usuario autentificado. En caso de que existiera algún comentario en el método original o en alguna llamada al método también debemos de modificarlo para que refleje el nuevo comportamiento.

El precio de no mantener los comentarios

Imaginemos qué estamos revisando un código escrito por otro desarrollador, y a medida que avanzamos notamos que los comentarios son superfluos y en muchos casos imprecisos e incoherentes con respecto al código, ¿qué ocurriría? Probablemente o los ignoraríamos por completo o seguiríamos leyéndolos a regañadientes.

Pero ¿que ocurriría si en lugar de ignorarlos tomamos por bueno la información de los comentarios en lugar de la realidad del código? La respuesta dependerá de cada situación, y en cada una de ellas intervendrán muchos factores, así que dejo esta respuesta a tu criterio, pero personalmente ninguna situación de las que soy capaz de imaginar es positiva.

Refactorizar comentarios

Hace no mucho escribíamos también sobre el código oloroso en la entrada ¿A qué huele el código fuente? y sobre refactorización en la entrada Refactorización de código.

La refactorización de los comentarios, que hoy estamos llamando mantenimiento, es tan importante como la del propio código. No basta solo con seguir los manuales de buenas prácticas al escribir nuevo código, debemos limpiar y corregir los comentarios irrelevantes, incomprensibles, imprecisos, incoherentes o erróneos que nos encontremos como parte de nuestra labor.

Si decidimos no refactorizar la primera consecuencia será que asumiremos que tanto nosotros como el resto del equipo que trabaje con ese código vamos a tener que convivir con comentarios erróneos. Y la segunda consecuencia que se dará con bastante probabilidad, es que el equipo se contagiará de la dejadez del código y comenzará a emplear malas prácticas, lo que suele acabar en un problema que crece con el paso del tiempo.

Conclusión

Debemos tratar los comentarios con la misma delicadeza que tratamos el resto del código, pues un código bien comentado facilita el mantenimiento del software y contribuye a evitar la deuda tecnológica.

¿Y tu qué opinas?, ¿crees que existen más situaciones relacionadas con los comentarios que debamos tener en cuenta en el mantenimiento?, ¿tienes algún consejo o recomendación? Sabes que nos gusta leer tu opinión, compártela en los comentarios.

Por supuesto que podemos utilizarlos para ayudarnos a debugar,  para ponernos notas, recordatorios o ToDos en en código y mil usos más. Pero los comentarios tienen un único objetivo que es aclarar la intención de un determinado bloque de código, y deberemos ceñirnos a este objetivo para garantizar la limpieza y la mantenibilidad de nuestros fuentes. Todo uso que se aleje de este objetivo (o de la documentación del código) no debe perdurar en el tiempo.

Así que a continuación veremos algunos usos inadecuados de los comentarios que están muy extendidos y que deberíamos evitar.

Este artículo forma parte de una serie que trata de una forma más amplia el uso de los comentarios en la programación, y en la que el artículo Introducción a los comentarios en la programación utilizaremos como índice.

Código comentado

Cuando estamos trabajando en un proyecto es bastante habitual encontrarnos con código fuente comentado. Suele ocurrir que comentemos  un pedazo de código por un motivo temporal y no realicemos una limpieza posterior, con lo que queda ahí para la posteridad. Otro motivo bastante habitual es que realicemos un cambio en el código, no dispongamos de un software de control de versiones y no queramos perder el código original.

Sea cual sea el motivo, ¿qué debe interpretar un desarrollador cuando se encuentra un código comentado? ¿Lo ignora? ¿Lo compara o lo interpreta e intenta relacionarlo con el código no comentado? ¿Qué se supone que debe hacer?

Debemos ser limpios y no dejarnos fragmentos de códigos comentados en nuestros fuentes, y si no disponemos de un software de control de versiones deberíamos darle la máxima prioridad a incluir uno en nuestro proyecto. Puedes ver las entradas Instalar y configurar Git en una Raspberry Pi con Ubuntu Mate o Crear un repositorio remoto en Git desde archivos locales.

Identificación de modificaciones

Un uso menos extendido pero con el que he tropezado en alguna ocasión es una versión «sofisticada» del punto anterior. Realizamos una modificación, comentamos el código original e incluimos ciertos datos como el nombre del desarrollador, la fecha en la que se realizó el cambio y el motivo por el que se hizo.

Veamos el siguiente ejemplos:

// J.J. 15/10/2017  
// Bug: no permitía nombres de 8 caracteres  
// if($userName > 8) {  
if($userName >= 8) {  
   ...  
}

La molestia visual es evidente, además que que nos llevará más tiempo leer y comprender 4 líneas que una:

if($userName >= 8) { 
   ... 
}

Siempre existen circunstancias alrededor de un proyecto, pero de nuevo, si éste no tiene software de control de versiones todos nuestros esfuerzos deberían centrarse en conseguirlo.

Código para debugar

Esto ocurre en mayor medida, aunque no exclusivamente, en proyectos de desarrollo web. Para ayudarnos a debugar nuestro software incluimos líneas extra de códigos que realizan una tarea determinada. Una vez completado el debug las comentamos y permanecen como partes del código fuente eternamente. Esto no hace más que ensuciar el código, la persona que vuelva a tocar esos fuentes probablemente no necesitará debugar en ese punto, o lo hará de otra forma, así que seamos limpios y borremos este tipo de comentarios.

Además, otro hecho que ocurre, es que si continuamente encontramos comentarios que no añaden valor, acabaremos por ignorarlos todos, ¿por qué tenemos que tropezarnos con comentarios de este tipo en el código?

/*  
echo '<pre>';  
printr($var);
echo '</pre>';  
die();  
*/  

Pero sobre todo, asegúrate de disponer de herramientas para debug. Cuando programamos en Java, C++, Basic, C#, etc. no concebimos desarrollar sin herramientas de debug adecuadas, que por lo general vienen incluidas en las IDEs.  Así que si eres desarrollador web, asegúrate también de disponer de éstas herramientas. En este mismo blog tenemos una entrada sobre cómo Debugar PHP con Netbeans y XCode. Para debugar Javascript también tienes múltiples opciones con herramientas como Chrome DevTools o la consola de Mozilla Firefox.

ToDos y notas de trabajo

En ocasiones nos ponemos notas al programar, yo por ejemplo en ciertas situaciones  incluyo alguna línea del tipo:

// todo: añadir validación de longitud máxima al nombre  
if($userName >= 8) {  
...
}

Existen IDEs que traen soluciones para este tipo de notas, también existen programas que pueden ayudarnos a gestionar estas notas de forma muy efectiva. De cualquier forma, si te gusta trabajar con este tipo de comentarios asegúrate de borrarlo una vez que hayas finalizado la tarea, y si no la vas a terminar, el código fuente no es el lugar dónde indicar las tareas pendientes de completar, así que mejor busca una alternativa.

Concluisión

A pesar de que los comentarios lo aguantan todo, debemos de ser estrictos y hacer un buen uso de ellos, o de lo contrario nunca tendremos un código limpio. Como hemos podido ver, con un software de control de versiones y  alguna herramienta para gestionar tareas pendientes podemos reducir drásticamente el número de comentarios inadecuados.

Seguro que tú también te has encontrado con muchos tipos de comentarios inadecuados, ¿de qué tipo eran? ¿qué herramientas utilizas para evitar estos comentarios?  Como siempre me gustaría conocer tu experiencia.