 Iñaki Elcoro ielcoro@consultec.

es
 Frank Torres ftorres@consultec.es

Prácticas
recomendadas
para codificar
software

Consultec, S.L.
Bilbao – Donostia San Sebastián – Madrid – Pamplona – Santander – Vitoria Gasteiz
 Qué esperamos que se aprenda con esta
charla

Sólo se espera conseguir un objetivo

QUE PROGRAMEMOS MEJOR

teniendo unas pocas reglas en mente mientras programamos,

produciremos código de mucha más calidad,
y por lo tanto,
más legible,
más reutilizable
y menos susceptible a fallar y a generar errores de seguridad

2
 ¿Qué vamos a explicar para llegar a la
conclusión de cuáles son las prácticas más
recomendadas?

Errores de programación más comunes

¿Cómo crear hábitos de buena programación?
KISS - Cómo aplicarlo
YAGNI - Cómo aplicarlo
No nos olvidemos del rendimiento
Reducción de dependencias
Control de la seguridad
Gestión de Errores
Reutilización

3
 Los 10 errores que más hemos visto en
nuestra experiencia en la programación

0000 - No asegurarse de que los parámetros 0110 - División por 0 / NaN

recibidos son los que esperamos

0001 - No comprobar si un elemento tiene 0111 - Convertir cadenas a números

valor antes de acceder a él directamente

0010 - No asegurarse de que un array o 1000 - No liberar los recursos adecuadamente

colección tenga valor y contenga elementos
antes de acceder a ellos

0100 - No comentar 1001 - El método recursivo infinito

0101 - No comprobar si el índice del elemento 1010 - Utilizar incorrectamente técnicas

existe antes de acceder a él en una colección conocidas
indizada

4
 0000 - No asegurarse de que los parámetros
recibidos son los que esperamos

Los parámetros recibidos por una función o método marcada como «pública», es decir
expuesta al mundo exterior, nunca son confiables.

public double MetodoExpuesto(int nuncaMenorQue4, int nunca0) {

return nuncaMenorQue4 / nunca0 ;
}

public static void Main

{
MetodoExpuesto(2, 0);
//El método fallará después de ejecutarse
}

public void PublicarNoticia(Noticia noticia, int importancia)

{
if (noticia == null) throw new ArgumentNullException(«El parámetro noticia no
puede ser nulo»);//Aquí publicar la notica
}

5
 0001 - No comprobar si un elemento tiene
valor antes de acceder a él

Una fuente de errores muy común que una vez avanzados en el desarrollo es muy costoso
de solucionar es acceder a los elementos sin antes comprobar si tienen un valor.

Bar foo = GetFooBar();

//utilizar foo sin comprobar fallará si GetFooBar devuelve null
foo.ToString();

En este caso si foo no tiene un valor la ejecución de este código fallará. Hay que recordar
siempre comprobar el valor de un elemento antes de acceder a él.

Bar foo = GetFooBar();

//Comprobar que foo tiene un valor antes usarlo
if (foo != null)
foo.ToString();

6
0010 - No asegurarse de que un array o
colección tenga valor y que sus elementos
tengan valor antes de acceder a ellos

List<int> numeros = ObtenerNumeros();

//Si numeros es null o numeros no tiene elementos este código fallará

txtNumero1.Text = numeros[0].ToString();
txtNumero2.Text = numeros[1].ToString();

7
 0100 - No comentar

Comentar el código también es programar. Es por eso que dentro de la sintaxis de cada
lenguaje de programación hay caracteres o comandos específicos que permiten poner
comentarios al código

[Ejemplo - Samples]

Los comentarios no deben explicar una funcionalidad completa.

Su principal función es comentar aquél código que no pueda explicarse por sí mismo: tanto
los identificadores -por no poder explicar del todo en la declaración su objetivo- como el
código que es complicado o poco legible por necesidad.

8
 0101 - No comprobar si el índice del
elemento existe antes de acceder a él en una
colección indizada
Antes de acceder a un elemento de una colección indizada debemos siempre comprobar si
la colección tiene al menos el número de elementos que necesitamos.

Este ejemplo de abajo es candidato ideal a fallar:

