Mi amigo Joan me contestó al mail en el que te contaba sobre la Ley del cambio continuio.
Copio y pego lo que me dijo:
No se si te habrás encontrado con esto, pero puede pasar algo peor. Que heredes un código que no esta preparado para adoptar cambios. Lo mejor en este caso seria que como ese código no esta preparado para adoptar cambios, la idea de aplicar un cambio se desvanezca. Pero es que el cliente de eso no entiende… El cliente quiere el cambio… Y tu no lo puedes aplicar porque el código no te lo permite… Que haces? Pides tiempo para hacer un refactor, pero el cliente no entiende de eso tampoco, y no quiere pagar por algo que no repercuta directamente en el cambio que ellos quieren. Te encuentras entre la espada y la pared. A veces te sacas de la chistera una chapucilla que se acerque, quizas de forma perfecta, a lo que pide el cliente, pero es pan para hoy, hambre para mañana. Es un boomerang, esa chapucilla algun dia volverá y te perseguirá.
En estos momentos si no estas acompañado de un buen equipo (director de proyecto, o incluso la rama comercial de la compañía ), estas muerto… Pero aqui ya no estamos hablando de software.
Todo esto para decirte que estoy de acuerdo que hacer software de calidad es muy importante. Los proyectos mal ejecutados acaban en frustración del desarrollador que tiene que lidiar con ellos, y en mucho de los casos acaba “quemandolos” y con la renuncia del puesto de trabajo (soy un experto en eso)
Me ha gustado este capítulo.
Saludos!
Me gustó mucho lo que le contesté y creo que es válido para ti también.
Le hablo de dos habilidades que, en mi opinión no solicitada, son muy buenas para añadir a la caja de herramientas.
Te pego la respuesta q le dí:
Escribir código es un compromiso constante.
Somos ingeniero y desgraciadamente en la industria te encuentras con muchas situaciones como la que dices.
Te llaga un código de mierda que a priori no tienes ni idea de cómo cogerlo.
Intentas explicarlo al cliente o manager de turno y no te entienden.
Para mi, hay dos habilidades q son buenas para aprender.
La primera, es hacer entender al cliente/manager lo complicado que sería hacer el cambio por más fácil que parezca. Verdad que no le dirán al carnicero cómo cortar la carne? Ni al doctor como operar? Al final es una relación de confianza.
La otra, y es donde entra el compromiso por nuestra parte de ingenieros, es aprender a liar con el código basura, tanto propio, como heredado.
Que quiero decir exactamente?
Pues quizás ir limpiando el código poco a poco, poniendo tests del código viejo (si se puede) y en el nuevo para que nos dé seguridad.
Cada vez q se toca el código es una oportunidad para limpiarlo.
Y la habilidad está en reconocer/saber que puedo limpiar y hasta donde puedo limpiar pq es muy fácil irnos de madre.
Soy Josué Alcántara y cada día envio un mail con una idea para escribir software de calidad. ¿A quién se la envío? A mi lista de suscriptores. Día que estás fuera, idea que te pierdes. Así de fácil.
