Ética (y estética) de la programación

Cada programador tiene un estilo propio para realizar su trabajo. Digamos que cada uno es como es y su producto lo mismo. Hay un estilo para cada programador. Unos utilizan el while otros el for, otros estructuras irreconocibles, y a otros les encantan las funciones recursivas y así cada cual es cada cual. Ahora bien, podríamos dividir los programadores en dos grupos excluyentes: aquellos que tiene en cuenta el prójimo y los que no. Los que creen que están solos en el mundo y los que no. Los que programan para ellos y los que lo hacen para todos. Los egoístas suelen escribir sentencias complejas que solo ellos entienden y que no suelen comentar (o poco y en un idioma no materno).En una línea son capaces de poner varias sentencias. He visto personalmente como de varias sentencias separadas y bien comentadas, el egoísta de turno las ha puesto en una sola línea. ¡Ay que complejo!, Ay para entender esto hay que subir un escalafón (en la idiotez). Los egoístas son aquellos que empiezan a programar y se les nubla la vista hasta que no acaban todo, ni comentan, ni prueban, solo programan como posesos e diotas. Y así salen algoritmos idiotas y mudos, muditos. Para que el próximo idiota diga ¡Uy esto es un churro! Hay que empezar de nuevo. Y venga otra chapuza mudita. Conozco excelentes programadores que saben solucionar problemas complejos con algoritmos que pueden se complejos pero con un aspecto de absoluta apertura al lector experto. Se te saltan las lagrimas de felicidad ver como puedes llegar a entender un método complejo con solo leer los comentarios y ver el código. Y esto es lo difícil, lo fácil es ser egoísta y vanidoso. Por tanto, recomiendo programar para los demás, en pro de le comprensión lectora y del posterior mantenimiento y también por coherencia estética (lo simple y expresivo es bello) y ética (pensar en los demás).

servido por rafikis sin comentarios compártelo

Feliz Release N.M

Recientemente recibí un email de un compañero del trabajo en el que nos comunicaba su cumpleaños y nos remitía a las correspondientes galletas cuetara de turno. Lo que me llamó la atención es que trataba su cumpleaños como una Release. En informática una release es el lanzamiento de una nueva versión de una aplicación. Por ejemplo, Firefox versión 1.5.0.1. Una Release suele contener cambios significativos en cuanto a la Release anterior. Para el compañero de trabajo cada vez que alguien cumplía años significaba una Release,, una nueva versión de la Persona. Sería muy interesante que así fuera. Cada año, sacaríamos a la luz pública una nueva versión de nosotros con todos los defectos arreglados y con nuevas mejoras. En definitiva, deberíamos realizar un proceso iterativo a la manera del Proceso Unificado cada año de nuestra vida. Las fases serían las siguientes:

1) Fase de toma de requisitos y/o defectos: A partir del día siguiente del cumpleaños ya deberíamos preguntar a los usuarios por posibles mejoras o modificaciones que crean oportunas. Para ello podemos optar por la comunicación oral: ¿Tu crees que yo soy Idiota? ¿Tal vez me falta suspicacia? ¿Te aburrro? ¿Qué tal mi potencia sexual? También engloba la recogida de defectos o bugs del tipo –Creía que habías cambiado pero sigues tan gilipollas como siempre. O ¿Es que nunca cambiaras? O Macho, ¡que ya tienes una edad!. Esta fase debería durar todo el año, sin embargo es importante recopilar requisitos y defectos durante los 3/4 primeros meses.

2) Fase de Análisis y Diseño. Una vez tenemos la lista de requisitos funcionales, hemos de analizar y diseñar nuestra personalidad para el siguiente cumpleaños. Por ejemplo, si has detectado que eres un aburrido, analizar porque y diseñar un nuevo perfil de personalidad. En esta fase es necesario comprobar la viabilidad de los cambios. Normalmente se es gilipollas toda la vida.

3) Fase de Desarrollo. En esta fase se trata de potenciar lo que se ha elaborado en la fase anterior. Por ejemplo, entrenándose para no ser tan aburrido: Aprender chistes, sonrerir etc…

4) Fase de Pruebas (Unitarias y de Integración) Fase muy importante, ya que se trata de hacer pequeñas pruebas de nuestras mejoras. En el caso de superar la timidez innata de la persona se trataría de soltar alguna idiotez de vez en cuando a ver como responde el público (pruebas unitarias) También hay que probar como nuestras mejoras se acoplan a nuestra personalidad en general (Pruebas de Integración). Si eres gilipollas y ahora te pones graciosillo, pues menudo cóctel

