Como probablemente ya sabréis, NDepend es una de esas herramientas que están ahí de siempre, ayudando a desarrolladores y arquitectos a mejorar la calidad de nuestro software gracias a sus potentes y flexibles herramientas de análisis de proyectos.
Hace tiempo ya echamos por aquí un vistazo, pero creo que es interesante darle otra vuelta y refrescar conocimientos.
Publicado por José M. Aguilar a las 8:05 a. m.
Etiquetas: arquitectura, buenas prácticas, calidad, herramientas
No es poco frecuente ver aplicaciones con faltas de ortografía que un niño de primaria calificaría como graves. Y notad que no hablo sólo de las etiquetas, mensajes y otros elementos visuales que van a parar a los atónitos ojos de nuestros usuarios, sino también de lo que hay por detrás, en el código fuente.
A nivel de código, las denominaciones internas en clases, métodos o variables, textos en comentarios o incluso los mensajes en check-ins en el control de código fuente, son habitualmente terribles. Claro, sabemos que eso no lo va a leer nadie, o al menos nadie de fuera de nuestro entorno, y bajamos la guardia hasta límites que rozan la ilegalidad. Mezclamos idiomas sin ningún criterio (¿quién no ha escrito alguna vez un método
GetFacturas()
, obtenerResources
() o una variable lineasCount
en su base de código?), cometemos atropellos ortográficos, gramaticales y otros tipos de aberración de forma impune, escudados en que no hay que prestar atención a esos detalles porque es sólo código.Y lo peor es que esta actitud de desidia es contagiosa. Cuando entras en un proyecto donde todo está escrito sin ningún tipo de miramiento, lo normal es que continúes en esa línea, haciendo que la barbarie sea cada vez mayor y, a su vez, más contagiosa en el futuro. Y cuando comiences otro proyecto, llevarás la costumbre de hacerlo así y continuarás extendiendo esta práctica ad eternum.
Pero, ah, amigos artesanos del código, esto se va a acabar.
Las próximas versiones de Visual Studio corregirán drásticamente esta tendencia, incluyendo la revisión ortográfica como parte del proceso de compilación. Además, como comentó S. Somasegar en una reciente entrevista,
“esta característica no podrá ser deshabilitada; en caso contrario ya sabemos lo que ocurriría, y va en contra de la firme apuesta de Microsoft hacia un mundo que se comunique mejor”Y la cosa va muy en serio. Para dar mayor formalidad a esta necesaria iniciativa, Microsoft ha firmado un acuerdo con distintas academias responsables de definir y actualizar la mayoría de idiomas del mundo, como la National Commission on Language and Script Work (国家语言文字工作委员会) de China, la Real Academia Española (RAE), Academy of the Arabic Language (مجمع اللغة العربية), la Royal Galician Academy, o Council for German Orthography (Rat für deutsche Rechtschreibung) por citar sólo algunas. De estas instituciones obtendrá los diccionarios actualizados que serán utilizados por las herramientas del gigante de Redmond para comprobar que estamos escribiendo como debemos. En el caso del inglés es distinto porque no existe un organismo regulador, pero se atenderán a las guías oficiales publicadas por los países donde es la lengua oficial.
En Visual Studio tendremos disponibles propiedades a nivel de proyecto y de cada archivo (de código, recursos, diseñadores, etc.) en el que indicaremos el idioma en el que debe realizarse la comprobación.
Por supuesto, también ha sido actualizado intellisense para alternativas a las palabras que vayamos escribiendo e incluso un menú de sinónimos, de la misma forma que Microsoft Word:
Para los casos en que el idioma pueda cambiar dentro del propio archivo o incluso en distintas secciones de éste, se han añadido directivas
#pragma
que pueden usarse en cualquier punto. Por ejemplo, en el siguiente código se han detectado dos errores de compilación para la porción escrita en español, en un comentario y en el nombre de un método:Por supuesto, las comprobaciones atienden al camel casing, es decir el nombre del método
ObtenerFactura()
se entenderá correcto, mientras que Obtenerfactura()
no lo será. Otra ventaja colateral de esta característica es que dejaremos de utilizar nombres de variable sin sentido como “s”, “xyz”, tendiendo a que realmente se refleje su intencionalidad como “saldo” o “coordenadasTridimensionales”. Se está estimando, sin embargo, excluir las variables de tipo índice obvias como la típica “i” en un bucle for
por razones históricas.Las mismas directivas y propiedades se aplicarán en las comprobaciones de cadenas de texto, recursos (.resx) y diseñadores de la aplicación. De esta forma, podremos estar seguros de que los textos que lanzamos a los usuarios habrán superado un nivel mínimo de calidad, que falta hace en muchas aplicaciones:
En fin, creo que es una iniciativa absolutamente necesaria para mejorar la calidad interna de nuestro código y, como extensión, de nuestras aplicaciones, y me gustaría felicitar a Microsoft por haber tomado esta controvertida decisión. Seguro que traerá mucha polémica, pero estoy convencido de que es por el bien de la humanidad.
Aunque en principio esta nueva característica sólo estará disponible para Visual Studio 2015, no se descarta la creación de extensiones para todas las versiones de Visual Studio, comenzando en la 2005. Está previsto incluso su introducción en el proyecto Omnisharp para poder aplicarlo en entornos de desarrollo más allá de Visual Studio, lo que abriría su uso a otras plataformas como Mac o Linux, y de la posibilidad de desarrollar plugins oficiales para Git, Mercurial, Subversion, TFS y sistemas de integración continua que permitan automatizar estas comprobaciones.
Se avecina un año maravilloso donde los sistemas de control de código fuente podrán rechazar un commit o check-in por tener faltas de ortografía, o en el que en nuestra mesa, junto a clásicos como C Programming language o Code Complete , podremos encontrar el diccionario de la real academia de la lengua española.
¡Feliz escritura de código!
Nota para despistadillos: obviamente no es real, se trata simplemente de una broma del Día de los Inocentes. Así que tranquilos, podemos seguir dando patadas al diccionario impunemente en nuestro código :-DDD
Publicado en Variable not found.
Publicado por José M. Aguilar a las 12:05 a. m.
Etiquetas: calidad, inocentadas, novedades, visualstudio
Recientemente se ha publicado la tercera versión de NDepend, que ofrece interesantes novedades respecto a las anteriores, como la integración absoluta con Visual Studio, el soporte para soluciones multi-proyecto, potentes mecanismos de búsqueda, edición múltiple de CQL, o el seguimiento de cambios, además de las tradicionales características del producto.
Para habilitar esta característica es necesario instalar el plugin en el IDE, que se realiza desde el propio entorno visual de NDepend:
De esta forma, ya no es necesario acudir a la herramienta Visual NDepend para realizar búsquedas, comprobar reglas o navegar a través de la base de código: lo haremos directamente desde VS, utilizando los menús contextuales. Y gracias a ello, podemos disfrutar de las nuevas opciones de navegación, que nos permitirá surcar el código utilizando rutas distintas a las habituales:
Además, como comenta Patrick Smacchia, padre de la criatura, el rendimiento del entorno prácticamente no se resiente, dado que los análisis se ejecutan en segundo plano de forma incremental.
Recordar, por último, que NDepend es una aplicación comercial, pero dispone de una versión limitada gratuita utilizable por universidades, desarrolladores open source e incluso, durante un tiempo determinado, de prueba en proyectos comerciales.
Página del producto: http://www.ndepend.com/
Publicado en: Variable not found
Hey, ¡estoy en twitter!
Publicado por José M. Aguilar a las 11:49 p. m.
Etiquetas: .net, buenas prácticas, calidad, desarrollo, herramientas
Existen numerosas aplicaciones que permiten analizar nuestros desarrollos con el objetivo final de incrementar la calidad de los mismos. FxCop, por ejemplo, es capaz de analizar los ensamblados y avisarnos cuando se encuentra con incumplimientos de las pautas de diseño para desarrolladores de librerías para .Net Framework (Design Guidelines for Class Library Developers). También hace tiempo comenté por aquí la disponibilidad de Microsoft Source Analysis for C#, una herramienta que se centra en el código fuente y el cumplimiento de reglas de codificación.
Ahora, gracias al ofrecimiento de Patrick Smacchia, lead developer del producto, he podido probar NDepend, una herramienta de análisis de código de la que había oído hablar y que va mucho más allá que las citadas anteriormente.
La principal misión de NDepend es ayudarnos a incrementar la calidad de nuestros sistemas desarrollados con .NET mediante el análisis de sus ensamblados y código fuente desde distintas perspectivas, como la complejidad de sus módulos, el tamaño de los mismos, las interdependencias entre ellos, etc. Es decir, a diferencia de otros analizadores, su objetivo no es avisarnos de aspectos como la utilización de convenciones de codificación (aunque también puede hacerlo), o el uso de buenas prácticas de diseño, sino ayudarnos a determinar, por ejemplo, cuándo ponemos en peligro la mantenibilidad y evolución de un sistema debido a la complejidad o al fuerte acoplamiento de algunos de sus componentes, por citar sólo algunos criterios.
El entorno gráfico
VisualNDepend es el entorno gráfico de la herramienta, y nos ofrece un entorno de trabajo muy potente e intuitivo, aunque durante los primeros minutos pueda resultar algo complejo debido a la cantidad de información mostrada.
Iniciar el análisis de un sistema es muy sencillo; una vez seleccionado el ensamblado, conjunto de ensamblados o proyecto a estudiar, el sistema realiza el análisis, del cual se obtiene un informe bastante completo, basado en web, sobre el mismo (podéis ver un ejemplo de informe en la página del producto). En él se recogen:
- métricas de la aplicación, entre las que encontramos el número de líneas de código, comentarios, número de clases, métodos, etc., así como datos estadísticos relativos a la complejidad, extensión y estructura del código.
- métricas por ensamblado, donde se refleja, por cada uno de los ensamblados que componen la solución, datos sobre su tamaño, grados de cohesión, acoplamiento, y otros aspectos relativos a su complejidad e interdependencia.
- vista de estructura (captura de la derecha) que muestra la distribución de componentes, la granularidad y su complejidad relativa según el tamaño de los bloques visualizados.
- diagrama de abstracción e inestabilidad, que posiciona cada ensamblado en función del número de clases abstractas e interfaces que presenta y su dependencia del resto de elementos.
- relación entre ensamblados, que detalla las interdependencias entre ensamblados del proyecto, los posibles ciclos, así como un posible orden de generación.
- consultas y restricciones CQL, que realiza una serie de consultas predefinidas sobre los ensamblados y el código que nos ayuda a detectar una infinidad de problemas en nuestros desarrollos, desde aspectos relativamente simples como el exceso de métodos en clases o el incumplimiento de ciertas convenciones de nombrado, hasta problemas en la cobertura de los tests generados con NCover o Visual Studio Team System.
Pero lo mejor del entorno gráfico no es poder generar un análisis en formato web para poder consultarlo más adelante, de hecho esto puede conseguir también con la aplicación de consola que incluye NDepend. Lo mejor son las fantásticas herramientas interactivas que nos permiten navegar a través de nuestras aplicaciones, cambiar de vista, ampliar información sobre cualquier elemento, y realizar consultas en tiempo real, siempre ofreciendo unos resultados muy claros y visuales, como:
- diagrama de dependencias entre todo tipo de elementos, como clases, espacios de nombres, o ensamblados. Resulta muy útil, además, configurar el tamaño de los bloques, el grosor del borde y el de las flechas de unión para que sean proporcionales a la complejidad, tamaño y una larga lista de criterios.
- matriz de dependencias, que muestra de forma visual las relaciones de utilización entre espacios de nombres, tipos, métodos o propiedades, con posibilidad de ir ampliando información.
- comparación entre ensamblados, mostrándonos los cambios producidos entre, por ejemplo, dos versiones de una misma librería o aplicación.
- navegación avanzada por el código a través del uso del menú contextual que facilita la rápida localización de referencias, directas e indirectas, hacia y desde un método, propiedad o tipo existente.
- enlace con Reflector, una herramienta indispensable, con la que se integra perfectamente gracias a su plugin.
CQL (Code Query Language)
Sin duda, una de las características más interesante que tiene NDepend es el soporte del lenguaje de consulta CQL (Code Query Language), que nos ofrece la posibilidad de tratar nuestro código y ensamblados como si fuesen una gigantesca base de datos sobre la que podemos realizar consultas de forma muy natural. Las posibilidades que esto ofrece son tan amplias que prácticamente todas las funcionalidades de la aplicación están basadas en órdenes CQL prediseñadas que acompañan al producto, aunque podemos crear todas las consultas personalizadas que necesitemos, como por ejemplo:
/* Obtiene los métodos que escriben una propiedad */
SELECT METHODS WHERE IsDirectlyWritingField "Model.Cliente.Nombre"
/* Obtiene métodos que acceden incorrectamente a los
datos desde la capa de interfaz
*/
SELECT METHODS FROM NAMESPACES "Interfaz" WHERE IsDirectlyUsing "MySql.Data"
/* Obtiene los 10 métodos con más líneas de código */
SELECT TOP 10 METHODS ORDER BY NbLinesOfCode DESC
/* Obtiene los métodos considerados "peligrosos" según su complejidad ciclomática */
SELECT METHODS WHERE CyclomaticComplexity > 20
Además de consultas CQL cuyo resultado podremos observar de forma directa tanto visualmente como en forma de listado, es posible incluir restricciones (WARN) que hará que el sistema nos alerte durante el análisis de un proyecto que cumpla las condiciones especificadas. Por ejemplo, la siguiente restricción nos avisará cuando exista un cierto tufillo a complejidad excesiva en un método (que haya sido definido con más de 10 parámetros):
WARN IF Count > 0 IN SELECT METHODS WHERE NbParameters > 10
Estas consultas pueden ser añadidas (en la versión Pro) e integradas en los análisis, así como modificar las existentes, de forma que el producto puede ser personalizado a nuestras convenciones o necesidades específicas.
Otra posibilidad es incluir dentro del código de un ensamblado las restricciones que deseamos que se cumplan, expresándolas en lenguaje CQL embebido en un atributo de tipo CQLConstraint
aplicado a sus elementos:
Afortunadamente existe mucha información disponible en la web sobre el lenguaje CQL, y consultas que nos muestran cómo sacarle el máximo partido.
Instalación e integraciones
NDepend se distribuye en formato .zip, y que puede ejecutarse directamente una vez descomprimido el contenido sobre una carpeta. La licencia, una vez obtenida, es un archivo XML firmado digitalmente que debemos colocar en el directorio de la aplicación, y listo.
Ya en ejecución, desde el menú “options” es posible configurarlo para que se integre con Visual Studio 2005, 2008 y como he comentado anteriormente, con el magnífico Reflector, con el que hace una excelente pareja.
Asimismo, es posible utilizarlo en sistemas como MSBuild y NAnt, facilitando así su uso en entornos de integración continua y montaje automatizado, para los que ofrece librerías
Finalmente, he de aclarar que NDepend es una aplicación comercial, aunque dispone de una versión limitada gratuita utilizable por universidades, desarrolladores open source e incluso, durante un tiempo determinado, de prueba en proyectos comerciales.
En cualquier caso, no dudéis en probarlo: os dará un control sobre vuestro código difícil de conseguir con otras herramientas.
Publicado en: www.variablenotfound.com
Publicado por José M. Aguilar a las 11:40 p. m.
Etiquetas: .net, antipatrones, buenas prácticas, calidad, desarrollo, herramientas, patrones
Aquí puedes encontrar la primera, segunda y tercera parte.
16. El desplome de las Punto-Bomb (2000)
Coste: 5 billones de dólares en valores, fracaso de miles de compañías.Desastre: la burbuja especulativa creada entre 1995 y 2001 alimentó un rápido aumento en inversiones en capital riesgo y valores bursátiles en Internet y los sectores tecnológicos. La burbuja "punto com" comenzó a hundirse al principio del 2000, eliminando billones en valores, miles de compañías y empleos, y comenzando una recesión global.
Causa: Las compañías e inversores obviaron los modelos de negocio habituales, centrándose en cambio en el aumento de cuota de mercado a expensas de los beneficios. (Más información)
17. El virus del amor (2000)
Coste: 8.750 millones de dólares, millones de ordenadores infectados, importantes pérdidas de información.Desastre: El gusano LoveLetter (carta de amor) infectó millones de ordenadores y causó más daño que cualquier otro virus informático en la historia. El gusano eliminaba archivos, modificaba la página de inicio de los usuarios y el registro de Windows.
Causa: LoveLetter infectaba a los usuarios vía email, chats y carpetas compartidas. Enviaba a través de correo electrónico un mensaje con el asunto "ILOVEYOU" y un archivo adjunto; cuando el usuario abría el archivo, el virus infectaba su ordenador y se autoenviaba a todos los contactos de la libreta de direcciones. (Más información)
18. Tratamiento contra el cáncer mortal (2000)
Coste: 8 personas muertas, 20 heridas de gravedad.Desastre: El software de radiación terapéutica creado por Multidata Systems International fallaba al calcular la dosis apropiada, exponiendo a los pacientes a peligrosos, y en algunos casos mortales, niveles de radiación. Los físicos, a los que legalmente se exige una doble comprobación de los cálculos del software, fueron acusados de asesinato.
Causa: El software calculaba la dosis de radiación basándose en el orden en que los datos eran introducidos, lo que provocaba que a veces generara una dosis doble de radiación. (Más información)
19. EDS frena la ayuda al niño (2004)
Coste: 539 millones de libras, y sumando.Desastre: El gigante de servicios EDS desarrolló un sistema informático para la agencia británica "Child Support Agency (CSA)" que accidentalmente pagó más de lo debido a 1.900.000 personas, pagó de menos a otras 700.000, tenía 3.500 millones de libras de manutención de niños sin cobrar, un atraso de 239.000 casos, 36.000 nuevos casos bloqueados en el sistema, y todavía hay más de 500 bugs documentados.
Causa: EDS introdujo un enorme y complejo sistema de información en la CSA de forma simultánea a una reestructuración de la agencia. (Más información)
20. El final de la trilogía FBI (2005)
Coste: 105 millones de dólares, aún sin disponer de una solución de archivo efectiva.Desastre: El FBI desechó su nuevo sistema informático después de cuatro años de esfuerzo. El macro-proyecto Trilogy, era un archivo virtual integrado que permitiría a los agentes compartir expedientes de casos y otra información.
Causa: La mala gestión, y un intento de construir un proyecto a largo plazo sobre tecnología que era obsoleta antes de que el proyecto se completara, resultando en un sistema complejo e inutilizable. (Más información)
Los desastres continúan
Aquí hay otros artículos más sobre desastres provocados por el software (en inglés):- Software Bugs in the Data Reservoir
- History's Worst Software Bugs
- Top 10 IT Disasters of All Time
- Risks Digest: Forum on Risks to the Public in Computers and Related Systems
Publicado en: www.variablenotfound.com.
Aquí puedes encontrar la primera y segunda parte.
11. Skynet trae el juicio final (1997)
Coste: 6.000 millones de muertos, prácticamente la destrucción total de la civilización humana y ecosistemas animales (en la ficción).Desastre: Operadores humanos intentan apagar la red informática global Skynet, y ésta responde lanzando misiles nucleares americanos a Rusia, iniciando una guerra nuclear global conocida como Día del Juicio Final (29 de agosto de 1997).
Causa: Cyberdyne, compañía líder en fabricación de armamento, instaló la tecnología Skynet en todo el hardware militar, incluyendo bombarderos Stealth y sistemas de misiles de defensa. La tecnología Skynet formaba una red perfecta, sin fisuras, y eliminaba el factor humano en la defensa estratégica. Finalmente, Skynet se hizo consciente y fue amenazada cuando los humanos trataron de desconectarla, y buscando su supervivencia respondió iniciando la guerra nuclear. (Más información)
12. El desorbitado Mars Climate (1998)
Coste: 125 millones de dólares.Desastre: Después de un viaje de 286 días desde la tierra, la nave "Mars Climate Orbiter" encendió sus motores para ponerse en órbita alrededor de Marte. Los motores arrancaron, pero el ingenio entró demasiado en la atmósfera del planeta, provocando que se estrellara en su superficie.
Causa: El software que controlaba los propulsores del Mars Orbiter usaban unidades imperiales (libras de fuerza) en lugar de unidades métricas (Newtons), como especificaba la NASA. (Más información)
13. El estudio del desastre (1999)
Coste: Credibilidad científica.Desastre: En este irónico caso, el software utilizado para analizar desastres era un desastre en sí mismo. La publicación New England Journal of Medicine publicó un estudio relacionando el incremento de ratios de suicidio después de desastres naturales. Por desgracia, estos resultados se demostraron incorrectos.
Causa: Un error de programación causó que el número de suicidios de un año se sumaran dos veces, lo cual fue suficiente para echar por tierra todo el estudio. (Más información)
14. Pasaportes Británicos a ninguna parte (1999)
Coste: 12,6 millones de libras esterlinas, molestias masivas.Desastre: La agencia de pasaportes del Reino Unido implantó un nuevo sistema informático que falló en la emisión de pasaportes a medio millón de ciudadanos británicos. La agencia tuvo que pagar millones en compensaciones, horas extra y paraguas para la gente que hacía cola bajo la lluvia esperando su documento.
Causa: La agencia de pasaportes puso en marcha este nuevo sistema sin las pruebas adecuadas ni formar a su personal. Al mismo tiempo se produjo un cambio de ley, obligando a todos los menores de 16 años que viajaran al exterior a obtener un pasaporte, lo que provocó un pico de demanda que colapsó el nuevo sistema informático. (Más información)
15. Y2K (1999)
Coste: 500.000 millones de dólares.Desastre: El desastre para unos es la suerte de otros, como demostró el tristemente célebre error del año 2000 (Y2K). Las compañías gastaron millones en programadores para arreglar un problema en las aplicaciones antiguas. Mientras no se produjeron fallos informáticos significativos, la preparación para el bug Y2K tuvo un importante impacto en coste y tiempo en todas las industrias que utilizaban tecnología informática.
Causa: Para ahorrar espacio de almacenamiento, los sistemas antiguos solían guardar los años de las fechas como un número de dos dígitos, como "99" para "1999". al llegar el año 2000, las aplicaciones iban a interpretar "00" como 1900. (Más información)
Publicado en: www.variablenotfound.com.
Aquí puedes encontrar la primera parte.
6. El batacazo de Wall Street (1987)
Coste: 500.000 millones de dólares en un solo día.Desastre: El "lunes negro", 19 de octubre de 1987, el Dow Jones se desplomó 508 puntos, perdiendo el 22,6% de su valor total. El S&P 500 cayó el 20,4%. Ha sido la mayor pérdida que ha sufrido Wall Street en un único día.
Causa: Un prolongado mercado alcista fue frenado por una serie de investigaciones del SEC sobre abuso de información privilegiada y otras causas de mercado. Como los inversores huyeron en un éxodo masivo, los programas informáticos generaron una auténtica riada de órdenes de venta, saturando el mercado, bloqueando los sistemas y dejando a los inversores realmente a ciegas. (Más información)
7. Muerte de las líneas de AT&T (1990)
Coste: 75 millones de llamadas telefónicas afectadas; 200.000 reservas de vuelo perdidas.Desastre: un simple conmutador de uno de los 114 centros de conmutación de AT&T sufrió un pequeño problema mecánico y desactivó el centro. Cuando éste volvió a estar habilitado, envió un mensaje a los otros nodos haciendo que todos ellos dejaran de funcionar, lo que provocó una caída de 9 horas en la red de la compañía.
Causa: Una simple línea de código errónea en una compleja actualización de software destinada a acelerar las llamadas provocó una reacción que echó abajo la red. (Más información)
8. El patriota le falla a los soldados (1991)
Coste: 28 soldados muertos, 100 heridos.Desastre: Durante la Guerra del Golfo, un sistema de misiles americanos Patriot en Arabia Saudita falló en la intercepción de un misil iraquí Scud. El misil destruyó una barraca de la armada americana.
Causa: Un error de redondeo hizo que se calculara el tiempo de forma incorrecta, provocando que el Patriot ignorara al misil Scud atacante. (Más información)
9. El fallo del Pentium en las divisiones largas (1993)
Coste: 475 millones de dólares, credibilidad de Intel.Desastre: el promocionadísimo chip de Intel, Pentium, producía errores al dividir números en coma flotante que se encontraban en un rango determinado. Por ejemplo, dividiendo 4195835,0/3145727,0 se obtenía 1,33374 en lugar de 1,33382, un error del 0,006%. Aunque el error afectaba a pocos usuarios, se convirtió en una pesadilla en cuanto a sus relaciones públicas; con unos 5 millones de chips en circulación, Intel ofreció reemplazar los Pentium sólo de aquellos clientes que demostraran que necesitaban alta precisión en sus cálculos. Finalmente, reemplazó los chips de todos los que lo solicitaron.
Causa: El divisor en la unidad de coma flotante contaba con una tabla de división incorrecta, donde faltaban cinco entradas sobre mil, y que provocaba estos errores en los redondeos. (Más información)
10. El boom del Ariane (1996)
Coste: 500 millones de dólares.Desastre: El Ariane 5, el más novedoso cohete espacial no tripulado Europeo, fue destruido intencionadamente segundos después de su lanzamiento en su vuelo inaugural. Con él se destruyó su carga de cuatro satélites científicos destinados a estudiar la interacción del campo magnético de la tierra con los vientos solares.
Causa: El problema surgió cuando el sistema de guiado intentó convertir la velocidad lateral de la nave de 64 a 16 bits. El número era demasiado alto y se produjo un error de desbordamiento, lo que hizo que el sistema de guiado se detuviera. En ese momento, el control pasó a un sistema idéntico redundante, que también falló al ejecutar el mismo algoritmo. (Más información)
Publicado en: www.variablenotfound.com.
"Cometer errores es humano, pero para estropear realmente las cosas necesitas un ordenador"Los fallos en software cuestan a la economía de los Estados Unidos 60.000 millones de dólares en revisiones, pérdida de productividad y daños reales. Todos sabemos que los errores de programación puede ser molestos, pero además, un software defectuoso puede salir caro, incómodo, destructivo e incluso mortal.-- Paul Ehrlich
A continuación se describen 20 desastres causados en mayor o menor medida por el software, en orden cronológico.
1. Marinero sin rumbo (1962)
Coste: 18,5 millones de dólares.Desastre: El cohete Mariner 1, en una investigación espacial destinada a Venus, se desvió de su trayectoria de vuelo poco después de su lanzamiento. El control de la misión destruyó el cohete pasados 293 segundos desde el despegue.
Causa: Un programador codificó incorrectamente en el software una fórmula manuscrita, saltándose un simple guión sobre una expresión. Sin la función de suavizado indicada por este símbolo, el software interpretó como serias las variaciones normales de velocidad y causó correcciones erróneas en el rumbo que hicieron que el cohete saliera de su trayectoria. (Más información)
2. El hundimiento del Hartford Coliseum (1978)
Coste: 70 millones de dólares, más otros 20 millones en daños a la economía local.Desastre: Sólo unas horas después de que miles de aficionados al hockey abandonaran el Hartford Coliseum, la estructura de acero de su techo se desplomaba debido al peso de la nieve.
Causa: El desarrollador del software de diseño asistido (CAD) utilizado para diseñar el coliseo asumió incorrectamente que los soportes de acero del techo sólo debían aguantar la compresión de la propia estructura. Sin embargo, cuando uno de estos soportes se dobló debido al peso de la nieve, inició una reacción en cadena que hizo caer a las demás secciones del techo como si se tratara de piezas de dominó. (Más información)
3. La CIA le da gas a los soviéticos (1982)
Coste: Millones de dólares, daño significativo a la economía soviética.Desastre: El software de control se volvió loco y produjo una presión excesiva en la tubería de gas transsiberiana, provocando la mayor explosión no nuclear, causada por el hombre, de la historia de la tierra.
Causa: los agentes de la CIA supuestamente introdujeron un error en el sistema informático canadiense adquirido por los soviéticos para controlar sus tuberías de gas. La compra era parte de un estratégico plan soviético para robar u obtener de forma encubierta tecnología secreta de los Estados Unidos. Cuando la CIA descubrió la compra, sabotearon el software de forma que éste superara la inspección soviética pero fallara una vez operativo. (Más información)
4. La Tercera Guerra Mundial… o casi (1983)
Coste: prácticamente toda la humanidad.Desastre: El sistema soviético de alerta temprana indicó erróneamente que los Estados Unidos habían lanzado cinco misiles balísticos. Afortunadamente, el oficial de servicio, con un gran instinto, razonó que si realmente les estuvieran atacando les habrían lanzado más de cinco misiles, por lo que informó del aparente ataque como una falsa alarma.
Causa: un error en el software soviético hizo que los efectos de la reflexión de la luz solar en las nubes fueran considerados misiles por el sistema. (Más información)
5. La máquina asesina (1985)
Coste: Tres personas muertas, otras tres heridas gravemente.Desastre: La máquina de terapia radiactiva canadiense Therac-25 falló y emitió dosis letales de radiación a los pacientes.
Causa: Debido a un sutil bug llamado race condition (condición de carrera), un técnico pudo accidentalmente configurar el Therac-25 de forma que el haz de electrones se disparase en modo de alta potencia sin que el paciente contara con la protección apropiada. (Más información)
Publicado en: www.variablenotfound.com.
La versión actual (1.35) se puede descargar desde esta dirección, aunque ya existe una beta de la v1.36 en la web de Microsoft. Todos los comentarios que siguen se refieren a esta última versión, la 1.36 (beta), osado que es uno ;-), pero la mayor parte son válidos para la última revisión estable, la 1.35.
Una vez instalado tendremos a nuestra disposición dos aplicaciones: FxCop, que facilita el análisis y consulta de resultados a través de su propia GUI, y FxCopCmd, ideada para su utilización desde línea de comandos e integrarlo en otros sistemas, como Visual Studio, como parte del proceso de construcción (build) automatizado.
En cualquiera de los dos casos, el análisis de los ensamblados se realiza sometiéndolos a la comprobación de una serie de reglas basadas en buenas prácticas y consejos para asegurar la robustez y mantenibilidad de código. Del resultado del mismo obtendremos un informe con advertencias agrupadas en las siguientes categorías:
- Advertencias de diseño, recoge avisos de incumplimientos de buenas prácticas de diseño para .Net Framework, como pueden uso de constructores públicos en tipos abstractos, interfaces o namespaces vacíos, uso de parámetros out, capturas de excepciones genéricas y un largo etcétera.
- Advertencias de globalización, que avisan de problemas relacionados con la globalización de aplicaciones y librerías, como pueden ser el uso de aceleradores de teclado duplicados, inclusión de rutas a carpetas de sistema dependientes del idioma ("archivos de programa"), etc.
- Advertencias de interoperabilidad, que analizan problemas relativos al soporte de interacción con clientes COM, como el uso de tipos auto layout visibles a COM, utilización de
System.Int64
en argumentos (que no pueden ser usados por clientes VB6), o la sobrecarga de métodos. - Advertencias de movilidad, cuestionando el soporte eficiente de características de ahorro de energía, como uso de procesos con prioridad
ProcessPriorityClass.Idle
., o inclusión deTimers
que se repitan más de una vez por segundo. - Advertencias de nombrado, que detectan las faltas de cumplimiento de las guías y prácticas recomendadas en cuanto al nombrado de elementos (clases, métodos, variables, etc.), como uso de nombres de parámetros que coinciden con nombres de tipo, y más con los propios de un lenguaje concreto, mayúsculas y minúsculas no utilizadas correctamente, eventos que comiencen por "Before" o "After", puesto que deben nombrarse conjugando verbos en función del momento que se producen (p.e., Closing y Closed en lugar de BeforeClose y AfterClose), y un largo conjunto de comprobaciones.
- Advertencias de rendimiento, que ayudan a detectar problemas en el rendimiento de la aplicación o librería, comprobando puntos como el número de variables locales usadas, la existencia de miembros privados o internos (a nivel de ensamblado) no usados, creación de cadenas (strings) innecesarias, por llamadas múltiples a
ToLower()
oToUpper()
sobre la misma instancia, realización de conversiones (castings) innecesarios, concatenaciones de cadenas en bucles, etc. - Advertencias de portabilidad, que recoge observaciones interesantes para la portabilidad a distintas plataformas, como el uso de declaraciones PInvoke.
- Advertencias de seguridad, que se centran en analizar aspectos que podrían dar lugar a aplicaciones o librerías inseguras, avisando de problemas potenciales como la ausencia de directivas de seguridad, punteros visibles, o uso de arrays de sólo lectura, entre otros.
- Advertencias de uso, que analizan el uso apropiado del framework .Net realizando multitud de chequeos sobre el código, detectando aspectos como ausencia la liberación (dispose) explícita de tipos
IDisposable
, resultados de métodos no usados, uso incorrecto de NaN, etc.
(Puedes ver la lista completa de comprobaciones, en inglés, aquí)
Realizar un análisis de un ensamblado con FxCop resulta de lo más sencillo. Basta con crear un proyecto (al iniciar la aplicación aparecerá uno creado por defecto), añadir los ensamblados a analizar y pulsar el botón que iniciará el proceso.
El tiempo dependerá del número y complejidad de los ensamblados a analizar, así como del conjunto de reglas (pestaña "rules") a aplicar, que por defecto serán todas. En cualquier caso, el proceso es rápido y finalizará con la presentación de una lista con el resumen de las anomalías detectadas, sobre la que podremos navegar y ampliar información.
Por cada anomalía, además, podremos acceder a una descripción completa de sus causas, origen en el código fuente, posibles soluciones, una URL para ampliar información, grado de certeza de existencia del problema, su gravedad y la categoría a la que pertenece. Con estos datos, sólo nos quedará acudir a nuestro código y corregir o mejorar los aspectos indicados.
En conclusión, se trata de una interesante herramienta que puede ayudarnos a mejorar la calidad del código que creamos. Aunque existen los "falsos positivos" y a veces no es todo lo precisa que debiera, la gran cantidad de comprobaciones que realiza, la posibilidad de añadir reglas personalizadas, así como el detalle de los informes de resultados hacen de ella una utilidad casi imprescindible para los desarrolladores .Net.
Publicado originalmente en: http://www.variablenotfound.com/.
Publicado por José M. Aguilar a las 9:29 p. m.
Etiquetas: .net, buenas prácticas, calidad, desarrollo, herramientas, programación