Cargando...Hay veces en la vida en que algún programador mete la pata. Y hay veces en que esas metidas de pata se prolongan en el tiempo. Muchas veces esos períodos de tiempo son tan largos que las metidas de pata del programador se convierten en clásicos.
Un clásico es el portal de noticias Observa, del que soy fiel lector. Pero creo que en realidad lo que me hace fiel es poder esperar estos momentos de regocijo en que el programador de Observa mete la pata y salta un error en la página principal que se ve así:
Hay varias cosas que nosotros programadores debemos tener en cuenta a la hora de poner un sistema en producción y que Observa es un caso claro no tiene.
1) Hay que crear páginas de error personalizadas. Para eso recomiendo leer este artículo: http://www.smashingmagazine.com/2009/06/12/effective-maintenance-pages-examples-and-best-practices/
2) Hay que deshabilitar en producción las páginas de error que tira el .net Framework. Así que alguien de desarrollo de Observa tendrá que leer este artículo: http://msdn.microsoft.com/es-es/library/h0hfz6fc(VS.80).aspx
3) Hay que ser muy celoso de la seguridad. ¡Paranoico! Porque una de las primeras cosas que aprendí respecto a seguridad es que el posible atacante no debe ni siquiera saber en que tecnología funciona nuestro sitio web.
Si vemos la imagen anterior, encontramos que hay dos links que presionando el primero nos muestra un montón de rutas y versiones de archivos y presionando el segundo nos muestra el código fuente de la aplicación.
4) Descubro analizando el código que el sitio de Observa está hecho todo a mano y no con un CMS (ya lo sabía de antes pero sirve para ejemplo), por lo cual eso aumenta la posibilidad de errores porque hay que tocar código. Un CMS, aunque sea propietario, permite hacer cambios a través de configuraciones y no a través de código.
5) Proceso de Testing: el testing hoy en día es muy importante porque nada puede fallar. Es por eso que deben existir los casos de uso y las matrices de trazabilidad. Cada vez que se cambia una funcionalidad hay que volver a probar todos y cada uno de los casos de uso.
Pero no solo eso. Hoy en día se hacen diferentes tipos de testing e incluso se contrata a empresas especializadas, como es el Centro de Ensayos de Software.
6) Control de errores: .Net Framework nos entrego a los programadores de plataforma Microsoft la belleza americana del control de errores estructurado: Try Catch. Úsenlo al máximo con todo su potencial:
Try Catch When Finally End Try
Deben existir casos para todas esas partes y conocer de antemano que excepciones se pueden dar. Incluso los componentes internos tienen que implementar Excepciones y devolver Excepciones cuando sea posible. Eso lo aprendí del código de Intellikon y funcionaba muy bien!
7) Podemos hablar durante horas de esto y seguir apareciendo errores, por eso, ningun software está libre de errores. El error de programación es imposible de evitar siempre, porque por su naturaleza, no se pueden preveer todos los caso. Los clientes también deben entender eso. Por eso es bueno recordar las 4 variables del software: Cronograma, Alcance, Presupuesto y Calidad. Cuando se contruye software, una tiene que ser variable y todas las demás fijas.
Para finalizar, unos chistes sobre bugs de software:
http://cliquee.net/2007/05/bug-o-mania-story-of-software-bugs/
Buenísimo !!! Si los garbage collectos de los frameworks funcionaran realmente bien, muchos programas serían eliminados antes de ejecutarse.
Jaja…. a tu mejor estilo, podría decir: «Los Garbage Collectors funcionan bien solo si les das plata cuando pasan a los bocinasos en las fiestas».
Fede muy buen artículo, Abrazo Pablo ;-)
Gracias Pablito!