Programación de Aplicaciones

Detalles

Categoría de nivel principal o raíz: Informática

Categoría: Programación de Aplicaciones

Visto: 134

El Zen de python consta de una serie de reglas que pueden aplicarse para escribir correctamente en cualquier código para convertirlo en código Pythónico. Se pueden obtener ver en la definición de la PEP 20 https://www.python.org/dev/peps/pep-0020/ o ejecutando el siguiente código en cualquier intérprete:

>>> import this

"""

The Zen of Python, by Tim Peters

Beautiful is better than ugly.

Explicit is better than implicit. Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!

"""

Bonito es mejor que feo

Beautiful is better than ugly

Los adjetivos de bonito o feo suelen ser muy subjetivos aunque cuando se refiere a código, cualquiera con algunas decenas de miles de líneas escritas puede apreciar si un código es bonito o feo, aplicando las siguientes reglas o con reglas propias que da la experiencia.

# ejemplo de codigo feo

gatos=4;perros=6;patas=34;assert patas==(gatos*perros*4),'Número de patas dispar';

# ejemplo de codigo bonito

gatos = 4

perros = 6

patas = 34

assert patas == (gatos * 4) + (perros * 4), 'Número de patas dispar'

Explícito es mejor que implícito

Explicit is better than implicit

Cuando un código es explícito, no requiere que el lector tenga que intuir o saber de antemano algún elemento implícito del sistema, haciendo que la legibilidad mejore considerablemente.

A veces convertir un código implícito en explícito es tan simple como añadir algunas variables intermedias con nombres apropiados, o no concatenar funciones o simplemente no hacer uso de variables globales sino pasar las variables usando argumentos.

# version implicita

def metros_a_pulgadas_dobles(metros):

   return metros * 39.3701 * 2

# version explicita

def metros_a_pulgadas_dobles(metros):

   pulgadas_por_metro = 39.3701

   multi_doble = 2

   return metros * pulgada_por_metro * multi_doble

Simple es mejor que complejo

Simple is better than complex.

Un sistema complejo se define como un sistema compuesto de muchas partes independientes conectadas entre sí, pero que no tienen relaciones ocultas entre los componentes.

Si el sistema está correctamente implementado, cada parte independiente será simple si se estudia de forma aislada, por lo que, el estudio del sistema completo se podría simplificar en el estudio de cada parte simple.

Complejo es mejor que complicado

Complex is better than complicated.

Sin embargo, un sistema complicado, se compone de elementos simples que no son independientes entre sí, sino que el sistema conoce de alguna lógica extra que convierte el sistema en complicado.

# version compleja interconectada

LIMITE_SUPERIOR = 32

LIMITE_INFERIOR = 3

POSICION = 1

def evaluar_cambio(valor):

   prev_pos = POSICION

   if valor > (LIMITE_SUPERIOR + LIMITE_INFERIOR * 5 / 4):

      nueva_pos = 1

   elif valor < (LIMITE_INFERIOR + LIMITE_INFERIOR * 2 / 4):

      nueva_pos = 0

   return prev_pos != nueva_pos

# version simple

def evaluar_cambio(valor, valor_actual):

   debe_cambiar = False

   if valor_actual == 1:

      debe_cambiar = debe_apagar(valor)

   elif valor_actual == 0:

      debe_cambiar = debe_encender(valor)

   return debe_cambiar

 

def debe_encender(valor, valor_superior=LIMITE_SUPERIOR, valor_inferior=LIMITE_INFERIOR):

   limite = valor_superior + valor_inferior * 5 / 4

   return valor > limite

 

def debe_apagar(valor, valor_superior=LIMITE_SUPERIOR, valor_inferior=LIMITE_INFERIOR):

   limite = valor_superior + valor_inferior * 2 / 4

   return valor < limite

Por tanto por orden de preferencia sería (> == mejor que):

Simple > Complejo > Complicado

Plano es mejor que anidado

Flat is better than nested.

La capacidad de retención y comprensión de cada desarrollador es limitada, por tanto si se anidan las sentencias en vez de mantenerlas lo más planas posibles, se suele mermar la capacidad cansando al lector del código.

