PARA LA CONSTRUCCION DE

SOFTWARE

Introducci
Definicin n
Por buenas prcticas se entiende un conjunto
coherente de acciones que han rendido buen o incluso
excelente servicio en un determinado contexto y que
se espera que, en contextos similares, rindan similares
resultados.
stas dependen de las pocas, de las modas y
hasta de la empresa consultora o del autor que las
preconiza.
No es de extraar que algunas sean incluso
contradictorias entre ellas.
(Fuente: wikipedia)

Porqu se desarrolla mal?

Falta de tiempo.
Falta de conocimiento.
Falta de motivacin.
Acudir a las fuentes
Fallos enequivocadas.
las etapas iniciales de desarrollo de
software (anlisis, requisitos, etc.).

Porqu buenas prcticas?

Establece reglas.
Aporta orden al cdigo.
Estandariza el desarrollo.
Fcil lectura y Fcil mantenimiento.
Facilita la reutilizacin.

Principios de buena
Programacin

Listado de los Principios

No repetirse a si mismo
No repetirse a s mismo evitar la repeticin.
Evitar la repeticin en todas sus posibilidades:
No repetir cdigo: funciones, mtodos, clases,
etc. Reutilizar.
No repetir libreras.
No repetir documentacin.
En general: NO REPETIR
CONOCIMIENTO.

Principio de Abstraccin
Principio de abstraccin. Cada pieza de
funcionalidad significativa en un programa debe ser
implementada en un slo lugar del cdigo fuente

Mantengalo Simple

Mantngalo simple: La mejor solucin

a un problema es la ms simple.
Menos cdigo menos errores.

Evitar la creacin de UNVNE

UNVNE (Usted no va necesitar esto): Evitar crear

algo que no vamos a necesitar. Es comn tratar de
ver el futuro y comenzar a crear abstracciones que
todava no estamos usando.
Se pierde tiempo al aadir, probar y documentar la
funcionalidad no necesaria.
Si la nueva caracterstica no est bien definida,
puede que no funcione correctamente, aunque con el
tiempo sea necesaria.
El software se hace ms grande y ms complicado
innecesariamente.

Hacerlo Simple
Haga lo ms simple que funcione.
r:

No me haga pensar

No me haga pensar. Evitar la pregunta y ahora,

cmo lo hago? Los nombres de las funciones,
variables, etc. deben declarar claramente lo
que hacen.

Principio de Abierto/Cerrado
Principio Abierto/Cerrado. Clases, mdulos,
funciones, etc. deben estar abiertas a la extensin.
Escribir clases, no para que otros las modifiquen,
sino para que se usen y extiendan.
Beneficios del principio
Abierto/Cerrado :
Robustez No se modifican las clases ya
probadas.
Flexibilidad Se facilita la implementacin de
nuevos requisitos o cambios en ellos.
Facilita las pruebas menos propenso a
errores.

Escriba cdigo para mantenerlo

Escriba cdigo pensando en el que va a
mantenerlo. Escriba el cdigo como si el que tuviera que
mantenerlo fuera un psicpata asesino que conoce donde
vives.

Principio del menor asombro

Principio del menor asombro. Ejemplo: el
nombre de una funcin debera corresponder con lo
que hace.

Principio de responsabilidad nica

Principio de responsabilidad nica. Un
componente de cdigo debe ejecutar una nica y
bien definida tarea.

Minimizar el acoplamiento
Minimizar el acoplamiento. Cada componente
(bloque de cdigo, clase, funcin, etc.) debe
minimizar las dependencias de otros
componentes.

Maximizar cohesin
Maximizar cohesin. Evitar implementar en un
componente dos funcionalidades que no estn
relacionadas, cumpliendo tareas que no tienen
relacin.

Evitar la optimizacin prematura

Evitar la optimizacin prematura. Evitar pensar
optimizar cdigo, si apenas lo estamos armando. Ir
armando el cdigo de tal forma que podamos
refactorizarlo.

Abraza el cambio
Abraza el cambio. El cambio es inevitable en el
desarrollo de software. No hay que luchar contra el
cambio, sino trabajar para estar preparado para l
Programacin gil, integracin continua, Scrum,
etc.

Buenas prcticas en
Convencin
de
Cdigo
para
qu?
cdigo
Alto % del coste del software mantenimiento.
Casi ningn software se mantiene durante toda
su por el autor original.
vida
Mejora la legibilidad del software, permitiendo a los
ingenieros a entender el nuevo cdigo con mayor
rapidez y en profundidad.
Cdigo fuente es igual que cualquier otro producto
asegurarse de que est tan bien empaquetado y
limpio como cualquier otro producto.

Ejemplos Convencin de Cdigo

En clases e Interfaces
Para programar Clases e Interfaces en Java:
Sin espacios entre el nombre de un mtodo y
el parntesis (.
La llave { debe aparecer al final de la lnea y
en la misma lnea que la declaracin.
La llave } empieza una lnea por s misma,
indentada con la lnea que contiene la llave {.

En Comentarios
Tres tipos de comentarios:
Bloque
Una sola lnea

Arrastrar al final de la lnea

Buenas
Programacin:
Errores
comunes
prcticas
Fiabilidad de los parmetros de entrada: No
asegurarse de que los parmetros recibidos son los
que esperamos.
Fiabilidad de los valores: No comprobar si un
elemento tiene valor antes de acceder a l.
Elementos en colecciones: No asegurar se de
que un array o coleccin tenga valor y contenga
elementos antes de acceder a ellos.
No comentar. (Sin comentarios...).

Programacin: Errores comunes

Acceso a colecciones: No comprobar si existe
elemento para un ndice antes de acceder a l en
una coleccin indexada.
No liberar recursos adecuadamente.
Recursividad: El mtodo recursivo infinito.
Malas prcticas: Utilizar incorrectamente
tcnicas
conocidas.

Consejos generales
Seguir estndares.
Seguir patrones de diseo.
Reutilizar cdigo No reinventar la rueda.
Usar libreras reconocidas, documentadas, etc.
Ejemplo: Apache Commons
Test unitarios.
Conocer bien nuestro entorno de desarrollo (IDE):
shortcuts, plugins, etc.

Consejos generales
Refactorizacin: Tcnica de ingeniera de
software para reestructurar cdigo fuente, alterando
su estructura interna sin cambiar su
comportamiento externo.
Comentar de forma completa pero no excesiva.
Seguir buenas prcticas del Framework
elegido. Nombrar con sentido las clases,
variables, etc.

Consejos generales
Leer cdigo ajeno. Que otros lean t cdigo.
Pautas para leer cdigo de una manera efectiva:
Tener en cuenta el rendimiento: El rendimiento
de nuestras aplicaciones es tan importante como
otros criterios de aceptacin. Criterios a tener en
cuenta para medir el rendimiento:
Recursos hardware del cliente.
Realizar pruebas de rendimiento en un
entorno
que
simule el hardware mnimo aceptado.
Hacer pruebas REALES.

Buenas

Consejos generales
Comparte prcticas
conocimiento. Wiki, blogs, reuniones,
charlas, etc.

Buenas prcticas para la

construccin de software

FIN