La verdad es que poner más presión sobre los programadores tiende a que escriban códigos más complejos. Sin embargo, los plazos no deberían llevarnos a escribir un código más complejo. En vez de decir que un plazo no te permite escribir código sencillo, podríamos enfocarlo de la siguiente manera: no soy un programador lo suficientemente rápido para hacer esto sencillo. Es decir, cuanto más rápido seas como programador, menos afectado quedará la calidad de tu código por los plazos.
Sobre el papel lo que acabo de escribir es muy fácil pero… ¿Cómo se convierte uno en un programador rápido? ¿Es un don mágico con el que nace en algunas personas? ¿Seremos más rápidos siendo más listos o inteligentes que otras personas?
No, no se trata de magia o de ningún don innato. De hecho, solo hay que seguir una simple norma, y si la sigues a rajatabla, serás capaz de solucionar el problema del todo:
Cada vez que pares y empieces a pensar , es que algo va mal.
Quizás esto que estoy escribiendo suena increíble, pero funciona realmente bien. Piénsalo un segundo, ¿cuando estás sentado enfrente de tu editor pero no estás introduciendo código de forma ágil es porque eres lento tecleando? Lo dudo, tener mucho que teclear rara vez es un problema de productividad para el desarrollador. Sin embargo, las pausas cuando no estás picando son las que te hacen ir lento y ¿qué es lo que están haciendo los desarrolladores durante esos parones? Se paran a pensar quizás sobre el problema, quizás sobre otras herramientas, quizás sobre los emails lo que sea pero cada vez que esto pasa indica que hay un problema.
Pensar por si mismo no es lo que está mal, pero si es señal de que puede haber algún otro problema y puede ser por varias razones:
Comprensión
La razón principal por la que un desarrollador se para a pensar mientras está programando es porque no entiende del todo una palabra o un símbolo.Esto me pasó a mí el otro día. Me estaba tomando 1000 horas escribir un servicio que era muy sencillo y me había parado a pensar sobre ello intentando dirimir como el código se tenía que comportar. Al final me di cuenta que no entendía una de las variables input de la función primaria conoce a nombre de su tipo pero jamás había ido a leer y entender la definición del tipo no entendí en realidad lo que significaba esa variable. Tan pronto como lo investigué, todo se volvió más comprensible y escribí ese servicio como un demonio (el juego de palabras es intencional).
Este ejemplo que acabo de dar te puede suceder de mil formas distintas , muchas personas se meten a programar en un lenguaje sin pararse a leer lo que(, ), [, ], {, }, +, *, y % son en realidad en ese lenguaje. Algunos desarrolladores no entiende cómo funciona un ordenador en realidad. Cuando entiendes algo en profundidad no tienes que pararte a pensar, y también es una motivación enorme de cara aprender ya que conociendo las reglas fundamentales del diseño de software eliminas muchos de esos momentos de pararse a pensar.
Así que si te das cuenta de que te paras a pensar, no intentes solucionar el problema en tu cabeza. Busca fuera de ti para ver qué es lo que no entendiste y luego vete a buscar información que te ayuda a entenderlo. Esto también es aplicable a cuestiones como del tipo: ¿este usuario leerá este texto alguna vez? Quizás no tengas un departamento de investigación de experiencia de usuario para entender o responder a esa cuestión, pero por lo menos puedes hacer un dibujo y enseñárselo a alguien y pedirle su opinión. Lo último que debes hacer es quedarte ahí parado pensando. Solo la acción lleva a pleno entendimiento de las cosas.
Dibuja
En otras ocasiones los programadores se paran a pensar porque no pueden albergar tantos conceptos en sus mentes a la vez. Muchas cosas están relacionadas entre sí de forma compleja y hay que pararse a pensarlo y repensarlo. En este caso es casi siempre más efectivo escribir o dibujar algo que pararse a pensarlo tanto. El objetivo es poder tener algo a lo que mirar desde fuera de tu cabeza. Esto es una forma de entendimiento pero es tan importante y especial que quería abrir este párrafo con este título: dibuja.¿Cómo empezar?
Muchas veces el problema es “No tengo ni idea con qué código empezar a escribir”. La solución más simple es empezar por el código que sabes a ciencia cierta que puedes escribir en ese momento. Empieza por la parte de problema que comprendes al 100% y escribe una solución para ello, -incluso si es solo una función o una clase poco importante-.A menudo, la parte más sencilla por la que empezar el código es el “core” de la aplicación. Por ejemplo, si fuese a escribir una app para YouTube, empezaría con el reproductor de vídeo. Hay que tomárselo como una actividad continua -escribe el código que realmente crea un producto primero, no importa lo pequeño o lo estúpido que te parezca el producto. Un reproductor de vídeo sin ningún otro interfaz de usuario es un producto que hace algo útil (reproducir vídeo), aunque no sea un producto terminado.
Si no tienes claro como escribir ese código “core” aún, pues entonces empieza por el código del que estás completamente seguro. Normalmente me doy cuenta que cuando una parte del problema se soluciona, , es mucho más fácil solucionar el resto. A veces el problema se soluciona yendo paso a paso: solucionas una parte, que hace que la solución del siguiente sea más obvia, y así hasta completar el programa. Si tienes entre manos una parte del programa que no te requiere pensar mucho, empieza por ese.
Saltarse un paso
Otra forma errónea de abordar los problemas es saltarse un paso en la secuencia de desarrollo normal. Por ejemplo, digamos que nuestro objeto Bicicleta depende de los objetos Ruedas, Pedales y el objeto Marco de la bicicleta. Si intentas escribir todo el objeto Bicicleta sin escribir los objetos Ruedas, Pedales o Marco vas a tener que pensar mucho sobre esas clases que no existen. Por otro lado, si escribes la clase Ruedas cuando no hay una clase Bicicleta, tendrás que pensar mucho sobre como la clase Bicicleta va a utilizar la clase Ruedas.La solución perfecta es implementar lo suficiente de la clase Bicicleta hasta llegar al punto en el que necesitas Ruedas. A continuación, escribir lo suficiente de la clase Ruedas hasta satisfacer la necesidad más inmediata de la clase Bicicleta. Luego volver a la clase Bicicleta y trabajar en ella hasta que necesites una de las piezas subyacentes. Igual que en el consejo anterior sobre ¿Cómo empezar?, encuentra la parte del problema que puedes solucionar sin pensar, y soluciona eso primero.
No te saltes pasos en el desarrollo de tu software y esperes ser productivo…
Problemas físicos
Si no he comido lo suficiente, tiendo a distraerme y empiezo a darle vueltas a todo porque estoy hambriento. No necesariamente son sobre mi estómago, pero no estaría en ese modo si estuviese bien. Estaría más centrado. Esto también puede pasar con el sueño, enfermedad, o cualquier tipo de problema corporal.Distracciones
Cuando un desarrollador se distrae por causas externas, como el ruido, se puede perder en medio de su proceso mental de programación. Aquí la solución es relativamente sencilla. Antes de que empieces a programar asegúrate de que estás en un entorno que no te va a distraer, o que no puedan surgir interrupciones. Algunas personas se encierran en la oficina, otros se ponen auriculares y algunos cuelgan un cartel de no molestar… Haz lo que quieras. Este tema es lo suficientemente importante como para ser consensuado con los compañeros y los jefes.A veces un desarrollador para a pensar porque se siente inseguro sobre sí mismos o sus decisiones. La solución a esto es similar a la de la sección Comprensión citada arriba. Si no estás seguro de algo, detente para aprender más hasta que estés listo para programarlo. Si te sientes inseguro en general como programador, igual es que tienes aún muchas cosas que aprender sobre los fundamentos de programación. Repasa tus lagunas y escríbelas en una lista y analiza una a una como mejorar. El proceso de aprendizaje va unido a la programación de forma intrínseca. Pero a medida que aprendas más y más, te volverás más rápido y perderás menos tiempo pensando en cosas improductivas.
0 Comentarios