Una forma de aplanar un código anidado es usando funciones planas y otra podría ser usando listas por comprensión, aunque la segunda opción suele quedar muy densa fácilmente.

# version anidada

valores_ajustados = []

for s in sistemas:

   sensores = sensores_sistema(s)

   for sensor in sensores:

      valores_s = valores_sensor(sensor)

         for val in valores_s:

            valores_ajustados.append(ajustar_valor(val))

# version aplanada pero densa

valores_ajustados = [ajustar_valor(val) for val in valores_sensor(sensor) for sensor in sensores_sistema(s) for s in sistemas]

# version en funciones simples, testeables y escalables

def valores_del_sistema_ajustados(sistemas):

   for sistema in sistemas:

      yield valores_sistema(sistema)

 

def valores_sistema(sistema):

   for sensores in sistema:

      yield valores_sensores(sensores)

 

def valores_sensores(sensores):

   for sensor in sensores:

      yield valores_sensor_ajustados(sensor)

 

def valores_sensor_ajustados(sensor):

   for valor in valores_sensor(sensor):

      yield ajustar_valor(valor)

Disperso es mejor que denso

Sparse is better than dense

Cuando se aumenta la densidad del código haciendo en pocas líneas muchas operaciones se puede hacer perder el foco del lector, por tanto es muy recomendable añadir espacios entre bloques lógicos.

# version densa

print(','.join(map(str, [x ** 2 for x in range(5)])))

# version dispersa

a = [x ** 2 for x in range(5)]

b = map(str, a)

c = ','.join(b)

print(c)

La legibilidad importa

Readability counts.

El código se escribe una vez pero se leen cientos de veces, por lo tanto es muy importante prestar especial atención a mejorar la legibilidad lo más posible, eligiendo los mejores nombres, separando funciones convenientemente o clases cuando son necesarios.

Existen muchas técnicas para mejorarlo e incluso libros sobre este tema como los principios SOLID o los libros de Clean Code que son totalmente recomendables.

# version mas legible

lista_de_cuadrados = [x ** 2 for x in range(5)]

cadenas_de_cuadrados = map(str, lista_de_cuadrados)

cuadrados_formateados = ','.join(cadenas_de_cuadrados)

print(cuadrados_formateados)

Los casos especiales no son lo suficientemente especiales para romper reglas

Special cases aren’t special enough to break the rules

Cuando se definen unas reglas hay que cumplirlas, de lo contrario no tienen razón de existir. Los casos «especiales» son la excusa que se pone para romper las reglas pero realmente son sinónimo de «conozco las reglas pero en vez de cambiar el código para cumplirarlas, prefiero romperlas», lo que debería de ser inadmisible dado que a la larga (conlleva al desastre).

Practicidad vence a la pureza

Although practicality beats purity

En multitud de ocasiones nos encontramos en la situación de querer escribir el código más puro, que sigue todos los patrones de diseño «a raja tabla» y que conlleva a que los sistemas sean demasiado genéricos o que se tarden una eternidad en desarrollar, es muy importante encontrar un equilibrio entre lo que es práctico (e importante) y la pureza.

Los errores nunca deberían de ocurrir silenciosamente

Errors should never pass silently.

Cuando se trabaja bajo presión y se encuentran errores se tienden a ocultar o a tomar medidas demasiado drásticas como la siguiente:

try:

   codigo_erroneo()

except Exception:

   pass

O lo que es lo mismo «se que este código falla de vez en cuando, cuando lo haga sigue sin más», esto no es solo un antipatrón sino que demuestra apatía y una desgana de hacer código profesionalmente. Si hay un error debe ser visible para poder ser arreglado.

A no ser que se silencien explícitamente

Unless explicitly silenced

Existen excepciones al caso anterior que se dan cuando se ha estudiado la situación, se conoce el error y explícitamente se silencia (o se actúa en consecuencia).

Si el error que se ha detectado es un ValueError (por ejemplo) pero se sabe que no es problemático, se debe de manejar adecuadamente, incluso pudiendo ser silenciado.

try:

   codigo_erroneo()

except ValueError:

   logger.debug('Value Error manejado correctamente')

En el caso de ambigüedad, rechaza la tentación de adivinar

