3.

Medición de la construcción

Se pueden medir numerosas actividades de construcción y artefactos, incluido el código

desarrollado, el código modificado, el código reutilizado, el código destruido, la complejidad
del código, las estadísticas de inspección de código, las tasas de corrección y falla, el esfuerzo
y la programación. Estas mediciones pueden ser útiles para los fines de administrar la
construcción, garantizar la calidad durante la construcción y mejorar el proceso de
construcción, entre otros usos.(McConnell, 2004, p.587).

3.1 Estrategias de ajuste de código

3.1.1Resumen de rendimiento

Creemos que cuanto mejor hagamos el código, más les gustará a los clientes, sin embargo
McConnell (2004) nos menciona que “los usuarios están más interesados en las
características tangibles del programa que en la calidad del código.” (p.558), a veces los
usuarios están interesados en el rendimiento en bruto, pero solo cuando afecta a su trabajo.

Los usuarios tienden a estar más interesados en el rendimiento del programa que en el
rendimiento en bruto. La entrega de software a tiempo, la provisión de una interfaz de usuario
limpia y la evitación del tiempo de inactividad suelen ser más importantes.(McConnell, 2004,
p. 589).

Elegimos la eficiencia como una prioridad, ya sea que se ponga énfasis en la velocidad o
en el tamaño, debe considerar varias opciones antes de elegir mejorar la velocidad o el
tamaño en el nivel de código. (McConnell, 2004, p. 589).

Pensando en la eficiencia tenemos diferentes puntos de vista:

- Requisitos del programa, el rendimiento se establece como un requisito mucho más a

menudo de lo que realmente es un requisito.

- Diseño del programa, según McConnell (2004)”el diseño del programa incluye los
principales trazos del diseño para un solo programa, principalmente la forma en que un
programa se divide en clases.”(p. 589), esto hace difícil escribir un sistema de alto
rendimiento y otros hacen difícil no hacerlo.
 Para cumplir con los objetivos de tamaño y velocidad establecemos objetivos de recursos
para subsistemas, características y clases individuales esto ayudará de diferentes maneras:

- El establecimiento de objetivos de recursos individuales hace que el rendimiento

máximo del sistema sea predecible.

- Hacer objetivos explícitos mejora la probabilidad de que se alcancen.

- Los programadores trabajan para los objetivos cuando saben lo que son, McConnell
(2004) “Cuanto más explícitos sean los objetivos, más fácil será trabajarlos.”(p. 590)
- Puede establecer objetivos que no alcanzan la eficiencia directamente, pero
promueven la eficiencia a largo plazo.

3.1.1.1 Diseño de clase y rutina.

McConnell (2004) nos dice: “el diseño de los aspectos internos de las clases y las rutinas
presenta otra oportunidad para diseñar para el rendimiento.”(p.590) ya que el rendimiento
entra en juego la elección de los tipos de datos y los algoritmos, que generalmente afectan el
uso de la memoria del programa y la velocidad de ejecución.

3.1.1.2 Interacciones del sistema operativo

Si el programa funciona con archivos externos, memoria dinámica o dispositivos de salida,

probablemente esté interactuando con el sistema operativo. Si el rendimiento no es bueno,
podría ser porque las rutinas del sistema operativo son lentas o pesadas. Es posible que no
sepa que el programa está interactuando con el sistema operativo; a veces su compilador
genera llamadas al sistema o sus bibliotecas invocan llamadas al sistema con las que nunca
soñaría. (McConnell, 2004, p. 591)

3.1.1.3 compilaciones de código

Los buenos compiladores convierten el código de lenguaje claro y de alto nivel en un

código de máquina optimizado. Si elige el compilador correcto, es posible que no necesite
pensar más en optimizar la velocidad. Los resultados de optimización proporcionan
numerosos ejemplos de optimizaciones de compiladores que producen un código más
eficiente que el ajuste manual de códigos. (McConnell, 2004, p. 591)
 3.1.1.4 Hardware

McConnell (2004)” La forma más barata y mejor de mejorar el rendimiento de un

