Como venimos comentando en post anteriores (sobre todo en los comentarios) una de las principales tareas del desarrollador es producir código legible para facilitar el mantenimiento del proyecto.
Pero código legible… ¿para quién?
Estaremos todos de acuerdo conque el código debe ser legible para el que lo escribe. Uno debe intentar ponerse en situación y pensar ¿dentro de un año entenderé esto? Si el código no se entiende un mes después de haberlo hecho, significa que algo se está haciendo mal.
Pero los programas suelen ser tocados por más de una persona, ya sea en la fase de desarrollo o de mantenimiento.
Durante el desarrollo de una aplicación se debe intentar mantener un mismo estilo de programación, es necesario que el equipo comparta (o al menos siga) la misma filosofía. Es ahí cuando entra la labor del responsable técnico del proyecto (llámese desarrollador sénior, analista, arquitecto, jefe de proyecto, etc). Esa tarea no es fácil, se puede tener suerte y contar con un equipo que personas preparadas y que coincidan con la mentalidad del responsable, pero la mayoría de las veces no va a ser así.
Lo mismo pasa en tareas de mantenimiento, bueno, en ese caso es peor, ya que todos los programadores solemos ser muy críticos con los productos realizados por los demás y solemos decir que todo es una mierda.
Voy a poner dos ejemplos de lo que se podría considerar soluciones correctas, pero que en la realidad han no han surtido el efecto deseado.
Los patrones son soluciones estándar a problemas habituales, el libro de referencia de patrones se llama Design Patterns: Elements of Reusable Object-Oriented Software, o como lo conoce casi todo el mundo, el libro del GoF. Uno de los patrones más conocido es el singelton. En una clase singelton el constructor es privado. Si un desarrollador necesita una instancia del objeto y se encuentra con que no puede acceder al constructor ¿podría hacerlo público? Sí, ya ha pasado. Si lo hace un miembro del equipo de desarrollo y se ve se puede solucionar, pero si lo hacen en la fase de mantenimiento… mejor no pensarlo.
Alguno podría pensar que los patrones son un mal ejemplo, ya que los programadores no están obligados a conocerlos. ¿Debería un programador estar familiarizado con la programación orientada a objetos? Supongamos un ejemplo muy sencillo de herencia:
class Trabajador
{
public string Nombre { get; set; }
public decimal HorasAnuales { get; set; }
public decimal PrecioHora {get; set;}
public virtual decimal CalcularSalario()
{
return HorasAnuales * PrecioHora;
}
}
class Jefito:Trabajador
{
public decimal Incentivos { get; set; }
public override decimal CalcularSalario()
{
return base.CalcularSalario() + Incentivos ;
}
}
class SuperJefe:Jefito
{
public decimal Dietas { get; set; }
public override decimal CalcularSalario()
{
return base.CalcularSalario() + Dietas;
}
}
Lo cierto es que no todo el mundo está familiarizado con mecanismos como la herencia y ante un caso tan sencillo como este se puede obtener una respuesta como “estas poniendo el if en otro sitio”. Hay gente que ve más sencillo de tener un único método calcular salario con un if y los tipos de trabajadores, que la jerarquía descrita anteriormente.
Con todo esto no quiero decir que no se usen los patrones de diseño o la programación orientada a objetos. Tan solo planteo el problema de saber cuando estamos escribiendo código legible.
Señalar los problemas es mucho más fácil que dar soluciones, lo cierto es que no tengo (y no sé si alguien tiene solución para esto). Supongo lo mejor es aplicar nuestro sentido común (como de costumbre). Lo típico: intentar formar a la gente, tener una cultura unificada de codificación, etc. Aunque esto no siempre sea posible.
En mi no siempre humilde opinión, un programador que trabaja con una tecnología orientada a objetos tiene la obligación de conocer los conceptos básicos de la orientación a objetos y manejarlos adecuadamente. Llegados a ese punto podemos pensar en usar siempre bucles while porque el programador no conozca los for, o usar gotos en lugar de ifs.
ResponderEliminarSi el programador no conoce la tecnología que maneja a un nivel mínimo, debe ser formado en ella, pero no puede hacerse el desarrollo en contra de los principios de la tecnología sólo porque uno o varios de los programadores no tengan el nivel suficiente.
Pero claro, todo esto depende de dos de los puntos flacos de la consultoría en este país: selección de personal y formación.
Estoy de acuerdo con vosotros. Pero deberíais tener en cuenta que si un programador no llega a un nivel mínimo, no es un programador, es mano de obra no cualificada a la que hay que enseñarle a programar.
ResponderEliminarPor supuesto, ahí es donde entran la selección de personal y la formación: si se buscaba un programador experimentado y no cumple las expectativas, la selección ha sido deficiente. Si se buscaba a alguien para formar, hay que invertir recursos en su formación. Si el individuo no aprende, es nuevamente un problema de selección: hay que deshacerse de él o asignarlo a tareas que estén a su alcance.
ResponderEliminarLa pregunta es si te colocan a una persona que dicen que sabe y cuando te pones con ella ves que no. ¿Es culpa de esa persona o de la que lo ha asignado? Se ha colocado un farol o son los jefes los que lo han elegido así.
ResponderEliminarCreo que ese es un factor muy importante para decidir.
Otro caso que se da con la crisis es la recolocación interna, gente que no se ajusta al perfil necesario asignado a él ¿es culpa de la persona? ¿la empresa debe reciclarlo? ¿se debe reciclar él?
Son de masiadas variables, cada caso es un mundo.
Creo que salvo que venga alguien de fuera haciendose la estrella y luego no sabe hacer la O con un canuto, en el resto de los casos es necesario ayudar.
En ningún momento se dice que no se deba ayudar a un compañero, pero intenta extrapolar la situación a cualquier otra actividad: "en el taller no usamos máquinas de diagnóstico porque son complejas y hay algunos que no las saben manejar, y apretamos todas las tuercas con llave inglesa en lugar de llaves más sofisticadas o motorizadas". O ya puestos, un médico que no use resonancias por si alguien de su equipo no las sabe interpretar.
ResponderEliminarPero como siempre, somos el gremio de las castañuelas en el país de la pandereta. Si mi empresa me recoloca en un puesto que no es adecuado para mi, tengo que aprender a hacer esa nueva labor o irme (suponiendo que esa recolocación sea legal, que ya es harina de otro costal).
Uno debe usar las mejores herramientas de que dispone, ciñéndose en la medida de lo posible a que sean estándar en la tecnología usada. No estamos tratando "la última novedad de la última revisión del framework XYZ", sino una herramienta básica de un paradigma de programación. Si un miembro del equipo no es capaz de aprender esos conceptos básicos (con toda la ayuda que se le proporcione) simplemente sobra.