In the face of ambiguity, refuse the temptation to guess

Este concepto aplica a muchos ámbitos del desarrollo, es mucho mejor tener claro qué se está construyendo y poder crear tests, que exactamente definan y comprueben el buen comportamiento del sistema, eliminando cualquier ambigüedad.

Debería de haber una – y preferiblemente sólo una – forma obvia de hacerlo

There should be one– and preferably only one –obvious way to do it

Si la forma de implementar el problema no parece obvia, quizás no sea la más correcta y haya que seguir pensando en otra opción.

Aunque la forma no parezca obvia a la primera, a no ser que seas Holandés

Although that way may not be obvious at first unless you’re Dutch

Es normal que no aparezca la forma obvia la primera vez que piensa la solución, por lo que puede requerir de un método iterativo.

El guiño que se añade en esta regla sobre los holandeses hace referencia la nacionalidad del Dictador Benevolente y creador de Python Guido van Rossum.

Ahora es mejor que nunca

Now is better than never

En el desarrollo de software siempre hay tareas que realizar y si no se priorizan las tareas importantes para hacerlas cuando salen los problemas, estos pueden alargarse en el tiempo hasta no hacerlas nunca.

Aunque nunca es a menudo mejor que ahora mismo

Although never is often better than right now

Quiere decir que no hay que forzar la realización de tareas tanto como para dejar lo que se está desarrollando actualmente, para desarrollar una tarea nueva, evitando así el cambio de contexto.

Si la implementación es difícil de explicar, es una mala idea

If the implementation is hard to explain, it’s a bad idea

Esta regla suele aplicarse en muchos ámbitos en general, dado que si no eres capaz de explicar la idea de forma simple es que no la visualizas de forma simple por lo que quizás sea necesario consensuar la solución hasta tenerla clara.

Si la implementación es fácil de explicar, es una buena idea

If the implementation is easy to explain, it may be a good idea

Cuando se puede explicar la idea a cualquier otra persona (o patito de goma) suele ser síntoma de tener los conceptos claros y de ser una solución genial.

Los espacios de nombres son una buena idea, ¡usemos más de ellos!

Namespaces are one honking great idea — let’s do more of those!

Los espacios de nombres en Python se pueden crear de múltiples formas y ayudan mucho a desacoplar código y de hacerlo más modular, por lo que se recomienda usarlos más.

Detalles

Categoría de nivel principal o raíz: Informática

Categoría: Programación de Aplicaciones

Visto: 145

El Tao de la Programación

por Geoffrey James

LIBRO PRIMERO: EL VACÍO SILENCIOSO

Así habló el maestro programador:
“Cuando hayas aprendido a extraer el código del error desde un trap frame,
será la hora de marcharte”

1.1

Algo misterioso se forma, nace en el vacío silencioso. Esperando solo e inmóvil, al mismo tiempo detenido y en movimiento constante. Es la fuente de todos los programas. Yo no sé su nombre, así que lo llamaré el Tao de la Programación.

Si el Tao es grandioso, entonces el sistema operativo es grandioso. Si el sistema operativo es grandioso, entonces el compilador es grandioso. Si el compilador es grandioso, entonces la aplicación es grandiosa. El usuario está complacido y hay armonía en el mundo.

El Tao de la Programación fluye lejos y regresa con el viento de la mañana.

1.2

El Tao engendró al lenguaje máquina. El lenguaje máquina dio vida al ensamblador. El ensamblador se la dio al compilador. Ahora hay diez mil lenguajes.

Cada lenguaje tiene su propósito, aunque sea humilde. Cada lenguaje expresa el Yin y el Yang del software. Cada lenguaje tiene su lugar dentro del Tao.

Pero no programes en COBOL si puedes evitarlo.

1.3

En el principio era el Tao. El Tao engendró el Espacio y Tiempo. Por tanto Espacio y Tiempo son el Yin y el Yang de la programación.

Los programadores que no comprenden el Tao siempre se quedan sin tiempo y espacio para sus programas. Los programadores que comprenden el Tao siempre tienen tiempo y espacio suficiente para lograr sus objetivos.

¿Cómo podría ser de otra manera?

1.4

