Durante los últimos 10 años he participado en el desarrollo de una gran cantidad de aplicaciones empresariales a la medida y realmente ninguna logra despertar en mi el orgullo con el que sueño. Con toda esta experiencia ya debo ser capaz de sacar conclusiones y tratar, de una vez por todas, de hacer el diseño completo de una aplicación que logre abarcar todas las cosas buenas que un programador desea para esta.
La realidad es que muy pocas personas puedo considerarlas buenos programadores; es más, a veces dudo de mis capacidades. Pero el punto es que programadores reales hay muy pero muy pocos. La educación de las universidades no prepara a los profesionales en el oficio de la programación, simplemente les dan a los estudiantes conocimientos teóricos y no estimulan la práctica intensiva. ¿Por qué? Esta es una pregunta que he tratado de responder sin aún tener una respuesta definitiva.
El oficio de programador es uno de aquellos oficios en los que la recompensa es muy poca en comparación al esfuerzo requerido ya que si todo sale bien las personas que están al frente del proyecto son muchas y todas ellas van primero en la fila que el programador, todos van primero. Por el contrario, si algo sale mal, no hay nadie más que pueda hacer algo que el mismo programador; por lo tanto es este el que debe sacrificarse para que no se frustren los planes de los demás.
Pero, ¿por qué las cosas pueden salir mal? ¿por qué el programador es, de cierta manera, una víctima? Pues en mi opinión, por más que se quieran buscar culpables, no es más que la culpa del programador. Es decir, es víctima de su propio invento.
El razonamiento es sencillo. Tomemos como metáfora la construcción de un acueducto para una cuidad. El requerimiento es aparentemente sencillo, traer agua a una ciudad. A primera vista es una tarea sencilla y el programador dice resolverla rápidamente: tendemos una tubería desde la represa hasta la ciudad, eso es todo lo que hay que hacer, en dos días está listo. Ja! he ahí el error. ¿Ya lo vieron? Si eres de los que creen que es así de sencillo o te escudas en que "el requerimiento no pide nada más", te advierto que te esperan largas horas de trabajo extra y muchos sinsabores con todos y serás uno más de los que hacen que este oficio sea tan mal visto y tan odiado por todos.
Primero que todo, transportar información de un lado a otro no es una tarea simple y menos si debes instruir máquinas sin corteza cerebral para hacerlos. Hay muchas cosas que pueden ir mal, muchas cosas que debe monitorear, muchas cosas que debes controlar. Cuando las cosas están fuera de control y no sabes qué pasó es entonces cuando la programación se vuelve un asunto tedioso, amargo y conflictivo. Acéptalo, eres de los que dice que todo es fácil. Yo también soy así.
Volviendo a nuestra metáfora, tender la tubería es solo una de tantas cosas que se deben hacer. Se deben poner válvulas, contadores de flujo, desvíos en caso de exceso, reguladores en caso de escacez, tuberías contingentes en caso que la principal falle y cada uno de estos componentes se debe monitorear detalladamente. Así, en caso de alguna falla podremos tener control y saber exactamente qué ocurrió. Estos mecanismos otorgan el tiempo necesario para tomar buenas decisiones y realizar las reparaciones sin prisa. Estos mecanismos son mucho más complicados de hacer que el mismo requerimiento y por lo tanto casi todos los programadores pasan por alto o dejan para más adelante.
Como podemos ver, el trabajo de dos días se pondrá en funcionamiento e inmediatamente comenzarán los problemas: hay que disminuir el flujo ya mismo porque la ciudad se está inundando; ¿qué cantidad de agua está fluyendo?; ¿qué presión tienen las tuberías?; ¿cuánta presión puede aguantar la tubería?; la tubería tiene una fuga pero ¡no podemos dejar la ciudad sin agua!... Ohhh ¿y ahora?. Inmediatamente todo se viene abajo, el proyecto tiene una salida en falso y los ciudadanos, alegres por el agua ahora están molestos. Eso mismo pasa con los proyectos de software.
Entonces, ¿qué se debe hacer para prevenir esto? La respuesta no se encuentra en la planeación del proyecto, ni en el personal de gestión, ni en el personal ejecutivo sino en la cabeza del programador mismo. Solo una vez tenemos para decir el tiempo que nos tomará hacer algo y ese tiempo que damos no debe ser tomado a la ligera, se debe medir muy bien y establecer qué cosas hay que hacer adicionales a las que pide el requerimiento, más para nosotros que para el mismo usuario.
Aunque en próximos capítulos detallaré cada tema vale enumerar aquí muchas de los desarrollos adicionales que se deben tener en cuenta para hacer ese sistema perfecto con el que todos soñamos:
- Mecanismos de configuración en tiempo real (que no requieran reinciar todo)
- Mecanismos de control del flujo de la información (tanto de control acceso como control de cantidad)
- Mecanismos de rastro (bitácoras e históricos de cambio)
- Mecanismos de contingencia (distribución en múltiples nodos activos o pasivos)
- Mecanismos de diagnóstico (mediciones, consulta de rastro, consulta de datos)
El control de flujo de información permite alterar el comportamiento del sistema en cuanto a qué usuarios pueden acceder a la información o a ciertas acciones y además controlar la cantidad de información (registros por lo general) que se muestran como resultados.
El rastro que deja un sistema es clave para determinar posibles daños y repararlos más eficientemente. Así mismo permite ver cuándo la información cambió y quién realizó el cambio.
La contingencia permite reaccionar en caso de una falla en la infraestructura y permite mantener el sistema funcionando sin que el usuario final se percate o por mucho que se queje por la eficiencia del sistema, algo que no genera mala propaganda.
El diagnóstico permite determinar al mismo sistema si se encuentra en un estado adecuado para atender las solicitudes de los usuarios. Además permite a los usuarios finales obtener información del estado del sistema sin necesidad de acudir a los administradores de infraestructura una y otra vez.
La realidad es que un sistema en producción se comporta muy diferente que en un ambiente de pruebas controlado, comenzando por la cantidad de usuarios concurrentes y terminando con que los usuarios en producción son impredecibles. Es por esto que los cinco tipos de mecanismos enumerados se proponen como algo necesario y que no surte utilidad sino hasta que el sistema se encuentra en producción.
Así pues, todos los buenos programas son complejos, porque deben hacer algo puntual pero lo deben hacer de la mejor manera. Estoy seguro que el próximo requerimiento que recibas lo vas a estimar diferente y no por lo que acabas de leer sino porque has vivido las consecuencias de no tener los mecanismos mencionados.
No hay comentarios:
Publicar un comentario