for (int i = 0; i < CargarEmpresas().Rows.Count - 1; i++)

{
if (CargarEmpresas().Rows[i]["PaginaWeb"].ToString()=="")
GridView1.Rows[i].Cells[7].Visible = false;
}

Solución: comprobar
for (int i = 0; i < CargarEmpresas().Rows.Count - 1; i++)
{
// si gridView.rows.count > i, podemos acceder al índice "i"
// a menos que la lista de empresas pueda variar entre bucles
// no se necesita comprobar la cantidad de empresas
...
}

9
 0110 - División por 0 / Infinite

Antes de realizar cualquier división, debemos tener en cuenta que el divisor nunca puede
ser 0, en cuyo caso el programa siempre terminará con un error por división por 0. No sólo
deberíamos controlar la situación sino decidir cuál debe de ser el comportamiento del
programa en dicho caso, en el siguiente ejemplo el programa decide devolver 0 siempre
que suceda este caso

Nota: en algunos lenguajes de programación, como c#, existen tipos de datos que representan esta
situación como un valor más, en concreto el valor Infinito. En estos casos debemos tener en cuenta dicha
posibilidad y tratarla de forma correspondiente
... valor es un parámetro decimal ...

if (valor == 0)
return 0;

decimal resultado = 10 / valor; ... valor es un parámetro double...

return resultado; double result = 10 / valor;

if (Double.IsInfinity(result))
return 0;
else
return result;

10
 0111 - Convertir cadenas a números
directamente

Cuando se trabaja con cadenas que “sabemos” almacenan números, es incorrecto

convertir directamente su contenido a un número.

string strNumero = txtNumero.Text;

int numero = Convert.ToInt32(strNumero);

Debemos tratar la cadena para asegurarnos de que su contenido es un número antes de

obtenerlo, es decir, debemos “parsear” la cadena primero

int numero = 0;

if (Int32.TryParse(strNumero, out numero)){

//continuar sabiendo que es un número
}

11
 1000 - No liberar los recursos
adecuadamente

Un error común es utilizar objetos que abren recursos externos y no asegurarse de cerrar
dichos recursos correctamente. En el ejemplo siguiente se puede observar que si el código
que utiliza la conexión falla la conexión nunca será cerrada:

void EjemploObtenerOGuardarDatos()
{
var cnn = new SqlConnection(cnnString);
cnn.Open();

//usar la conexión

cnn.Close();
}