Al programador sabio le hablan del Tao y lo sigue. Al programador medio le hablan del Tao y lo busca. El programador necio se ríe cuando le hablan del Tao.

Si no fuera por la risa, no existiría el Tao.
Los sonidos más altos son los más difíciles de oír.
Avanzar es un camino para la retirada.
El gran talento se muestra tarde en la vida.
Incluso un programa perfecto todavía tiene errores.

LIBRO SEGUNDO: LOS MAESTROS ANCIANOS

Así habló el maestro programador:
“Después de tres días sin programar, la vida pierde sentido”

2.1

Los programadores de la antigüedad eran misteriosos y profundos. No podemos comprender sus pensamientos, así que todo lo que hacemos es describir su apariencia.

Consciente, cual zorro cruzando el agua. Alerta, como un general en el campo de batalla. Amable, como una anfitriona saludando a sus invitados. Simple, como bloques de madera sin tallar. Opaco, como negras piscinas en cuevas oscuras.

¿Quién puede contar los secretos de sus corazones y mentes?

La respuesta sólo existe en el Tao.

2.2

El Gran Maestro Turing una vez soñó que era una máquina. Cuando se despertó, exclamó:

”¡No sé si soy Turing soñando que soy una máquina, o una máquina soñando que soy Turing!'”

2.3

Un programador de una gran compañía fue a una conferencia de software y luego regresó para informar a su jefe, diciendo: “¿Qué clase de programadores trabajan en otras empresas? Se comportan mal y no se preocupan por las apariencias. Su cabello era largo y despeinado y sus ropas arrugadas y viejas. Destrozaron nuestra hospitalidad e hicieron ruidos groseros durante mi presentación''.

El director dijo: “Nunca debí haberte enviado a la conferencia. Esos programadores viven más allá del mundo físico. Consideran que la vida es absurda, una coincidencia accidental. Ellos van y vienen sin conocer limitaciones. Sin cuidado, ellos viven sólo para sus programas. ¿Por qué deberían preocuparse por las convenciones sociales?

Ellos viven dentro del Tao”.

2.4

El discípulo preguntó al Maestro: “Este es un programador que nunca diseña, documenta o prueba sus programas. Sin embargo, todos los que lo conocen lo consideran uno de los mejores programadores del mundo. ¿Por qué es esto?”

El Maestro responde: “Ese programador ha alcanzado la maestría del Tao. Ha ido más allá de la necesidad de un diseño; no se enoja cuando el sistema se cae, pero acepta al universo sin preocupación. Ha ido más allá de la necesidad de documentación; no le importa si alguien más ve su código. Ha ido más allá de la necesidad de pruebas; cada uno de sus programas son perfectos en sí mismos, serenos y elegantes, su propósito es auto-evidente. Realmente, él ha penetrado en el misterio del Tao''.

LIBRO TERCERO: DISEÑO

Así habló el maestro programador:
“Cuando el programa está siendo testeado,
es demasiado tarde para hacer hacer cambios de diseño”

3.1

Hubo una vez un hombre que fue a una feria de informática. Cada día, al entrar le decía al guarda de la puerta: “soy un gran ladrón reconocido por mis hazañas de robo. Estás prevenido de que esta feria no escapará sin ser saqueada”.

Estas palabras incomodaron mucho al guardia, porque dentro había millones de dólares en equipamiento informático, así que observó cuidadosamente al hombre. sin embargo, el hombre simplemente vagaba de stand en stand, murmurando para sí.

Cuando el hombre se iba, el guardia se lo llevó aparte y buscó entre sus ropas, pero nada fue encontrado.

Al siguiente día de la feria, el hombre regresó y regañó al guardia diciendo: "Ayer escapé con un gran botín, pero hoy será todavía mejor". Así que el guardia lo observó incluso más de cerca, pero sin resultados.

En el último día de la feria, el guardia no pudo resistir más su curiosidad. "Señor Ladrón", dijo, "estoy tan confuso que no puedo vivir en paz. Por favor ilumíneme. ¿Qué es lo que está robando?"

El hombre sonrió. "Estoy robando ideas", dijo.

3.2

