En este artículo veremos una serie de teorías y consejos referentes del libro "The Pragmatic Programmer: From Journeyman to Master" de Andrew Hunt y David Thomas, que nos hará preguntarnos si de verdad somos buenos desarrolladores de software.
Comencemos por el principio: qué es un programador pragmático. Podríamos definirlo como aquel que se preocupa por escribir bien su código y evalua constantemente su trabajo proporcionando continuamente nuevas formas de hacer las cosas, evitando excusas y explicando de una manera clara lo que sí que se puede hacer. Su objetivo es encontrar las diferentes alternativas posibles ante un problema y no conformarse con un "no se puede hacer".
El libro "The Pragmatic Programmer" no es puramente técnico, si no que nos aporta consejos prácticos aplicables a nuestro día a día y nos ofrece un enfoque concreto de cómo debe de trabajar un desarrollador de software. En definitiva, proporciona una serie de principios y pautas de desarrollo de software de las que vamos veremos algunas a continuación.
Teoría de las ventanas rotas ("Broken window theory")
Esta teoría es muy conocida en el mundo de la criminología y la han llevado al mundo del software.
En criminología se dice que mantener los entornos urbanos en buenas condiciones puede provocar una disminución del vandalismo y reducir así las tasas de criminalidad. Por ejemplo, nos econtramos que en un edificio nuevo hay una ventana rota; si esta ventana no se repara, seguramente el edificio comience a tener cada vez más ventanas rotas y, en consecuencia, probablemente accedan al edificio y termine siendo ocupado o prendan fuego en su interior.
Aplicado al software, la teoría se resume en que arreglar los problemas cuando son pequeños puede evitar problemas mucho mayores. Si en tu proyecto has detectado código duplicado o algún pequeño bug que no es importante, pero que por falta de tiempo no lo has solucionado, es conveniente que lo resuelvas en un periodo corto de tiempo, porque sino seguramente se deje sin hacer y puede llegar a desencadenar problemas mayores en un futuro.
A raíz de ésto entra en juego el término de la entropía, y es que en el mundo del software es posible que sino se controla el problema, el proyecto tienda a la entropía, es decir, tender al desorden en un sistema. Como alternativa, si no puedes solucionar esos pequeños problemas detectados en el momento, márcalos, para que en cuanto se pueda, sean solucionados.
No olvides que una pequeña ventana rota, puede provocar en el futuro el caos en tu proyecto.
El gato se comió mi código fuente ("The cat ate my source code")
...o cómo perder el miedo a reconocer un error. Un profesional del software no debe de tener miedo en decir que ha habido un fallo en su código, o que no tiene un conocimiento de algo que quizá para algunos sea básico.
No hay que tener miedo en admitir la ignorancia o el error, y no hay que poner excusas de por qué ha fallado algo. En este mundo seremos eternamente unos principiantes y no habrá siempre un gato al que echarle la culpa.
Método de depuración del patito de goma ("Rubber duck - Debugging")
Es un término informal que consiste en explicar a un patito de goma qué hace nuestro código. Le diremos en detalle qué se hace línea a línea y así podremos comparar lo que supuestamente hace el código con lo que hace en realidad, con el objetivo de darnos cuenta en ese momento de cualquier incongruencia. Esta situación también se nos presenta al explicar a una persona que no entiende de desarrollo de software, un problema que tenemos y encontrar la solución en el mismo momento en el que le estamos contando nuestro problema.
Sopa de piedra ("Stone soup")
Está basada en una fábula que cuenta cómo unos viajeros llegaron a una aldea únicamente con una olla vacía. Cuando vieron a los aldeanos les preguntaron si podían darles algo de comer, pero todos ellos se negaron. Ante la negativa, los viajeros llenaron la olla de agua, echaron unas piedras y la pusieron al fuego en la plaza mayor de la aldea.
Un aldeano curioso por lo que estaban preparando, se acercó a preguntarles lo que estaban haciendo. Ellos le contestaron que estaban cocinando una deliciosa sopa, pero que les faltaba algún que otro ingrediente. El aldeano no tuvo inconveniente en prestarles algo de carne a cambio de tomar un poco de sopa al final. Así mismo, otro aldeano que pasaba por allí les preguntó también y los viajeros volvieron a mencionar su estupenda sopa, indicando igualemente que aún les falta algo, por lo que el aldeano les dio un poco de condimento a cambio de un plato de sopa cuando estuviera terminada. Más y más aldeanos fueron acercándose, añadiendo otros ingredientes y finalmente todos, aldeanos y viajeros, disfrutaron de una deliciosa y nutritiva olla de sopa.
Esta fábula trata sobre la cooperación frente a la escasez. Haz creer a tus compañeros que estás realizando algo muy bueno y te ayudarán a conseguirlo, ayúdales a creer que les estás dando la oportunidad de ser parte de tu éxito, un éxito común. Demuestrales que al trabajar en equipo y cooperar, el resultado y el éxito serán mucho mayores.
Teoría de las ranas hervidas ("Boiled frogs")
Imaginemos que metemos una rana en una cazuela con agua fría y calentamos el agua poco a poco. La rana no intentará escapar, sino que irá gastando energías en ajustar su temperatura corporal de manera gradual con la temperatura del agua. Cuando el agua llegue casi a su punto de ebullición, la rana se dará cuenta de que la situación es insoportable, pero estará tan débil de haber gastado energías en ajustar su temperatura que ya no podrá escapar... y al seguir aumentando la temperatura la rana morirá hervida sin poder hacer nada.
Sin embargo, si metemos la rana en una cazuela con el agua ya hirviendo la rana saltará y escapará enseguida porque es consciente del peligro.
Esta teoría pretende transmitir que cuando un cambio se introduce de forma lenta, éste escapa de nuestra conciencia, y nos impide preparar una respuesta o reacción por nuestra parte. Muestra que un deterioro, aunque sea pequeño y lento, pasa inadvertido hasta el punto de que cuando nos damos cuenta ya es demasiado tarde y puede tumbar un proyecto.
Aunque éstas son las teorías que más me llamaron la atención del libro, ppodréis encontrar algunas más en su interior igual de interesantes. Os animo a leerlo ya que no os dejará indiferentes.
.jpg)
