Es increíble, pero si me pongo a programar de acuerdo a las buenas costumbres (TDD, DRY, métricas, clases pequeñas, código reutilizable, etc), el trabajo de programador se me hace aburrido y pesado. Pierdo más tiempo pensando cómo debería ser el código que en hacerlo.
Me divierto más cuando me lanzo a lo loco, sin pensar y programo/corrijo código según salen las cosas, veo rápidamente resultados y juego sobre ellos.
Pobre del que coja mi código después….
WTF?
Amen
lol
Como dice el dicho «Programo, luego pienso»
Es otro punto de vista que no tiene por que ser siempre «malo». Es como empezar con un bosquejo a mano alzada en lugar de dibujar con la regla milimetrica. Las reglas estan para romperlas (en el momento y contexto oportuno, y esa regla mejor no romperla)
ajajajajaaj weno yo programo y pienso , pienso y programo, piensao programando, programo pensando, lo haga como lo haga me divierto xk es algo ke me gusta
Pingback: de la red – 17/05/2010 « Tecnologías y su contexto
Me está pasando exactamente ahora. Iba a empezar una clase a saco i me he detenido para pensarla un poco antes de nada. Al final tengo un esbozo con tres clases relacionadas que tengo que programar. Lo que 5 minutos antes estaba ya empezando con ganas de repente me ha dado pereza, me he puesto a leer el reader y leo tu post…
Por otro lado será más satisfactorio cuando vea que las tres clases funcionando y comunicándose bien entre ellas en lugar del código ravioli que puede salir cuando empiezo una clase sin pensar.
LOL, hablas en serio? Echar por la borda a las metodologias de desarollo por no ser `divertidas’ me parece un tanto precipitado. Por otro lado, entiendo que algunas metodologias son muy `burocraticas’ e imponen practicas que obstruyen una programacion `fluida’, por asi decirlo. Yo digo: toma lo razonable de las metodologias y apegate a esas practicas, que a la larga si paga tener consistencia.
Hombre, no pretendo echar por tierra las metodologías ágiles, sólo indico lo que «siento» a veces al programar.
Si programo a lo loco, estoy más entretenido, codifico rápido, veo resultados rápido y juego con ellos. Eso sí, seguramente el código solo lo entienda yo durante el tiempo que lo tenga en la cabeza, no se podrá reutilizar en otra cosa, se cuelen más bugs y posiblemente no se pueda ampliar/modificar más adelante de forma fácil.
Si quieres hacer software «serio», es imprescindible cumplir ciertas normas (seguir cosas como TDD, cumplir métricas, no hacer clases ni métodos muy grandes o con muchas responsabilidades, comentar, etc), de forma que luego otros o tú mismo más adelante, puedan mantener, modificar o ampliar ese código. Eso no quita que mientras haces todo eso puedas sentirte, como es mi caso, «impedido» a hacer rápido el software. A veces las buenas prácticas se me antojan una burocracia aburrida (poner comentarios, hacer test, ver que falla, código mínimo para que pase, ver que el test pasa, refactorizar, ver que sigue pasando, hacer otro test …) que me hace concentrarme más en esa burocracia que en el programa.
Y desde luego, es mucho más divertido para un programador seguir una metodología ágil que tirarse dos meses con un word y un editor de UML escribiendo documentos.
Yo lo que veo es que seguir la metodología rápida y a lo loco puede ser más divertido al principio, pero si lo que quieres es hacer un software debes organizarte.
Lo primero es saber por dónde vas a empezar, para qué va a servir cada clase, etc. Cuando lo tengas planeado deberás ir por partes, con una pequeña clase main() que inicie el test. Ten en cuenta que la depuración ocupa el 70% del tiempo de desarrollo y si lo dejas para el final terminarás aburriéndote cuando todavía vayas por los errores de compilador. Además, si por lo que sea lo dejas, será más fácil para otro continuarlo si añades comentarios, documentación doxygen, etc.