Había una vez un maestro programador que escribía programas no estructurados. Un programador novicio, buscando imitarlo, también comenzó a escribir programas no estructurados. Cuando el novicio le pidió al maestro que evaluara su progreso, el maestro lo criticó por escribir programas no estructurados, diciendo:

“Lo que es apropiado para el maestro no es apropiado para los principiantes. Debes entender el Tao antes de trascender la estructura”.

3.3

Hubo una vez un maestro programador en la corte del señor de Wu. El señor preguntó al programador: “¿qué es más fácil de diseñar, un paquete de contabilidad o un sistema operativo?”.

“Un sistema operativo”, respondió el programador.

El señor lanzó una exclamación de incredulidad. “Sin duda, un paquete de contabilidad es trivial al lado de la complejidad de un sistema operativo”, dijo.

“No es así”, dijo el programador, “cuando se diseña un paquete de contabilidad, el programador actúa  como mediador entre personas con distintas ideas: cómo debe operar, cómo deben aparecer sus informes, y cómo se deben cumplir las leyes de impuestos". Por el contrario, un sistema operativo no está limitado por las apariencias externas. En el diseño de un sistema operativo, el programador busca la armonía más simple entre máquina e ideas. Esta es la razón por la que el sistema operativo es más fácil de diseñar”.

El señor de Wu asintió y sonrió. “Eso está bien, pero, ¿qué es más fácil de depurar?”.

El programador no respondió.

3.4

Un gerente fue al maestro programador y le mostró el documento de requisitos para una nueva aplicación. El gerente preguntó al maestro: “¿Cuánto tiempo se tarda en diseñar este sistema si le asigno cinco programadores?”.

“Tomará un año”, dijo el maestro rápidamente.

“¡Pero necesitamos este sistema inmediatamente o incluso antes! ¿Cuánto se tarda si le asigno diez programadores?”.

El maestro programador frunció el ceño. “En este caso, se tardará dos años”.

“¿Y si le asigno cien programadores?”

El maestro programador se encogió de hombros. “Entonces el diseño no se completará jamás”, dijo.

LIBRO CUARTO: CODIFICACIÓN

Así habló el maestro programador:
“Un programa bien escrito es su propio cielo;
un programa mal escrito, su propio infierno”

4.1

Un programa debe ser ligero y ágil, sus subrutinas conectadas como las perlas de un collar. El espíritu e intencionalidad del programa debe mantenerse en todo momento. No debe ser ni mucho ni poco, ni bucles innecesarios ni variables sin utilidad, ni ausencia de estructura ni rigidez excesiva.

Un programa debe seguir la “Ley de la menor sorpresa”. ¿Qué es esta Ley? Simplemente que el programa debe responder siempre de la forma que menos sorprenda al usuario.

Un programa, no importa cuán complejo sea, debería actuar como una sola unidad. El programa debe ser dirigido por la lógica interna en lugar de por las apariencias externas.

Si el programa falla en estos requisitos, se llegará a un estado de desorden y confusión. La única manera de corregir esto es reescribiendo el programa.

4.2

Un discípulo preguntó al maestro: “Tengo un programa que a veces funciona y veces aborta. He seguido las reglas de la programación, y estoy totalmente desconcertado. ¿Cuál es la razón?”.

El maestro respondió: “Estás confuso porque no entiendes el Tao. Sólo un necio espera un comportamiento racional de sus semejantes humanos. ¿Por qué ibas a esperarlo de una máquina que los humanos han construido? Los ordenadores simulan determinismo; sólo el Tao es perfecto.

Las reglas de la programación son transitorias; sólo el Tao es eterno. Por tanto, debes contemplar el Tao antes de ser iluminado.”

“Pero, ¿cómo sabré que he sido iluminado?”, preguntó el discípulo.“Tu programa funcionará correctamente”, respondió el maestro.

4.3

Un maestro estaba explicando la naturaleza del Tao a uno de sus discípulos. “El Tao está presente en todo el software, independientemente de su insignificancia”, dijo el maestro.

“¿Está el Tao en una calculadora de bolsillo?”, preguntó el novicio.

“Está”, fue la respuesta.

“¿Está el Tao en un videojuego?”, continuó el discípulo.

“Incluso en un videojuego”, dijo el maestro.

