Programadores y personas que hacen programas
Estos días estoy haciendo una de mis labores preferidas, Refactorizar. El termino lo conocí hace años, cuando me interese por el Extrem Programming y metodologías relacionadas. Cuando oí hablar de el me dí cuenta de que esa palabra significaba lo mismo que yo hacía cuando tenía tiempo de mejorar mis programas. Lo que no sabía era la cantodad de teoría escrita sobre el tema.
Decidí entonces comprarme el mítico libro Refactoring, del también mítico Martin Fowler. Al libro le pondría un 7. Explicaba como hacer una refactorización y le daba nombres a muchas de las operaciones que todos hacemos habitualmente, pero esperaba que también te enseñara cuando y porque aplicar una refactorización. Hoy en día no sabría decir si gracias a los IDEs y sus modulos de refactorización (atención a Netbeans Jackpot) este libro ha pasado a la historía.
Otro libro del que guardo un buen recuerdo es Java Design de Peter Coad, Mark Mayfield y Jon Kern. De este libro destaco especialmente sus primeros capítulos, donde te enseñan de forma muy clara como diseñar software. Porque y cuando aplicar composición, herencias y sobre todo el uso de interfaces. El libro dedica más de 80 páginas a explicar que es un interfaz. Siempre que cojo este libro se me revuelven las tripas al recordar la primera y única explicación que recuerdo haber recibido sobre interfaces en la universidad: El interfaz es un contrato que obligas a firmar a una Clase. Punto y final. Espero que el resto de mis 5 años se ofrecierá algo mejor al personal alguno de los días que no fuí a clase.
El interfaz es para mi, junto con la refactorización, las herramientas más avanzadas de un programador. Creo que una persona que trabaja en el mundo de la programación e ingeniería del software debería de conocer estas dos herramientas como la palma de su mano. Se de empresas que utilizan lenguajes orientados a objetos y no aplican estas dos herramientas y soy consciente de que Ingenieros en Informática salen a la calle todos los años con escasos conocimientos de las mismas.
Igual es ser un poco drástico, pero creo que si no dominas estas herramientas, no puede decirse que seas un programador, no al menos uno bueno. Tus programas funcionarán, serán incluso rápidos y pueden no tener errores, pero por hacer una analogía con un cuadro: solo te gustará a tí, no entrará en ningún marco, deslucirá la pared donde lo cuelgues, será un mal regalo para tu peor enemigo y si consigues que alguien lo acepte, acabará tirandolo y haciendolo de nuevo
Está claro que siempre existirán programadores de lenguajes procedurales, es la vida ;-).
Enviado por emillan en septiembre 13, 2006 a las 01:05 AM CEST #
Llevas mucha razón. Yo siempre pongo este ejemplo: todo el mundo sabe escribir, pero poca gente sabe escribir buenos libros; del mismo modo mucha gente hace programas, pero poca gente realmente hace buenos programas.
Cuando comencé a programar me dije, eh, ya sé la sintaxis del lenguaje, ya sé programar! Pronto me dí cuenta que es como saber la gramática de un lenguaje natural, por muy bien que la sepas si no tienes vocabulario y no sabes expresarte no puedes escribir un libro.
Enviado por gimenete en septiembre 13, 2006 a las 01:09 AM CEST #
Los buenos programadores estan muy poco valorados, de hecho menos valorados que los malos jefes.
Cuando programo intento hacer el codigo para que no lo tenga que mantener yo.
A mi me gusta crear proyectos nuevos, si me tengo que dedicar a mantener el codigo, bien porque no rinda o porque sea dificil de mantener o este mal documentado .... me lastra el mantenimiento de ese codigo, que ya no me aporta, todo lo que supone un reto esta hecho.
Como bien sabeis hay veces que no me explico lo suficientemente bien, imaginarse cuando escribo comentarios de codigo a toda velocidad, pero hago un gran esfuerzo en que cualquiera pueda trabajar con lo que hago.
Creo que el exito esta en que nadie te llame cuando dejas el proyecto.
Enviado por batch4j en septiembre 13, 2006 a las 08:51 AM CEST #
Claro, primero aprendes a picar código, luego aprendes a programar :-D.
Enviado por Ricardo en septiembre 13, 2006 a las 10:38 PM CEST #
Al final la programación es una mínima parte de la vida del software. Diseño, pruebas, mantenimiento,... llevan más tiempo. Pero es algo habitual que los programadores den por "acabado" algo cuando acaban el código y se despreocupen por el resto.
Enviado por Carlos Sanchez en septiembre 17, 2006 a las 09:45 AM CEST #