miércoles, 2 de noviembre de 2011

[14 de 97] Una linea de codigo funcional equivale a 500 de especificaciones.


Post publicado originalmente entre Mayo del 2009 y Enero del 2011 en mi anterior blog.
Pertenece a una serie sobre arquitectura de software, replicaré los comentarios ya que, a mi parecer, son lo más importante de la serie.

Puedes encontrar el listado de esta primera entrega en este enlace.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:
"Una línea de código funcional equivale a 500 de especificaciones."
Allison Randal. 

Allison Randal Es arquitecto en jefe y principal desarrollador del proyecto Parrot.
Con más de 25 años como programadora, ha desarrollado de todo, desde juegos hasta herramientas de análisis linguisticos pasando por websites, compiladores y demás.

[NT. El título original del axioma es: One line of working code is worth 500 of specification]

Aquí parte importante del axioma:

men @ work #03

---

Design is a beautiful thing. A systematic, detailed presentation and review of a problem space and solution reveals errors and opportunities for improvement, sometimes in a startlingly dramatic way. The specifications are important because they provide the pattern for building. Taking the time to think through the architecture is important, both on a macro level with an eye for interactions between components and on a micro level with an eye for behavior within a component. 

Unfortunately it's far too easy to get wrapped up in the process of design, enthralled by architecture in abstract. The fact is that specifications alone have no value. The ultimate goal of a software project is a production system. A software architect must always keep an eye on this goal, and remember that design is merely a means to an end, not an end in itself. An architect for a skyscraper who ignored the laws of physics to make the building more beautiful would soon regret it. Losing sight of the goal of working code spells serious trouble for any project.

Value the team members who work on implementing your vision. Listen to them. When they have problems with the design, there's a good chance they're right and the design is wrong, or at least unclear.  It's your job, in these cases, to modify the design to meet real-world constraints by working with your team members to determine what works and what does not. No design is perfect from the start; all designs need to be modified as they are implemented.

If you're also a developer on the project, value the time you spend writing code, and don't believe anyone who tells you it's a distraction from your work as architect. Your vision of both macro and micro levels will be greatly enhanced by the time you spend in the belly of the beast bringing it to life.
---

Para este axioma iniciaré con una anécdota,  y compartiré dos refranes que según una encuesta, forman parte de los 150 refranes más utilizados en este país del águila devorando a la serpiente, todo esto con el único fin de contextualizar la reflexión del axioma y evitar lo más que se pueda una mala interpretación.

Va la anécdota:
Hace ya varios años, estábamos a punto de liberar una aplicación sencilla a producción: el objetivo de la aplicación era poner a prueba el uso de una herramienta para la creación de flujos de trabajo, está demás mencionar el nombre de la herramienta. Honestamente, la herramienta era muy buena para construir flujos básicos y escenarios no tan complejos, su único punto débil era la complejidad requerida para meter código personalizado en algún punto del flujo.

Para no hacer el cuento largo, ocurrió lo siguiente: la aplicación funcionó de maravilla en los ambientes de: desarrollo, integración, y QA, pero, al momento de llegar a producción, la ingrata (sí, ingrata) herramienta no lograba procesar adecuadamente un stream de bytes que contenía una imagen. El mensaje de error (como siempre muy descriptivo en este tipo de herramientas) decía algo más o menos así: el stream no es válido.

El encargado de ese fragmento de código se negaba a realizar cambio alguno pues indicaba que el código había pasado sin problemas todos los ambientes y no tenia caso poner en riesgo el entregable completo; además de que, la única manera de encontrar la posible falla era agregando código para "loggear", lo cual  iba en contra de las "mejores prácticas" del uso de la herramienta.
Doy mi palabra que, como ocurre en las películas, durante la discusión para encontrar como solucionar el problema tuve un flashback  y llegó a mi mente, cual albatros estrellándose en mi frente,  la noción de que el EOF en algunos lenguajes se podía substituir por la constante -1.
La solución:  se agregó un -1 al final del stream. Con eso la recuperación del stream funcionaba bien en todos los ambientes.

¿Por qué en el ambiente de producción no funcionaba el código original? nadie logró dar una explicación totalmente convincente, el asunto fue que, con esa "maniobra" todos vivieron felices para siempre (bueno, realmente vivieron felices en lo que les cambiaron la herramienta por otra mas popular)