“¿Y está en el sistema operativo de un ordenador personal?

”El maestro tosió y cambió levemente de posición. “La lección ha acabado por hoy”, dijo.

4.4

El programador del Príncipe Wang estaba codificando software. Sus dedos bailaban sobre el teclado. El programa compiló sin errores y se ejecutó cual ligera brisa.

“¡Excelente!”, exclamó el Príncipe, “¡Tu técnica es infalible!”.

“¿Técnica?”, dijo el programador girándose desde su terminal, “¡Lo que yo sigo es el Tao más allá de toda técnica! Cuando empecé a programar, veía ante mí el problema completo como un todo.

Después de tres años ya no veía ese bloque: empecé a usar subrutinas. Pero ahora no veo nada. Mi ser existe en un vacío sin forma. Mis sentidos están ociosos. Mi espíritu, libre para trabajar sin un plan, sigue su propio instinto. En resumen, mi programa se escribe a sí mismo. Es cierto que a veces hay problemas complejos. Los veo acercarse, me detengo, observo en silencio. Entonces cambio una única línea de código y las dificultades se desvanecen como una voluta de humo. Compilo mi programa. Me quedo quieto y dejo que el gozo del trabajo llene mi ser. Cierro los ojos un momento, y entonces cierro mi sesión”.

El Príncipe Wang dijo “Ojalá todos mis programadores fueran tan sabios”.

LIBRO QUINTO: MANTENIMIENTO

Así habló el maestro programador:
“Incluso un programa de tres líneas algún día tendrá que se mantenido”

5.1

Una puerta bien usada no necesita aceite en sus bisagras.
Un río que fluye veloz no se estanca.
Ni el sonido ni los pensamientos pueden viajar a través del vacío.
El software se pudre si no se utiliza.
Son grandes misterios.

5.2

Un gerente preguntó a un programador que cuánto tiempo le llevaría terminar el programa en el que trabajaba. “Se acabará mañana”, respondió rápidamente el programador.

“Creo que no estás siendo realista”, dijo el gerente, “De verdad, ¿cuánto tiempo tardará?”.

El programador pensó un instante. “Tengo algunas características que me gustaría añadirle. Me llevará al menos dos semanas”, dijo finalmente.

“Incluso eso es demasiado esperar”, insistió el gerente, “me basta si simplemente me avisas cuando el programa esté completo”.

El programador asintió.

Varios años más tarde, el gerente se retiró. De camino hacia su almuerzo de jubilación descubrió al programador dormido sobre su terminal. Había estado programando toda la noche.

5.3

Un programador novicio fue una vez asignado a la codificación de un sencillo paquete financiero.

El novicio trabajó furiosamente muchos días, pero cuando su maestro revisó su programa descubrió que contenía un editor de pantallas, un conjunto de rutinas gráficas generales, y una interfaz de inteligencia artificial, pero ni la más mínima mención de nada financiero.

Cuando el maestro le preguntó acerca de ello, el novicio se indignó. “No seas tan impaciente”, dijo, “Incluiré los temas financieros al final”.

5.4

¿Acaso un buen agricultor descuidaría un cultivo que ha plantado?
¿Acaso descuidaría un buen profesor incluso al estudiante más humilde?
¿Acaso un buen padre permitiría que uno de sus hijos murieran de hambre?
¿Acaso un buen programador rechazaría mantener su propio código?

LIBRO SEXTO: GESTIÓN

Así habló el maestro programador:
“Sean los programadores muchos y gestores pocos;
todos ellos serán entonces productivos”

6.1

Cuando los gestores tienen reuniones infinitas, los programadores escriben juegos. Cuando los financieros hablan de beneficios cuatrimestrales, el presupuesto de desarrollo está a punto de ser recortado. Cuando los científicos hablan de cielo azul, las nubes están a punto de aparecer.

Ciertamente, esto no es el Tao de la Programación.

Cuando los gestores se comprometen, los juegos son ignorados. Cuando los financieros hacen planes a largo plazo, la armonía y el orden son restaurados. Cuando los científicos se centran en los problemas cercanos, los problemas estarán a punto de resolverse.

Ciertamente, esto es el Tao de la Programación.