programa es comprar hardware nuevo.”(p. 591), comprar hardware nuevo no es una opción
realista, pero se desarrolla software personalizado para unos pocos usuarios, una
actualización de hardware podría ser la opción más barata.

3.1.1.5 Ajuste de código

Es la práctica de modificar el código correcto de manera que se ejecute de manera más

eficiente. "Ajuste" se refiere a los cambios a pequeña escala que afectan a una sola clase, una
sola rutina o, más comúnmente, unas pocas líneas de código. “Ajuste” no se refiere a cambios
de diseño a gran escala u otros medios de alto nivel para mejorar el rendimiento. (McConnell,
2004, p. 592).

3.1.2 Introducción a la optimización de código

Podemos darnos cuenta de lo que nos menciona McConnell (2004) “Reducir las líneas de
código en un lenguaje de alto nivel mejora la velocidad o el tamaño del código de máquina
resultante, ¡falso!”(p.593), ya que muchos programadores se aferran a la creencia de que si
pueden escribir código en una o dos líneas, será lo más eficiente posible.

Observemos esta matriz de 10 elementos:

For i = 1 to 10

a[ i ] = i

End for

La pregunta que nos podemos plantear sería estas líneas son más rápidas o más lentas que
las siguientes 10 líneas que nos permiten hacer el mismo trabajo?

a[ 1 ] = 1

a[ 2 ] = 2

a[ 3 ] = 3

a[ 4 ] = 4
 a[ 5 ] = 5

a[ 6 ] = 6

a[ 7 ] = 7

a[ 8 ] = 8

a[ 9 ] = 9

a[ 10 ] = 10

Según “Las pruebas en Microsoft Visual Basic y Java han demostrado que el segundo
fragmento es al menos un 60% más rápido que el primero.”(p.593) Aquí están los números:

Tabla 01:
Las pruebas en Microsoft Visual Basic y Java

Nota: Recuperado de McConnell, 2011, Code complete, p.593.

Esto ciertamente no implica que aumentar el número de líneas de código de idioma de alto
nivel siempre mejore la velocidad o reduzca el tamaño. Implica que, independientemente del
atractivo estético de escribir algo con el menor número de líneas de código, no existe una
relación predecible entre el número de líneas de código en un lenguaje de alto nivel y el
tamaño y la velocidad finales de un programa.(McConnell, 2004, p. 594).

3.1.3 Clases

Fuentes comunes de ineficiencia, aquí hay varias fuentes comunes de ineficiencia:

- Operaciones de entrada / salida

- Fuentes de ineficiencia entrada / salida innecesaria.
 Aquí hay una comparación de rendimiento que nos proporciona McConnell (2010)
entre el código que accede a elementos aleatorios en una matriz de 100 elementos en
memoria y el código que accede a elementos aleatorios del mismo tamaño en un
archivo de disco de 100 registros:

Tabla 02:
Código que accede a elementos aleatorios

Nota: Recuperado de McConnell, 2011, Code complete, p.598.

Según estos datos, el acceso en memoria es del orden de 1000 veces más rápido
que el acceso a datos en un archivo externo. De hecho, con el compilador de C ++

Tabla 03:

Comparación de rendimiento para una prueba similar de tiempos de acceso

secuencial

Nota: Recuperado de McConnell, 2011, Code complete, p.598.

3.1.4 Medición

Debido a que las partes pequeñas de un programa usualmente consumen una parte
desproporcionada del tiempo de ejecución, se mide el código para encontrar los puntos
calientes. Una vez que haya encontrado los puntos calientes se haya optimizado, se mide el
código nuevamente para evaluar cuánto lo ha mejorado.(McConnell, 2004, p. 606)
 3.1.5 Resumen del enfoque para el ajuste de código

McConnell (2004, p. 606), nos menciona que se debe seguir los siguientes pasos para
considerar si la optimización de código puede ayudar a mejoras el rendimiento de un
programa:

a) Desarrollar el software utilizando un código bien diseñado que sea fácil de entender y
modificar.

