Writing Quality Code – La calidad del software y el código fuente

Siempre he
sostenido que la calidad del software empieza por la calidad del código fuente.
Basta observar unas cuantas líneas de código de un proyecto, de unos cuantos
archivos de código elegidos al azar para saber mucho sobre la calidad
del proyecto en general. Es impensable que con código de mala calidad se
pueda construir buen software. Microsoft tiene gente investigando sobre la
relación que existe entre la calidad del software y la calidad del código
fuente y sobre la importancia del código fuente de calidad.

Hay dos
interesante videos en los que se trata el tema:

En el primero,
Khaled El Eman, de la Universidad de Otawa, habla sobre el retorno de la
inversión del código fuente de calidad
. Es curioso como se puede llegar
a cuantificar en unidades monetarias la calidad del código en los proyectos.
Además este autor tiene un libro que parece interesante sobre el tema del video
The
ROI from Software Quality
.

En el software, la
calidad, no es opcional

El problema
que se presenta es que existen empresas, donde  sus jefes no perciben la calidad como algo
importante, es más importante para ellos tener un mayor número de características
que un software de mayor calidad. El razonamiento es simple, la
calidad no se puede poner en un anuncio o en una oferta. Esta mentalidad podría
ser razonable para muchos productos, pero no lo es para el software.
Trataré de explicar el por
qué.

Si tu
produces, por poner algo simple, bolígrafos, puedes decidir que tu segmento del
mercado es el de los bolígrafos baratos, de baja calidad. Y sin duda te puede
ir muy bien, no todo el mundo necesita un pluma Du Pont, para firmar su
hipoteca. Tendrás un motón de clientes que solo ven en el momento de la compra
de un bolígrafo su precio, y que además en el momento de la compra no van a
evaluarlo a fondo. Además, reducir la calidad, en el caso de la gran mayoría de
los productos manufacturados, tiene el efecto directo de abaratar los costos de
producción. Muchos de los directivos actualmente al mando de empresas que
construyen software han sido formados en sectores ajenos a la informática, una
industria muy nueva, y a menudo caen en el error de pensar en la producción de
software desde los parámetros habituales en otras industrias. Este es un error
habitual, la producción de software es muy diferente, es un proceso creativo no
un proceso manufacturero.

La principal
diferencia cuando ‘fabricamos’ software es que la calidad no es
opcional, no puedes elegir fabricar software de baja calidad y rebajar el
precio
.
Ese enfoque no funciona por varios motivos:

Primero:
Puedes hacer bolígrafos de baja calidad que hagan su labor aceptablemente, pero
no puedes hacer software de baja calidad que funcione y cumpla su misión
aceptablemente. Además, los usuarios cada vez son menos tolerantes con los
errores en las aplicaciones. Pensemos en cómo ha evolucionado la calidad del
software que todos tenemos en común, el sistema operativo. Todos recordamos las
pantallas azules de la muerte de Windows NT, alguna vimos en 2000 y luego llego
Windows XP y la mejora fue notable. Lo mismo ha ocurrido en otros sistemas
operativos, como Linux, donde cada vez es más difícil ver un Kernel Panic. Al
ser el sistema operativo el software que todos usamos, es el que se convierte
en patrón
de calidad

Con Windows
95 no era importante que nuestros programas ‘cascasen’ con cierta frecuencia,
el usuario estaba acostumbrado a que el sistema operativo fallase y era más o
menos permisivo con nuestros fallos. Con la mejora de la calidad de los sistemas
operativos el usuario está subiendo el listón de la calidad y si queremos
seguir vendiendo nuestro software más que el de la competencia la calidad del
mismo se está convirtiendo en un factor vital.