6.2

¿Por qué los programadores son improductivos?
Porque pierden su tiempo en reuniones.

¿Por qué los programadores son rebeldes?
Porque la gestión interfiere mucho.

¿Por qué los programadores reniegan unos de otros?
Porque están quemados.

Después de haber trabajado para un mal gestor, ya no valoran sus empleos.

6.3

Un gerente estaba a punto de ser despedido, pero un programador que trabajaba para él inventó un nuevo programa que se hizo popular y se vendió bien. Como consecuencia, el gerente conservó su empleo.

El gerente intentó darle al programador una bonificación, pero éste se negó diciendo “yo escribí el programa porque pensé que era un concepto interesante, por lo que no espero ninguna recompensa”.

Al oír esto, el gerente comentó: “Este programador, a pesar de su baja autoestima, entiende bien los deberes de un empleado. ¡Vamos a promocionarlo hacia la posición de consultor de gestión!”.

Pero cuando se le dijo esto, el programador lo rechazó una vez más diciendo: “Vivo para la programación. Si fuera ascendido no haría más que desperdiciar el tiempo de todos. ¿Me puedo ir? Tengo un programa en el que trabajar”.

6.4

Un gerente se dirigió a sus programadores: “En cuanto a sus horas de trabajo, van a tener que venir desde las nueve de la mañana hasta las cinco de la tarde”. En ese momento todos se enfadaron y muchos de ellos renunciaron en el acto.

Así que el gerente dijo: “Bien, pues en ese caso podéis establecer vuestros propios horarios de trabajo, siempre que terminéis los proyectos a tiempo”. Los programadores, ahora satisfechos, comenzaron a llegar a mediodía y trabajar hasta altas horas de la madrugada.

LIBRO SÉPTIMO: CONOCIMIENTO CORPORATIVO

Así habló el maestro programador:
“Puedes mostrar un programa a un ejecutivo de la empresa,
pero no puedes hacerlo experto en informática”

7.1

Un discípulo preguntó al maestro: “En el Este hay una gran estructura con forma de árbol que los hombres llaman sede corporativa. Está excesivamente inflada con vicepresidentes y contables. Generan una gran cantidad de notas diciendo ‘ve aquí’ o ‘ve allá’ y nadie sabe lo que significa. Cada año se colocan nuevos nombres en las ramas, todo en vano. ¿Cómo puede existir una entidad tan innatural?”.

El maestro respondió: “Percibes esta inmensa estructura y te perturba que no tenga un propósito racional. ¿No puedes encontrar entretenimiento con sus giros sin fin? ¿No disfrutas de la facilidad de programar sin problemas refugiado bajo sus ramas? ¿Por qué te molesta su inutilidad?”.

7.2

En el Este hay un tiburón que es mayor que todos los otros peces. Se transforma en ave cuyas alas son como nubes llenando el cielo. Cuando es ave, se mueve por toda la tierra y trae un mensaje desde la sede corporativa. Este mensaje cae entre los programadores como una gaviota dejando su huella en la playa. Entonces el pájaro remonta el vuelo y, con el cielo azul a sus espaldas, vuelve a casa.

El programador novicio mira sorprendido el ave porque no lo entiende. El programador intermedio teme la llegada del ave porque teme su mensaje.

El maestro programador continúa trabajando en su terminal, no sabe que el ave ha llegado y se ha marchado.

7.3

El Mago de la Torre de Marfil llevó su último invento para que lo examinara el maestro programador. El Mago acarreó una gran caja negra a la oficina del maestro, mientras éste esperaba en silencio.

“Esto es una estación de trabajo de propósito general integrada y distribuida”, comenzó el Mago, “diseñada ergonómicamente con un sistema operativo propietario, lenguajes de sexta generación y múltiples interfaces de usuario con tecnología de punta. Construirlo costó a mis asistentes varios cientos de años/hombre . ¿No es sorprendente?”.

El maestro alzó sus cejas ligeramente. “Sin duda es increíble”, dijo.“La sede corporativa ha ordenado”, continuó el Mago, “que todos usen esta estación de trabajo como plataforma para los nuevos programas. ¿Está de acuerdo con esto?”.