5) Puesta en Producción. Release. Y llegó el cumpleaños. A partir de hoy hemos de incorporar a nuestra personalidad esas nuevas mejoras que hemos ido elaborando a lo largo del año. Y a partir de hoy seremos una nueva persona versión N. Es posible que las pruebas no hayan sido exhaustivas y suframos una agresión justificada en el caso de que te partan la cabeza hartos de nuestra sinrazón. A esto se le denomina petada o mascletá. Normalmente sufriremos un volcado de pila o que es lo mismo un dolor de cabeza impresionante. En este sentido, lo mas prudente es volver rápidamente a la versión anterior.

En fin, que cada día seríamos mejores, o no.

servido por rafikis sin comentarios compártelo

En el nombre de la Performance

Cuando hablamos de Performance en el ámbito de la Ingeniería del Software nos referimos muchas veces a la velocidad o rapidez de respuesta de un determinado proceso. Pues bien, en el nombre de la Performance se hacen increíbles barbaridades dentro de esta profesión, la nuestra. Es patético ver por enesima vez a un ingeniero (eh!) defender su arquitectura que no la entiende ni Dios en base a la venerada performance. Ni separación de capas, ni claridad del código, ni reutilización, nada de nada. Oye que la aplicación va como un torpedo. Como el torpedo que le explotará al pobre analista que tenga que mantener el código. Obviamente la velocidad de respuesta es un factor a tener en cuenta, pero siempre hay que establecer un rango de tiempo límite. Es corriente encontrase con aplicaciones realizadas en lenguajes orientados a objetos, como java, que no utilizan el paradigma de la orientación a objetos ya que están dirigidas a datos y no objetos. Ejemplo típico en Java, es que en una aplicación Web, desde el jsp se traten resultset. Ni capas, ni nada. Venga, que así va rápido. Pues no, si trabajas con Java has de trabajar con objetos (herencia, polimorfismo, interfaces, reescritura, etc.…) ya sea en la capa de negocio, presentación o persistencia. Y si no es así, utiliza otro lenguaje, que no sea orientado a objetos, por ejemplo, php, o lo que sea. Por favor, no me ensucien Java. Que si trabajando con datos va más rápido, pues, repito utilicen otro lenguaje y si no toma x euros y compra un procesador más rápido, pero no me toquéis la buena programación orientada a objetos. Por eso, cuando alguien afirma no se que de la performance ya tiemblo. Siempre preferiré un aplicación más lenta (dentro de un margen) pero robusta a una más rápida, inestable y que sola la entienda su creador.

servido por rafikis 3 comentarios compártelo

El Ataque de los Clones

En el ámbito de la empresa y en particular en el caso de las tecnologías de la información están en todas partes. Se caracterizan principalmente por su frívola pedantería y su vanidad. Suelen estar en mandos intermedios (aunque pululan por toda la jerarquía) y que por inseguridad y nula auto confianza se agarran a la herramienta de la demagogia barata para añadir complejidad e importancia a asuntos sencillos y triviales. Se vanaglorian de sus logros, e incluso magnifican su errores pasados para acentuar la importancia se sus cometidos. Cualquier asunto simple se puede convertir (normalmente por razones políticas) en una situación de difícil solución. Son peligrosos cuando dominan a la perfección la demagogia y con ello abruman y nublan a sus superiores. Por ejemplo, en una reunión, un jefe de proyecto pide la opinión acerca de la posibilidad de utilizar una nueva tecnología. La mayoría de presentes piensa que pueda ser una buena idea. Ahora bien, nuestro personaje que no domina lo nuevo, rápidamente salta como un tigre idiota y arremete con su sabio lenguaje acerca de nuevos cambios en la empresa. Normalmente se levanta y dice algo como:

Políticamente no estamos en condiciones de sustituir nuestras herramientas corporativas por otras que personalmente he probado y cuyo performace es bajo. Además nuestro Middleware no soportará un refactoring y menos un Business Process Rengineering a bajo nivel. (¡¡¡T’ha hecho daaaañoo!!!)

En estos casos, lo fácil sería la eliminación directa del individuo vía golpe seco con portátil Toshiba años 90 o en su defecto caida fortuita pizarra businnes, sin embargo es recomendable armarse de paciencia y dejar correr al idiota y dejar la violencia (que no gratuita) para otros casos mas graves.