Segundo:
Antes de comprar un software o contratar la realización del software con una compañía
de desarrollo, el usuario comparará a fondo. Y a menudo el precio no es el
factor principal. Nunca venderemos un software si el instalador de nuestra demo
falla con solo ejecutarlo con un usuario que no es administrador, por m
ás
barato que sea, el usuario no se va a tomar un segundo más en seguir
evaluando nuestro software. Ni venderemos un proyecto de desarrollo si a los oídos
del comprador llega una mala experiencia de una empresa que nos contrato con
anterioridad, por  más económica que sea
nuestra oferta. Solo centrándonos en la calidad lograremos evitar este tipo de
problemas. Nadie recuerda quien hizo un buen software, pero nadie olvida quien
hizo uno que no funciona correctamente porque lo sufre a diario.

Tercero: Quizá
el factor más importante y menos evidente es el de  añadir calidad a nuestro software, al
contrario de lo que puede parecer a primera vista, reduce los costes de
desarrollo y acorta los plazos. La reducción de costes se produce con un
adecuado proceso de desarrollo, que tenga la calidad del software como un
factor central, y se descubren antes los errores. Y los errores, de cualquier índole,
son más costosos cuanto más tarde se descubren, además estos coste se
incrementan siguiendo una función exponencial. Descubrir que nuestra Arquitectura
no es capaz de gestionar el número requerido de transacciones por segundo, es
infinitamente más costoso de corregir si se descubre durante las pruebas de
aceptación que durante la revisión de la arquitectura. La reducción del tiempo
de desarrollo se produce porque es mucho más fácil construir software sobre
software estable que sobre software que no es estable. Hoy en día todos los
procesos de desarrollo de software son en mayor o menor medida iterativos e
incrementales. Es imposible construir un incremento de funcionalidad si la base
de ese incremento no es estable.

Dicho esto,
es curioso ver las situaciones paradójicas que se dan en cuanto a la calidad en
los proyectos y las empresas de desarrollo de software.
Existen empresas con grandes carteles en recepción del estilo "La
calidad es nuestra esencia"
o "La calidad al servicio
del cliente
" y con todas las certificaciones habidas y de por haber de
‘calidad’ que no tienen ni un solo especialista en calidad del software, ni un
solo especialista en probar aplicaciones. ¿Se imaginan una empresa industrial,
que se tome en serio el mantenimiento de sus maquinas, sin un solo experto en
mantenimiento?, pues esto es la norma en las empresas de desarrollo, dicen
preocuparse por la calidad pero no cuentan con un solo experto en el tema. Y
no, lo desarrolladores, no son expertos en calidad y pruebas. ¿Por qué se dan
estas paradojas en el desarrollo de software?

"La
manera más rápida y económica de desarrollar software es hacerlo bien".

Creo que
mientras quien este al mando de las empresas de desarrollo no hayan sido
previamente desarrolladores la situación no cambiará. Construir software es
algo radicalmente diferente a construir cualquier otro producto, pero los
gestores ser resisten a verlo. Por eso seguimos sufriendo intentos fallidos de
formalizar el desarrollo de software, como RUP
o CMMI, sin dejar parcela a la
creatividad. Se tiende al olvidar que desarrollar software es esencialmente ‘diseño’
y no ‘construcción’. Cada línea de código que escribe un desarrollador en una
decisión de diseño.

La crisis de
software se da en dos puntos:

-el
programador conformista (nunca se pregunta como optimizar o mejorar lo que hace,
solo si funciona, dejémoslo así).

-el jefe que
sabe más chatear que de arquitectura de software.

Temas Relacionados:

Guidelines for Conducting Design and Code Reviews

Proporciona
varias técnicas para realizar la revisión del diseño y del código a fin de
descubrir errores y supuestos incorrectos solicitando a sus homólogos que
revisen el código.

Guidelines for Writing Secure Code

Describe
técnicas y estrategias para escribir código seguro.

Guidelines
for Checking in Quality Code

Muestra
instrucciones para comprobar el código de maneras diferentes a fin de
garantizar que incorpora lo que estaba previsto en el diseño de calidad.

Guidelines for Debugging

Proporciona
varias instrucciones para encontrar defectos de código.

Guidelines
for Using Code Analysis Tools