“Ciertamente”, respondió el maestro, “Lo transportaré al centro de datos inmediatamente”. Y el Mago retornó complacido a su torre.

Varios días después, un novicio vagaba por la oficina del maestro programador y le dijo: “No puedo encontrar el listado de mi nuevo programa. ¿Sabes dónde puede estar?”.

“Sí”, respondió el maestro, “los listados están apilados sobre la plataforma del centro de datos”.

7.4

El maestro programador se mueve de un programa a otro sin miedo. Ningún cambio en los gestores puede dañarle. No será despedido, ni siquiera aunque el proyecto en el que trabaja sea cancelado. ¿Por qué es esto?

El Tao está en él.

LIBRO OCTAVO: HARDWARE Y SOFTWARE

Así habló el maestro programador:
“Sin el viento, el pasto no se mueve. 
Sin software, el hardware es inútil”

8.1

Un discípulo preguntó al maestro: “Percibo que una compañía de ordenadores es mucho mayor que todas las demás. Se eleva por encima de su competencia como un gigante entre enanos. Cualquiera de sus divisiones podría abarcar todo el negocio. ¿Por qué es esto así?”.

El maestro respondió: “¿Por qué haces preguntas tan necias? Esa compañía es así de grande porque es grande. Si sólo fabricara hardware nadie lo compraría. Si sólo hiciera software, nadie lo usaría. Si sólo mantuviera sistemas, la gente los trataría como a sirvientes. Pero al combinar todas esas cosas, la gente piensa que son dioses. Al no buscar la confrontación conquista sin esfuerzo”.

8.2

Un maestro programador pasó un día junto a un novicio. El maestro notó la preocupación del novicio con un juego en un dispositivo portátil. “Disculpe”, dijo, “¿me permite examinarlo?”.

El novicio atendió y pasó el dispositivo al maestro. “Veo que el aparato afirma tener tres niveles de juego: fácil, intermedio y difícil”, dijo el maestro. “Pero aún cada dispositivo tiene otro nivel de juego, donde el apartado no busca conquistar al humano, ni ser conquistado por el humano”.

“Ruego, gran maestro”, imploró el novicio, “¿cómo hace uno para encontrar esa misteriosa configuración?”.

El maestro arrojó el dispositivo al suelo y lo aplastó bajo su pie. Y de pronto, el novicio fue iluminado.

8.3

Había una vez un programador que trabajaba con microordenadores. “Mira lo bien que estoy aquí”, dijo a un programador de mainframes que lo fue a visitar. “Tengo mi propio sistema operativo y dispositivo de almacenamiento de archivos. No tengo que compartir mis recursos con nadie. El software es consistente y fácil de usar. ¿Por qué no dejas tu trabajo actual y te vienes conmigo?”

Entonces, el programador de mainframes comenzó a describir su sistema a su amigo, diciendo: “El mainframe está sentado como un antiguo sabio meditando en el centro de datos. Sus discos se encuentran de extremo a extremo como un gran océano de maquinaria. El software es tan polifacético como un diamante, y enrevesado como una selva virgen. Los programas, cada uno único, se mueven a través del sistema como un río de corriente rápida. Por eso estoy feliz donde estoy”.

El programador de microordenadores, al oír esto, se quedó en silencio. Pero los dos programadores siguieron siendo amigos hasta el final de sus días.

8.4

Hardware y Software se encontraron en el camino hacia Changtse. Software dijo: “Tú eres Yin y yo soy Yang. Si viajamos juntos nos haremos famosos y ganaremos vastas sumas de dinero”. Y así, el equipo se unió, pensando que conquistarían el mundo.

Actualmente se encontraron con Firmware, que estaba vestido con harapos y cojeaba apoyado en un palo espinoso. Firmware les dijo: “El Tao está más allá del Yin y Yang. Es silencioso y quieto como un estanque de agua. No busca la fama, por tanto, nadie sabe de su presencia. No busca fortuna, porque es completo en sí mismo. Existe más allá del espacio y del tiempo”.

Software y Hardware, avergonzados, regresaron a sus hogares.

LIBRO NOVENO: EPÍLOGO

Así habló el maestro programador:
“Es hora de que partas”