b) Si el rendimiento es pobre:

- Guarde una versión de trabajo del código para que pueda volver al "último estado
bueno conocido".
- Medir el sistema para encontrar puntos calientes.
- Determine si el rendimiento débil proviene de un diseño, tipos de datos o algoritmos
inadecuados y si el ajuste del código es apropiado.
- Afine el cuello de botella identificado en el paso (c).
- Mida cada mejora una a la vez.
- Si una mejora no mejora el código, vuelva al código guardado en el paso (a).

3.2 Estrategias de ajuste de código

3.2.1 Gestión de la configuración

McConnell (2004)” un proyecto de software es dinámico ya que el código cambia, el

diseño cambia y los requisitos cambian” (p. 664), entonces los cambios en los requisitos
llevan a más cambios en el diseño y los cambios en el diseño llevan a más cambios en el
código y los casos de prueba.

La gestión de la configuración es la práctica de identificar los artefactos del proyecto y

manejar los cambios sistemáticamente para que un sistema pueda mantener su integridad a lo
largo del tiempo.
 3.2.2 Estimación de un cronograma de construcción

McConnell (2004, p. 671), nos hace mención que se puede estimar el tamaño de un
proyecto y el esfuerzo requerido para completarlo en cualquiera de varias maneras:

- Utilizar software de estimación.

- Utilice un enfoque algorítmico haga que expertos externos en estimación estimen el
proyecto.
- Tenga una reunión de visita para las estimaciones.
- Estimar piezas del proyecto y luego sumarlas.
- Haga que las personas calculen sus propias tareas y luego sumen las estimaciones de
las tareas.
- Consulte la experiencia en proyectos anteriores.
- Mantenga las estimaciones anteriores y vea qué tan exactas eran. Utilízalos para
ajustar

3.2.3 Medición

Se puede recopilar la mayoría de estas mediciones con las herramientas de software que
están disponibles actualmente. La mayoría de las mediciones no son útiles para hacer
distinciones finas entre programas, clases y rutinas. Son útiles principalmente para identificar
rutinas que son "valores atípicos"; las mediciones anormales en una rutina son una señal de
advertencia de que debe reexaminar esa rutina, verificando la calidad inusualmente
baja.(McConnell, 2004, p. 680)

3.2.4 Tratando a los programadores como personas

La abstracción de la actividad de programación exige una naturalidad compensadora en el

entorno de oficina y contactos ricos entre compañeros de trabajo. Las compañías altamente
técnicas ofrecen campus corporativos, estructuras organizativas orgánicas, oficinas
confortables y otras características ambientales de "alto contacto" para equilibrar la
intelectualidad intensa, a veces árida, del trabajo en sí. Las empresas técnicas más exitosas
combinan elementos de alta tecnología y alto contacto.(McConnell, 2004, p. 680).
 3.2.5 Administrando a su gerente

Si su gerente es más típico, se enfrenta a la tarea poco envidiable de administrar su

gerente. "Administrar a su gerente" significa que debe decirle a su gerente qué hacer en lugar
de hacer lo contrario. El truco es hacerlo de una manera que le permita a su gerente continuar
creyendo que usted es el único que está siendo administrado. Aquí hay algunos enfoques para
tratar con su gerente.(McConnell, 2004, p. 686)

Algunas ideas basadas en McConnell:

- Eduque a su gerente sobre la manera correcta de hacer las cosas. Este es un trabajo
continuo porque los gerentes a menudo son promovidos, transferidos o despedidos.

- Concéntrese en los intereses de su gerente, haciendo lo que realmente quiere que haga, y
no distraiga a su gerente con detalles de implementación innecesarios. (Piense en ello como
"encapsulación" de su trabajo.)

- Rechace hacer lo que su gerente le dice e insista en hacer su trabajo de la manera

correcta.

- Encuentra otro trabajo.

 Referencias para copiar

McConnell, S. (2004). Code complete (2nd ed). Redmond, Wash: Microsoft Press.