Proporciona
varias instrucciones para utilizar las herramientas de análisis de código.

Detecting
and Correcting C/C++ Code Defects

Describe cómo
detectar y corregir defectos de código utilizando la herramienta de análisis de
código para C/C++.

Detecting
and Correcting Managed Code Defects

Describe cómo
detectar y corregir defectos de código utilizando la herramienta de análisis de
código para código administrado.

Code Analysis Check-in Policies

Describe cómo
crear directivas de protección personalizadas asociadas con las protecciones de
control de código fuente de Team Foundation.

Code Analysis for Managed Code Overview

La
herramienta de análisis de código para el código administrado analiza los
ensamblados administrados y muestra información sobre dichos ensamblados, como
las infracciones de las reglas de programación y diseño estipuladas en las
Instrucciones de diseño de Microsoft .NET Framework.

 Integración del entorno de desarrollo integrado
(IDE)

Para que el
uso de la herramienta de análisis resulte más cómodo a los desarrolladores,
éstos pueden seleccionar Habilitar análisis de código en
las Páginas de propiedades del proyecto.

Desde las
páginas de propiedades se puede tener acceso, además, a otras opciones para
incluir o excluir reglas, así como para tratar las reglas como advertencias o
errores. Cuando la herramienta está habilitada, registra las advertencias en la
Lista de errores durante el proceso de generación.

Supresión en el código fuente

Con
frecuencia resulta de gran utilidad indicar que una advertencia no es de
aplicación; de este modo, se informa al desarrollador (y a otras personas que
puedan revisar el código más adelante) de que se ha investigado ya una
advertencia y que se ha suprimido u omitido.

La supresión
de advertencias en el código fuente se implementa mediante atributos
personalizados. Para suprimir una advertencia, agregue el atributo SuppressMessage al código fuente como se muestra en el
ejemplo siguiente:

[SuppressMessage("AdventureWorks.Rules",
"AW14441")]

Public class MyClass

{

    // code

}

Integración
de Team System y Team Build

Puede
utilizar las características integradas del sistema de generación para ejecutar
la herramienta de análisis como parte del proceso de generación.

Conclusión:

Utilice las
herramientas de análisis de código.

Realice una
revisión de seguridad.

Valide todos
los datos introducidos por los usuarios.

Valide
perfectamente todos los parámetros de las interfaces de programación de
aplicaciones (API) exportadas.

 Utilice las API criptográficas de Windows.

Escriba pruebas unitarias.

Conozca cómo
recuperar una pila dañada.

Se debe evitar

Las
saturaciones del búfer.

Las
características sin una especificación.

Suponer que
las pruebas encontrarán todos los errores.

Se
recomienda

Revise todos
los defectos de seguridad anteriores de la aplicación.

Revise todas
las rutas de acceso a errores.

Escriba las
pruebas unitarias antes de escribir el código.

Escriba
código portable a otras plataformas.

Recorra paso
a paso todas las rutas de acceso de código en un depurador.

Aprenda a
depurar aplicaciones multiproceso.

Aprenda a
realizar depuraciones remotas.

Aprenda a
depurar en servidores activos.

Analice el
código que se está desarrollando.

Realice el
seguimiento de las advertencias

No se
recomienda

Privilegios
de administrador para que se ejecute la aplicación.

About justindeveloper

I am MCP (Microsoft Certified Professional). MCTS (Microsoft Certified Technology Specialist) and MCPD (Microsoft Certified Professional Developer), also I am SAP Business One Certified!! Desarrollando desde el IDE de Visual Studio NET 2003 hasta ahora con el Visual Studio NET 2010. Desde Microsoft SQL Server 2000 hasta ahora con el Microsoft SQL Server 2008 R2 y tambien con SharePoint, desde WSS 3.0 y MOSS 2007 y ahora familirizandome con el Sharepoint Foundation 2010 & Sharepoint Server 2010. The software development will follow being every time more wonderful!
This entry was posted in Development. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s