Ojo con los clones.

servido por rafikis 4 comentarios compártelo

El monstruo crece

Buenos días programadores chapuceros, un días más para saturar el espacio lógico del universo de auténticos líos de bucles, condicionales, asignaciones. Venga complicaciones en cantidades industriales, venga líneas de código para complicar aún más el inmenso océano de aplicaciones informáticas. ¿Cuántas líneas de código existen en el mundo? ¿Eing? ¿Cuántas? Y vosotros no paráis. Por favor, un poco de reflexión, de sentido común, levantad las manos del teclado y parad, parad de introducir código incomprensible y chapucero, parad de engordar el monstruo que estáis creando. Levantad el culo y negaros a introducir más mierda. Por favor, pensad en vuestro hijos (que seguro no tenéis por falta de tiempo o por problemas disfuncionales leves o por falta de pareja o simplemente por desconocimiento, o por que nos os da la gana…) o en vuestros nietos, ¿Van a heredar vuestras asquerosas obras? Venga hombre, no lloréis, la vida es dura, levantad las manos y negaros a seguir con esto, escribid el último comentario y salvad la humanidad de tanta chapuza. I no os quejéis porque sois conscientes de ello, lo sabéis y seguís en vuestra línea. Parad antes que el mundo se vea abocado a un caos inmenso de código inútil y chapucero. Parad o los buenos programadores no veremos arrastrados a un arreglo sin fin de vuestras chapuzas. ¡Parad, por Dios, parad!.

servido por rafikis 6 comentarios compártelo

else o el misterio de la inmensidad

En programación poner un else es poner el infinito. Para cualquier condición del tipo if condición poner un else es decir que se ejecute todo lo que no cumpla la condición. Por ejemplo:

If (x==0)
….
else
…
X puede valer cualquier valor menos 0. Es decir, infinitos valores. O sea que ojo, por ahí puede pasar cualquier cosa. Cuidadito con los else ya que son un coladero de infinitos. En este caso no parece peligroso, pero examinemos el siguiente ejemplo:

If (soy idiota)
…
else
…
Nótese la condición, es de una sutiliza que asusta. Si eres idiota, pues nada, lo eres y poca cosa podemos hacer, ahora bien ¿y si no lo eres?, no significa que no seas imbécil, ni gilipollas, ni cateto, ni cursi, ni bombero, ni inspector de hacienda ni cacahuete. O sea ojo, ¡ojo! con los else que son ni más ni menos el universo entero. Por ahí se han dado casos de agujeros negros, y muchos programadores han caído en las fauces de tales elementos. Sus ansías de succión son proporcionales a la inmensidad de su extensión. Recomiendo, mucha atención a la hora de utilizarlos, son peligrosos, por tanto abogo por un while (pensando) antes de poner un else así por así.

servido por rafikis sin comentarios compártelo

¿Quién es ese programador?

Recientemente un compañero me confesó que a veces oye voces, y que éstas son sensuales y su origen sin duda está en la estrecha relación entre su trabajo y sus obras. Esto es lo que oye:

Mírame yo soy tu aplicación, tu programita
la que tiene el fuego
la que sabe bien que hacer

servido por rafikis 2 comentarios compártelo

Modelos homogéneos

Muchas veces entre analistas se establecen largas discusiones de cómo diseñar una aplicación. Surgen varias alternativas, diferentes soluciones a problemas. Por ejemplo, se proponen aplicar patrones a problemas muy comunes o se inventa un patrón ad-hoc para la situación. Pero lo verdaderamente importante es la homogenización en la programación. No importa tanto aplicar esta o aquella solución, lo verdaderamente importante es que todos apliquen la misma. Y si pasa que esa solución no sirve para todas las circunstancias, es el momento de replantearla o de crear una excepción a la regla. Pocas aplicaciones son homogéneas en cuanto a soluciones. Por ejemplo, si se han establecido n capas, no nos las podemos saltar. Esta homogenización tiene muchas veces el inconveniente de frenar la “creatividad” del programador, ya que ha de ceñirse a los modelos establecidos. Sin embargo, esa unidad de criterios nos facilita el mantenimiento y la legibilidad del código. Es pura belleza observar una aplicación donde todos los procesos siguen un mismo modelo claro y sencillo.

servido por rafikis 3 comentarios compártelo