Debemos asegurarnos de capturar los errores que genere el uso de los recursos externos y
si se produce un error o terminamos de trabajar con ellos, liberar los recursos (en .NET es
recomendable usar bloques finally, o bloques using)
using (cnn = new SqlConnection(cnnString);
{
//usar la conexión, en caso de que falle el recurso es liberado
}

12
 1001 - El método recursivo infinito

En programación un patrón muy habitual es utilizar recursividad. Aunque muy útil en todos los
escenarios, a menudo se comete el mismo fallo: no poner un límite a las llamadas recursivas.

static long LastFibonacciNumber(long anterior1, long anterior2)

{
long numero = anterior1 + anterior2;

Console.Write(numero + " ");

numero = LastFibonacciNumber(anterior2, numero);

return numero;
}

Para evitar el tan conocido error de "stack overflow", debemos poner líneas de control que
permitan dar fin al anidamiento de llamadas recursivas

13
 1010 - Utilizar incorrectamente técnicas
conocidas

Habitualmente nos podemos encontrar con que al implementar una técnica o patrón
conocidos, lo hacemos de forma incompleta o incorrecta.

Esto puede dar lugar a que, más tarde, quien actualice el código introduzca más errores
funcionales, ya que lo hará basándose en la técnica o patrón originales.

Ejemplo: Sample - Implem Incorr Tec Conocida

14
¿Cómo crear los hábitos de buena programación?

15
 ¿Cómo crear los hábitos de buena
programación?

Nunca programar para ti mismo

Siempre que el programador piense que él es el único que va a utilizar el código que
genera, aunque realmente sea el único programador del proyecto, introducirá muchos de
los errores que hemos comentado.

Cada vez quedan menos proyectos de un sólo programador, o en los que participe un sólo
programador durante todo el ciclo del proyecto.

El código que haya generado un programador puede lastrar todo el proyecto. El resto de los
programadores que participen en el proyecto en etapas posteriores tendrán que lidiar con el
código generado por los programadores que han participado con anterioridad en el mismo
proyecto.

Como programadores debemos convencernos de dicha situación y programar siempre para

otros.

Pero ¿cómo se forma un programador para no cometer los errores anteriores?

16
 ¿Cómo crear los hábitos de buena
programación?

Leer código
Leer un fragmento de código al día nos permite crecer como programadores.

Además de leer el programador debe revisar el código que lee, en busca de errores o
técnicas que le permitan mejorar.

El código que leemos o que generamos, podemos clasificarlo dentro de estas tres
categorías:

este cuadro cubre parte de la

imagen de abajo para mostrarla
en 2 partes
17
 ¿Cómo crear los hábitos de buena
programación?

Leer código
Partiendo de estas categorías podemos generar el esquema mental de las preguntas que
como programadores debemos hacernos cuando lee o escribe código.

Si nos hacemos estas preguntas veremos dónde nuestro código se sale de los
estándares y las buenas prácticas sin motivo justificado.

18
 ¿Cómo crear los hábitos de buena
programación?

Pair Programming
Al emparejar a programadores, entre ambos se aportan experiencia y convergen sus
ideas en puntos comunes que permiten crear buen código.

Esto puede significar una gran mejora para ambos programadores.

19
 ¿Cómo crear los hábitos de buena
programación?

Organizar el código
Organizar nuestro código es importante para mantener durante el proceso de desarrollo
un proyecto saludable y con unos costes de mantenimiento controlados.

Después de la observación de patrones de programación, se ha puesto nombre a cómo

organizan (o no) los programadores el código.

Código Spaguetti Código Ravioli Código Lasagna

20
 ¿Cómo crear los hábitos de buena
programación?

La Mejor Opción

El mejor código que podemos llegar a generar es áquel organizado en capas y

particionado en componentes que interactuan entre sí, es decir:

Lasagna Ravioli

+
21
 ¿Cómo crear los hábitos de buena
programación?

Poner comentarios en el código

Tan importante como tener una buena organización de código, es comentarlo.

Un código documentado es un código que va a poder ser mantenido en el tiempo, por

diferentes personas y en diferentes proyectos.

Cuando un programador tiene que realizar mantenimientos o escalar código que no

entiende y que no está comentado, en lugar de reutilizarlo, reescribe la funcionalidad,
solo con tal de evitarse aprender como funciona.

Ejemplo de exceso de comentarios en el código.

Ejemplo de código autocomentado y comentarios correctos.

22
 KISS:
El principio de la simplicidad

23
 KISS

El principio de la simplicidad

Este principio recomienda desarrollar usando código simple y comprensible.

También se conoce como "Keep it Short and Simple", para evitar lo tosco del acrónimo
original.

¿Cómo lo aplicamos?

Leer lo de otros - siempre nos ayudará a escribir mejor

Escribir lo mejor que sepamos
Releer nuestro código
Mejorarlo

Dos técnicas nos permiten hacer el código más legible y más

sencillo:
PARTICIONADO y SIMPLIFICACIÓN

24
 KISS

Particionado y Simplificación

PARTICIONADO

Se basa en el principio de dividir secciones grandes de código en partes más pequeñas, lo

que hace cada una de las secciones más comprensible.

SIMPLIFICACIÓN

Se basa en el principio de hacer el código más comprensible eliminando todo aquello que no
sea útil o modificándolo para hacerlo más sencillo.

Iterar sobre estos dos puntos las veces que sea necesario y que el tiempo nos lo permita,
hará que nuestro código quede limpio, sencillo y legible

25
 YAGNI
El principio de no malgastar esfuerzo

10 minutos después de poner esta imagen y este título, todavía seguía buscando imágenes mejores
para representar YAGNI, cuando en realidad no las necesitaba.

26
 YAGNI

YAGNI = EFICACIA

You aint gonna need it

No vas a necesitarlo

Uno de los fallos comunes en un proyecto de software es el exceso de programación u

over-programming.

Cuando afrontamos cualquier proyecto uno de los primeros pasos es realizar un análisis.

Realizar el análisis de los requisitos del proyecto sin tener en mente el objetivo final,
produce siempre como resultado un exceso de funcionalidad.

27
 YAGNI

...tener en mente el objetivo final

REQUISITO
Como [ operador de atención al cliente ]
Necesito [ poder buscar clientes ]
Para así [ encontrarlos más rápido cuando nos llaman por teléfono ]

ANÁLISIS

PANTALLA QUE NECESITA EL CLIENTE

28
 YAGNI

...tener en mente el objetivo final

Lógica de Acceso a Datos

Lógica de Negocio

Interfaz de Usuario

Servicio

29
 YAGNI

...tener en mente el objetivo final

¿Qué necesita quien interactúe con la aplicación?

Usuario Funcionalidad

Interfaz de Usuario Servicio

Lógica de Negocio

Lógica de Acceso a Datos

30
 KISS, YAGNI y DRY

principios básicos de una programación elegante

DRY es el acrónimo de Don't Repeat Yourself y aunque se menciona menos, no deja

de ser de los principios más importantes de la programación. Cuando se aplica de
forma eficiente, los cambios necesarios sólo se necesita hacerlos en un sólo lugar.
Lo veíamos antes en el ejemplo de sobrecargas mal implementadas (o
interpretadas?).

Eficiencia, Eficacia y Reutilización

31
Optimización del Rendimiento

32
 Optimización del rendimiento

Horror Code

for (int i = 0; i < CargarEmpresas().Rows.Count - 1; i++)

{
if (CargarEmpresas().Rows[i]["PaginaWeb"].ToString()=="")
GridView1.Rows[i].Cells[7].Visible = false;
}

var empresas = CargarEmpresas();

for (int i = 0; i < empresas.Rows.Count - 1; i++)
{
if (empresas.Rows[i]["PaginaWeb"].ToString()=="")
GridView1.Rows[i].Cells[7].Visible = false;
}

La primera responsabilidad en el rendimiento la tenemos nosotros:

los programadores

33
 Optimización del rendimiento

Medir el rendimiento
El rendimiento de nuestras aplicaciones es tan importante como otros criterios de
aceptación de nuestra aplicación.

Para poder medir el rendimiento, debemos tener en cuenta:

- Conocer los recursos de hardware del cliente y definir los requisitos minimos de
nuestra aplicación en base a ellos.

- Conocer el rendimiento esperado por el destino y definir los criterios de aceptación

de nuestra aplicación en base a ello.

- Realizar pruebas de rendimiento en un entorno que simule el hardware mínimo

aceptado y no el hardware recomendado.

- Probar el rendimiento frecuentemente.

- Hacer pruebas REALES

34
 Optimización del rendimiento

Herramientas
El rendimiento de nuestras aplicaciones es tan importante como otros criterios de
aceptación de nuestra aplicación.

Rendimiento Aplicaciones

- Visual Studio - Performance Explorer

- Eclipse - Eclipse Test & Performance Tools Platform Project

Rendimiento Web

- FireBug

- Fiddler2

35
 Optimización del rendimiento
El futuro ya está aquí
Los entornos uniprocesador son
cosa del pasado
El presente son los entornos multiprocesador.
Deberemos adaptar nuestras aplicaciones a este
nuevo entorno.
36
Para poder aprovechar el uso de
estos nuevos recursos debemos
adaptar nuestras aplicaciones
introduciendo paralelismos.
La Plataforma MS .NET 4 incluye
una API que permite aprovechar
mejor esta capacidad de los
ordenadores.
Reducción de Dependencias

37
 Reducción de dependencias

Dependencias vs. Soluciones Escalables

Cuando afrontamos un proyecto y hacemos caso de buenas prácticas, dividimos el

mismo en capas y componentes que interactúan entre sí.

Sin embargo, la interacción genera una dependencia entre ellos.

Según el tipo, la dependencia puede interponerse en el camino de crear soluciones

escalables, ya que la mera ausencia de uno de los componentes iniciales podría
inutilizar todo el proyecto.

38
 Reducción de dependencias

Eventos

Una forma sencilla de reducir dependencias es mediante eventos. Esto facilita la

reutilización de los componentes que desarrollamos.

39
 Reducción de dependencias

Dependency Injection

Esta técnica esta basada en el patrón de diseño Inversion Of Control.

Este patrón especifica que, a diferencia de una aplicación convencional, en lugar de ser
el código del usuario el que invoca los elementos externos (p.e. objetos en una librería)
son los elementos externos los que invocan al código de usuario.

Este EJEMPLO describe la implementación.

Unity, una librería de Patterns & Practices, que nos proporciona una API completa
configurable para la inyección de dependencias.

Otra opción muy conocida que disponible para Java y .NET es

http://www.springsource.com/

40
 Reducción de dependencias

Dependency Injection

Ejemplo de Inyección de Dependencias con Unity

41
 Reducción de dependencias

Extensibilidad de Aplicaciones - Loose coupling

La reducción de dependencias va mucho más allá de sustituir llamadas a otras clases

por lanzar eventos o "inyectar" la funcionalidad que necesitamos.

Así como la reducción de dependencias entre clases facilita la reutilización, la

eliminación de dependencias entre ensamblados facilita la escalabilidad y compatibilidad
de nuestras aplicaciones.

MEF Mono Addins Ejemplo [Recordar YAGNI

42
Control de la seguridad

43
 Control de la seguridad

Pensar en la seguridad mientras se programa

¿MIS DATOS SEGUROS, LOS DE MIS PROGRAMAS ME DA IGUAL?

Siempre tenemos cuidado en la seguridad al navegar por la red, con los programas que
nos descargamos, con aquellas personas que pueden tener acceso a nuestros datos
confidenciales. Siempre estamos pensando en los datos de nuestro ordenador, pero
pocas veces en los datos que manejan nuestros programas, los que nosotros
codificamos.

¿SIEMPRE IMPLEMENTAR LA MAYOR RESTRICCIÓN?

- Muchos lo recomiendan - A nadie le importa esperar tres segundos cada

vez que se hace un clic en el cajero automático.
- Va en contra del rendimiento y la eficiencia.
- A todos nos enfurece esperar tres segundos
- Pensar en 2 antivirus, 2 firewalls, bloqueador de para obtener un listado en una aplicación de
popups, analizador de Webs seguras... todo gestión de datos sin demasiada importancia.
instalado en nuestro ordenador

44
 Control de la seguridad

Análisis de Riesgos
Una fórmula permite priorizar los riesgos asociados al sistema que programamos:

Prioridad = RIESGO1_PÉRDIDA(en €) * RIESGO1_NIVEL_RIESGO_ASIGNADO.

Valor del riesgo - por ejemplo, de 0 (min) a 5 (máx).

Valor de las pérdidas - costes de recuperación de datos, de re-instalación de software,

y posibles demandas por pérdidas o publicación de datos confidenciales.

Ej. Aplicación de gestión de datos personales de 100 usuarios

[R1] - Acceso no autorizado a la base de datos
[NivelR1] - 3 [PérdidasR1] - 250.000€ [ValorR1] - 750.000
Ejemplo Riesgo:
[R2] - Página web no disponible a menudo
[NivelR2] - 5 [PérdidasR2] - 100.000€ [ValorR2] - 500.000 Recomienda esta Web
Siempre hay un riesgo asociado a cada trozo de nuestro código y un riesgo asociado a
los datos que se manejan con nuestro código.

Los mayores riesgos vendrán valorados en el estudio del proyecto. Pero hay riesgos
implícitos en cada línea de código que programamos y ésos tenemos que conocerlos y
valorarlos nosotros mismos
45
 Control de la seguridad

¿Cuánta seguridad necesitamos?

La seguridad es necesaria. La falta de seguridad cuesta dinero, y el exceso de

seguridad también.

• Debemos evitar la seguridad excesiva

o No debemos dedicar más tiempo del necesario a proteger los datos, y éste
tiempo estará dado por la importancia de los datos que queremos proteger.
o Esta valoración de esfuerzo será intuitiva la mayoría de las veces, y cuando
no, debemos realizar un análisis de riesgos para saber qué prioridad darle a
este riesgo.
• Nunca olvidarse de la seguridad (el usuario NO es guay)
o Tampoco debemos confiar en que el entorno en que se van a usar los datos
es 100% seguro
o También los usuarios para los que se ha hecho la aplicación pueden ser
futuros elementos de riesgo (ante despidos, disgusto entre personas
empleadas, etc).
o Incluso en los sistemas creados para un sólo usuario, hay riesgo potencial de
que otro usuario intente acceder al sistema.

46
 Control de la seguridad

¿Siempre implementar la mayor restricción?

MEJORES PRÁCTICAS

• Aplicar la lógica para saber dónde pueden haber fallos de seguridad.

o SQL Injection
o Cross-site scripting
o Dynamic Evaluation vulnerabilities
o No guardar datos en el PC del usuario (contra los Password revealers, trojanos que revisan
cookies)
o Repositorios protegidos por contraseña y aplicación que se impersonaliza
o Validar todos los datos que vienen del usuario o sistemas externos.

• Implementar lo necesario para gestionar la seguridad que necesitan nuestros

datos.

• La sencillez y legibilidad en el código influirá positivamente en la seguridad,

debido a que la claridad del código permitirá detectar los fallos existentes o
potenciales.

47
Control de errores

48
 Control de errores

Ignorar, Contener, Mitigar, Solucionar

Muchas veces nos planteamos demasiadas soluciones de control para errores que
tienen soluciones más simples.

A veces es suficiente con capturar el error, loguearlo e informar al usuario.

Se debe analizar el nivel de seguridad y de integridad que necesitan los datos que
maneja nuestro código. Esto nos va a indicar cómo gestionar los errores encontrados.

49
 Control de errores

Ignorar

Podemos ignorar errores que no influyan en las tareas principales del usuario de nuestra
aplicación y no provoquen pérdidas de datos ni comprometan la seguridad, pero desde
su detección son candidatos a corregirse.

Se suelen ignorar los errores sólo cuando hay otras tareas de más prioridad para
desarrollar.

- La pantalla no está bien estructurada, y cuando la resolución de la pantalla es menor

que la sugerida, algunos controles no se ven (errores de diseño)

- Cuando se están guardando los datos, no permite cancelar, y si la ruta de red no existe,
la aplicación devolver el control al usuario (errores de rendimiento)

50
 Control de errores

Contener
Usar ante soluciones urgentes o si el tiempo apremia, por ejemplo cuando muy cerca de
entregas inmediatas se detectan fallos.

Luego que esté contenido en la solución en producción, planificar la mitigación o la

solución.

Escenarios en que podría usarse la contención:

- Si ocurre el fallo y NO es un error de seguridad

Capturar, loguear, avisar que no se ha podido realizar la operación y

cerrar la pantalla en la que se ha producido para que se empiece a
realizar el proceso desde cero. Si es necesario, reiniciar también la
aplicación.

- Si es un error que compromete la seguridad, ocultar la

forma de acceder al error o de reproducirlo.

Ejemplo de contención

51
 Control de errores

Mitigar

La mitigación no es más que una solución -muchas veces temporal- que evita el
problema, y da la sensación de que lo ha solucionado, pero que tiene un riesgo
asociado.

En el siguiente caso que citamos como ejemplo, nos podemos plantear mitigar y no
solucionar del todo.
Una web contiene maquetas funcionales de sitios HTML, y comercializa la visión de las mismas. Hay que
guardarlos en un servidor Web y el usuario final debe tener acceso a ellas una vez sea autorizado por el
sistema. Sin haber sido autorizados los usuarios también tienen acceso a ellas, ya que el acceso se realiza a
través de un directorio virtual que permite lanzarlas como URL. Los usuarios no lo saben. No hay mucho
tiempo de desarrollo.

Mitigación: Estructurar las carpetas por IDs de paquete. Teniendo en cuenta que los nombres de las
maquetas son complejas, los usuarios del sitio Web no podrán conocer, ni dentro de una maqueta, las partes
que no ha visitado. No permitir listar los directorios para evitar descargas spiders, evitar indexación de
buscadores mediante los archivos "robots".

Riesgo pendiente: Muy Bajo, pero quedan expuestos paquetes con copyright.

52
 Control de errores

Mitigar

53
 Control de errores

Mitigar

54
 Control de errores

Solucionar
En estos casos de abajo hay que solucionar el problema sí o sí, o todo código que
generemos (o que usemos para parchear un problema) no será más que coste añadido
y tiempo perdido.

• Puede haber revelación de datos confidenciales

• Pérdida de datos (importantes o no, hay un coste en recuperarlos)
• Nivel de rendimiento inaceptable por el cliente

55
 Control de errores

Registro de Errores y de Acciones (Logs)

Es MUY importante registrar los errores y acciones de los usuarios.

Ellos nos brindarán información valiosa sobre qué está ocurriendo en nuestro sistema y
dónde aplicar las mejoras más inmediatas.

Logging Application Block

56
Re-Utilización

57
 Re-Utilización

Ya estamos reutilizando
Durante el desarrollo de nuestra carrera como programadores, a medida que
adquirimos experiencia, todos aglutinamos recursos, buenas prácticas y soluciones
comunes a problemas que nos hemos ido encontrando.

En otras palabras, ya re-utilizamos

58
 Re-Utilización

Etapas
Estas son las etapas de un proceso de reutilización

59
 Re-Utilización

Etapa 1 - Reutilizar Diariamente

Todos los días:

• Intentar detectar qué partes de lo que programamos pueden ser reutilizadas

• Intentar analizar y estudiar como podríamos independizar el código que nos

interesa reutilizar, para ser aplicable a cualquier proyecto

Con la práctica iremos adquiriendo más experiencia.

60
 Re-Utilización

Etapa 2 - Documentar

Una vez hemos detectado y creado el código que

queremos reutilizar, debemos documentarlo.

Documentar es un paso fundamental para reutilizar

correctamente.

Nuestro código reutilizable debe ser utilizable no sólo por

nosotros sino por otros.

61
 Re-Utilización

Etapa 3 - Habilitar una Ubicación Común

Debemos habilitar una ubicación común dónde guardar

el código y poder acceder a ella de forma rápida y
confiable

La ubicación debe ser accesible por TODOS

Lo mejor es que esta ubicación sea un repositorio.

Sólo por el control de cambios, ya es suficiente para utilizar un
repositorio.

Así que, ¿por que no comenzar con un repositorio desde el

principio?

62
 Re-Utilización

Etapa 4 - Publicitar

Hacer que tus compañeros se enteren.

Debemos comunicar a nuestros compañeros la

existencia de la librería, lo que aporta, enseñarles
ejemplos, étc.

Hay que mencionarla en las conversaciones técnicas,

en el café, donde haga falta.

Es altamente recomendable poner la documentación del

código a disposición de todo el mundo en:

La intranet
El wiki de la empresa,
étc
63
CONCLUSIONES

64
 Conclusiones

Qué esperamos que se aprenda con esta charla

Sólo se espera conseguir un objetivo

QUE PROGRAMEMOS MEJOR

teniendo unas pocas reglas en mente mientras programamos,

produciremos código de mucha más calidad,
y por lo tanto,
más legible,
más reutilizable
y menos susceptible a fallar y a generar errores de seguridad

65
 Conclusiones

¿Cuáles son esas pocas reglas de las que

hablábamos y que nos harán programar mejor?

- leer mucho código (nuestro y de otros)

- mantenerlo todo lo más simple posible, sin caer en la simpleza

- no implementar lo que no necesitemos

- no pensar lo que ya está pensado (reutilizar código y patrones de

codificación)

- pensar en que si nosotros reutilizamos, lo que hagamos también podría

reutilizarse

- nuestra aplicación siempre debe proteger los datos que maneja, pero
nunca más de la cuenta

66
Contacto

Prácticas recomendadas para codificar software

Muchas gracias por su atención
 Iñaki Elcoro ielcoro@consultec.es
 Frank Torres ftorres@consultec.es

902 23 66 66

67