Van los refranes:
Va la reflexión:
¿Entonces? todo lo que hemos reflexionado sobre: diseño, patrones, integración continua, etc,etc... ¿Está demás?
La respuesta es, por supuesto que no está demás,  al contrario la idea de todas estas reflexiones es tratar de  analizar y compartir los axiomas del libro para poder, entre todos, mejorar nuestros procesos de desarrollo de software y, de ser posible, reflejar esas mejoras en nuestra vida diaria. ;)

Creo que Allison lo explica en estas líneas (parafraseando):

        Tomarse el tiempo para pensar en la arquitectura (de la aplicación) es importante: tanto a alto nivel, para poder visualizar las interacciones entre los componentes; como a bajo nivel, para poder ver el comportamiento dentro un componente.
        Desafortunadamente, es muy fácil envolverse en el proceso de diseño, cautivados por la (definición de la) arquitectura (muy) en abstracto.
        {...}
        El objetivo final de un proyecto de software es (llevar/poner) el sistema en producción.
        Un Arquitecto de software siempre debe mantener claro ese objetivo, y recordar que el diseño es simplemente un medio para tal fin, no el fin en sí mismo.

Entiendo que, esas líneas podrían orillarnos a calurosas reflexiones filosóficas o incluso (pro/anti) maquiavélicas pero, creo que de momento, podemos abstraernos a un nivel no tan alto. XD

Cómo ya hemos dicho, y seguiremos diciendo, el truco será siempre, encontrar el sabio equilibrio.
Discutir y compartir opiniones seguramente nos ayudan a tener un mejor criterio para decidir y alcanzar este equilibrio, así que, como siempre.... agradezco desde ya sus valiosos comentarios.  ;)


2008-11-14-The-best-way-to-improve-code-performance

Saludos!!!

RuGI
Isaac Ruiz Guerra

Comentarios:

Creo que hace poco hemos tenido un dialogo parecido en debugmode_on:

Afortunadamente, me gusta leer que realmente has analizado el axioma en su contexto y le has sacado el punto justo. Por que, sinceramente, los "mandamientos" de este tipo sacados así en frio, como les gusta a hacer a alguna gente en simples enumeraciones del tipo: entrada en blog "los 10 x más guays para ser un gran programador", son simples tonterías. No hay que tomárselos literalmente.

Yo en este caso, como en la mayoría, abogo por un equilibrio. Por que te puedes encontrar, simplificando, con una linea de codigo que dice:
CalcularResultado(x,y) = x + y.
Todo correcto, ¿verdad? No necesita documentación, todo el mundo sabe lo que hace, está clarísimo... y si leyeras la especificación dice... "Calculamos el producto de x e y" o "Calculamos la suma de x e y excepto si x es cero y entonces devolvemos 0", por decir algo.

Es decir, fiarse sólo, única y exclusivamente del código es mucho fiarse, y además sólo lo puede verificar alguien que sea programar y sepa además, de cabeza, de que va el tema.

Las especificaciones las puede verificar más facilmente un no-programador y comprobar si se ajustan o no al código lo puede hacer alguien sin saber previamente de que va el tema.

Por supuesto tampoco hay que exagerar y llegar a usar 500 lineas para explicar lo que va a hacer una linea simple de código, pero vamos, ni tanto ni tan poco.

S!

Enviado por GreenEyed en septiembre 06, 2009 a las 11:13 AM CDT #
---
Hola GreenEyed !!!
Interesante (y altamente recomendable) el hilo que mencionas de debugmodeon.....realmente quise ser lo más congruente con la reflexión, sobre todo porque me ha tocado "ver de cerca" los dos extremos; y seguramente todos los hemos visto y por ello reconocemos que es importante guardar el equilibrio.


Viene aún otro axioma que toca este tema, seguramente confirmará que, como bien dices , debemos tratar de hacer: "ni tanto, ni tan poco"


Saludos!!!


Enviado por RuGI en septiembre 13, 2009 a las 02:04 AM CDT #

-------------------------------------------------------
Créditos:
La foto es de: cool_colonia4711
http://www.flickr.com/photos/cool_colonia4711/1390902934/in/photostream/
La tira es tomada de: http://www.geekherocomic.com/
-------------------------------------------------------

No hay comentarios:

Publicar un comentario