Вы находитесь на странице: 1из 13

VFP: Gua de Buenas Prcticas de Programacin y recomendaciones

Por: Fernando D. Bozzo


Hace poco publiqu unas Reglas Mnimas de Buenas Prcticas de Programacin, orientadas principalmente
a las prcticas con el control de cdigo fuente que estbamos haciendo.
En esta ocasin voy a tomar parte de lo escrito all y a extenderme ms sobre esas y algunas otras, de
forma de tener una Gua ms completa respecto de la programacin en general con algunas cosas
especficas de FoxPro y en algunos casos con el por qu o en qu beneficia hacerlo, ya que personalmente
considero muy importante qu es lo que motiva a recomendar hacer las cosas de una forma determinada.

Qu son y para qu sirven las buenas prcticas?


Las buenas prcticas no existen desde siempre, sino que se fueron desarrollando como resultado de la
experiencia comn de muchos desarrolladores y empresas dedicadas al desarrollo de software, como
Microsoft y otras.
En esas experiencias se han pasado muchas veces por situaciones conflictivas, que luego de haber
identificado fallos o problemas comunes, y luego de haber analizado los motivos que llevaron a ellos, se han
ido perfeccionando ciertas prcticas que minimizan la posibilidad de los mismos.
Otra ventaja de las buenas prcticas, es que tienen a facilitar el mantenimiento del cdigo, no solo por la
persona que lo hace, sino por otros, lo que permite "normalizar" la forma de hacer las cosas, bajar los
tiempos de desarrollo y maximizar la eficiencia.
Finalmente, el uso de estas normas minimiza los problemas y las diferencias a la hora de tener que mezclar
el cdigo de dos desarrollos sobre los mismos componentes (llamado merge), aumentando la posibilidad de
que sea automtico y no requiera intervencin manual.

1. Convencin de nomenclatura de variables (VFP)


Est detallada en la ayuda de FoxPro y en el MSDN de Microsoft
Resumen:
La primera letra define el alcance (local, privada, global)
La segunda letra define el tipo de dato (numrico, carcter, date, etc)
El nombre debe definir el concepto que representa
Ejemplos de nomenclatura:
Parmetros (t) => tcCadena, tnNumero, tdFecha, tlBoolean, taArray, toObjeto
Variables Locales (l) => lcCadena, lnNumero, ldFecha, llBoolean, laArray, loObjeto
Variables Privadas (p) => pcCadena, pnNumero, pdFecha, plBoolean, paArray, poObjeto
Variables Publicas (g) => gcCadena, gnNumero, gdFecha, glBoolean, gaArray, goObjeto
Ejemplos de buen uso conceptual:
ldFechaNacimiento
glUsuarioActivo

llActivateEjecutado

Beneficios:
Permite distinguir rpidamente los distintos alcances y tipos de variables y propiedades, por lo
que pueden convivir variables o propiedades del mismo nombre y distinto alcance o tipo (ej:
gdFecha y ldFecha)
Ayudan, en parte, a ver si un mtodo est bien encapsulado o si requiere mayor parametrizacin.
Como regla general, conviene usar siempre variables locales para mantener la encapsulacin de
la funcionalidad
Impide que se confunda una variable con un nombre de campo (lcClave y clave)
Ayuda a entender mejor el cdigo y lo que hace

2. Convensin de nomenclatura de objetos (VFP)


Est detallada en la ayuda de FoxPro y en el MSDN de Microsoft
Resumen:
Las primeras 3 letras definen el tipo de objeto
El nombre debe definir funcionalmente para qu sirve
Ejemplos de nomenclatura:
custom => cus_nombre
label => lbl_nombre
form => frm_nombre
checkbox => chk_nombre
editbox => edt_nombre
listbox => lst_nombre
spinner => spn_nombre
pageFrame => pgf_Nombre
page => pag_Nombre
commandButton => cmd_nombre

Ejemplos de buen uso conceptual:


txt_FechaDeNacimiento
cmd_CerrarFormulario
pag_ConfiguracionesDeUsuario
frm_PermisosPorUsuarioYGrupo

Beneficios:
Permite distinguir rpidamente los distintos tipos de objetos
Ayuda a entender mejor el cdigo y lo que hace

3. Checkin y checkout de componentes (SCM/VFP)


Recomendacin:
Antes de hacer un checkin o un checkout de componentes, es conveniente limpiar el entorno para evitar
problemas:
CLEAR ALL
CLOSE ALL

o incluso cerrar la sesin de VFP si se usa para ejecutar, y luego ya se puede hacer el checkin o checkout.

Beneficios:
Evitar errores por "archivo en uso"
Evitar hacer checkin de partes del componente (proteger SCX sin su SCT, etc) si el SCM no usa
transacciones atmicas (todo o nada)

4. Sesiones de FoxPro
Recomendacin:
Evitar cambiar el directorio de una sesin de FoxPro que sea usada para modificar componentes,
o sea, no usar CD <directorio> o SET DEFAULT TO <directorio> si se modifican programas con
MODIFY o se ejecutan con DO.
Para distintos sistemas o programas en distintos directorios, es mejor usar sesiones
independientes de VFP (o sea, abrir un VFP para cada sistema)

Beneficios:
FoxPro suele cachear los programas y clases en la memoria, y al modificar en otra ubicacin se
podran guardar rutas invlidas o apuntando a otro directorio, sobre todo en las clases y forms

5. Recepcin de Parmetros en mtodos


Recomendaciones:
Usar LPARAMETERS en vez de PARAMETERS y si hay que agregar parmetros a un mtodo,
agregarlos siempre al final, nunca en medio o al inicio de los parmetros existentes.
Usar PCOUNT() en vez de PARAMETERS()
Ejemplo agregando nuevo parmetro "tnCosto":
LPARAMETERS tcNombre, tnEdad, tnCosto
lnParams = PCOUNT()

Beneficios:
LPARAMETERS crea parmetros Locales, o sea que se limpian automticamente al terminar el
mtodo y los mtodos que se llamen no vern las variables creadas, mientras que
PARAMETERS los crea Privados y seguirn siendo visibles al llamar a otros mtodos
Creando los parmetros nuevos al final, se garantiza la compatibilidad de las llamadas existentes
a este mtodo sin necesidad de pruebas de regresin, porque de otra forma habra que cambiar
todas las llamadas y volver a probar todo lo existente para verificar que no falle (pruebas de
regresin)
PCOUNT() lleva la cuenta de los parmetros del mtodo actual, mientras que PARAMETERS()
lleva la cuenta de los ltimos parmetros recibidos en cuelquier mtodo, incluyendo mtodos

externos al actual, lo que puede producir errores de evaluacin

6. Uso de referencias de objeto


Recomendaciones:
Definir siempre que sea posible las variables de objeto indicando la clase y librera de pertenencia
Usar nombres significativos, que indiquen claramente para qu sirven
Antes de liberar la referencia del objeto, asignarle NULL
Liberar siempre las variables de objeto con RELEASE, y no confiar en la limpieza automtica de
Fox, porque a veces queda la referencia en memoria
Usar variables de objeto en lugar de rutas de objetos tipo obj1.obj2.obj3.objN
Si se deben usar muchas referencias de objetos en un bucle, usar WITH objeto .. ENDWITH
Aunque no est documentado, en los parmetros definidos con "AS clase" para aprovechar
Intellisense, no es conveniente referenciar clases de libreras o programas externas, sino solo
clases nativas, ya que con las clases externas se puede provocar un error C0000005 fatal. Para
referencias clases externas es mejor usar el truco del IF .F. descripto en el ejemplo de debajo,
donde nunca se ejecutar su contenido, pero servir para usar Intellisense.

Ejemplo 1: Referencia de objeto por parmetro


LPARAMETERS toEntorno, toException as Exception, tnCod as Integer
IF .F. && Truco para no ejecutar, pero poder definir Intellisense
LOCAL toEntorno AS "Entorno" OF "LIB_ENTORNO.PRG"
ENDIF
toEntorno.EspacioMinimoDeDisco = 100 && MB

Ejemplo 2: Uso de With..EndWith de forma ptima


WITH THISFORM.pgfConfig.pagEntrada.txtContador
FOR I = 1 TO 1000
.VALUE =.VALUE + 1
ENDFOR
ENDWITH

Ejemplo 3: Uso de Referencias de objeto cacheadas en variables


LOCAL loPagEntrada AS Page
loPagEntrada = THISFORM.pgfConfig.pagEntrada
loPagEntrada.txtUsuario.VALUE = ""
loPagEntrada.txtPassword.VALUE = ""
loPagEntrada.chkDiasVigencia.VALUE = 15

Beneficios:
Definir las variables indicando la clase y la librera, permite usar Intellisense y acceder a la lista
de miembros de la clase al poner el punto (objeto.<miembros>), lo que ahorra tiempo
Usar nombres significativos facilita la compresin y claridad del cdigo, y el mantenimiento futuro
Asignar NULL a las referencias de objetos al terminar evita la referencias pendientes de tipo

objeto, cuya acumulacin puede provocar el error C0000005


Liberar las variables de objeto con RELEASE es ms rpido y seguro que el recolector de basura
de Fox, donde a veces quedan colgadas en memoria
Usar variables de objeto (ej: loPagEntrada) en vez de referencias de objeto largas (ej:
thisform.pgfConfig.pagEntrada) permite ganar velocidad de ejecucin por no requerir leer cada
objeto de la secuencia, adems permite mayor claridad en el cdigo y ocupar bastante menos
espacio, lo que hace que se pueda leer y entender ms rpido
Usar With..EndWith cuando hay muchas referencias de objeto o referencias dentro de un bucle
FOR o DO WHILE siempre es lo ms rpido, ya que el WITH cachea el objeto

7. Return
Recomendaciones:
No usar RETURN en medio los mtodos, sino slo al final de los mismos, ya que si no se rompe
el flujo natural del programa
Jams usar RETURN dentro de un ENDWITH! Deja referencias de objeto colgadas y al rato
genera el error C0000005
Agregar RETURN siempre al final de un mtodo o procedimiento, para poder elegirlo durante una
depuracin y poder salir del mtodo antes

Ejemplo:
LPARAMETERS tnValor
lnCodError = 0
IF tnValor <= 0
lnCodError = 1
ENDIF
RETURN lnCodError

Beneficios:
Los RETURN al final del cdigo permiten seguir el flujo del programa ms fcilmente
Se facilita la recoleccin de basura (liberacin de tablas y variables, etc) en un nico punto
Es ms fcil para depurar y permite saltearse todo el cdigo e ir directo al Return para salir del
mtodo (a veces viene bien al depurar)

8. Manejo de Errores
El control de errores es fundamental en cualquier aplicacin y no debe dejarse de lado o para el final, sino
que debe formar parte del diseo. Este artculo te ayudar a entender cmo funciona el Try/Catch y cmo
usarlo.
Recomendaciones:
Controlar los errores en todos los puntos clave del sistema y no ignorarlos
No dejar que FoxPro controles los errores con Abort-Retry-Ignore, porque es peligroso dejar esa
decisin al usuario, ya que normalmente "ignorar" para seguir adelante
Los errores se deben relanzar desde la capa de datos y negocio hacia la interfaz visual, donde se

muestran
Nunca deben mostrarse errores en una capa que no sea la Interfaz visual

Ejemplo:
TRY
lnCodError = 0
IF tnValor <= 0
lnCodError = 1
ENDIF
CATCH TO loEx
THROW
FINALLY
*-- Recoleccin de basura
ENDTRY

Beneficios:
Try/Catch permite el manejo estructurado de errores, y relanzarlos o tratarlos localmente
Finally permite recolectar la basura, tanto con o sin errores
Relanzar los errores de negocio o de datos permite reutilizar esas lgicas, encapsularlas y
testearlas de forma ms fcil y aislada
Al ser una estructura de control que envuelve al mtodo, facilita el flujo del programa y permite
salir de l con Exit, siempre por el final del mtodo
No permite usar RETURN dentro de la estructura (genera un error), lo que ayuda a estructurar y
disear mejor el proceso

9. Separacin en N capas y en funcionalidades (encapsulacin)


Recomendaciones:
Si se quiere usar la separacin de 3 capas (datos, negocio e Interfaz), es importante no hacer los
procesos en el form, sino en un proceso independiente que puede ser invocado desde el form,
pero programado fuera de l. Quedan excluidos los procesos necesarios para gestionar la
Interfaz, como rutinas de refresco y similares.
Con los accesos a datos lo mismo: evitar usar sentencias DML (Data Manipulation Language,
tpicamente SQL) como Select, Update, Insert o Replace, dentro del form, y hacerlo fuera del
form en procesos separados, por ejemplo las consultas de clientes o de artculos son casos
tpicos. Quedan excluidos los accesos a datos como necesidad del manejo de la pantalla, como
cursores con metadatos usados para gestionar la Interfaz.
Una misma librera no debera contener elementos de capas distintas (por ejemplo, forms, clases
de negocio y clases de acceso a datos)
Cada capa puede estar contenida en una o ms libreras, dependiendo del diseo
Evitar que los mtodos o procedimientos hagan muchas cosas y preferir que hagan una sola
cosa a la vez
Si un mtodo es muy largo o tiene muchos comentarios, es muy probable que haga varias
cosas, lo que dificulta su mantenimiento, y sera mejor separarlo en mtodos ms chicos
Los procesos complejos que requieren realizar varias tareas, conviene dividirlos de tal forma que

haya un proceso central que solo gestione subprocesos (paso de datos entre ellos, gestin de
errores, etc) mediante llamadas a los mismos, donde el subproceso es el nico que implementa
el cdigo de la tarea necesaria
Si se tienen las tpicas hiper-libreras que lo hacen todo y que de tanta funcionalidad mezclada es
son difciles de mantener, una buena tcnica de encapsulacin, y muy simple, es reemplazar
mtodos con cdigo por llamadas a mtodos de libreras externas donde se mueva y adapte ese
cdigo. De esa forma se mantiene la API de la interfaz (los nombres de los mtodos) pero se
cargar mucho ms rpido porque ya no contendr todo el cdigo inicial, sino solo las llamadas.
Hay casos en los que es necesario redisear (cambiar la funcionalidad). No tener miedo de
hacerlo, ya que puede ahorrar ms tiempo que el que lleva mantener un cdigo espagueti

Ejemplo 1: Cdigo de una funcionalidad para


Ejemplo 1: Cdigo externalizado como funcionalidad
externalizar
independiente
*-- Consultar artculo
oBus.ConsultarArticulo(lcCodArt)
(Aqu estara todo el cdigo que
implementa la consulta, el control de
errores, etc)

Ejemplo 2: Cdigo de mltiples funcionalidades paraEjemplo 2: Cdigo externalizado como


externalizar
funcionalidades independientes
*-- Funcionalidad 1
oBus.Funcionalidad_1()
(cdigo con implementacin de la
funcionalidad 1)
oBus.Funcionalidad_2()
*-- Funcionalidad 2
(cdigo con implementacin de la
funcionalidad 2)

oBus.Funcionalidad_3()

*-- Funcionalidad 3
(cdigo con implementacin de la
funcionalidad 3)

Beneficios:
La separacin en capas permite el mantenimiento por separado y granular de los distintos
subsistemas
Esta separacin permite maximizar las posibilidades de reutilizar cdigo en procesos
desatendidos o para otros sistemas o relacionados al actual.
La separacin en libreras favorece su reutilizacin
La separacin en funcionalidades bien definidas que hacen una sola cosa en lo posible, no solo
favorece la reutilizacin, sino tambin que facilita su testeo de forma separada al sistema
mediante herramientas de Testing Unitario como FoxUnit
La creacin de mtodos "Gestores" unido a una buena nomenclatura funcional, facilita el anlisis,
comprensin y mantenimiento del sistema, evitando tener que entrar en cada mtodo para saber
lo que hace

En muchas ocasiones, el rediseo ahorra tiempo y mejora la calidad y mantenibilidad del cdigo

10. Desarrollo sencillo y tonto (KISS)


Recomendaciones:
Desarrollar con la simplicidad en mente
Evitar complejidades innecesarias
Si algo se complica, probablemente convenga separarlo en partes ms simples o usar un mtodo
gestor de procesos
Evitar los mega-procedimientos que hacen de todo, ya que suelen ser los ms difciles de
arreglar si fallan, o de mantener, pasado un tiempo
Usar nomenclatura clara que todos entiendan, y no "yo solo me entiendo", porque dentro de
varios meses ser "ni yo mismo me entiendo!"
Cuando se modifica un cdigo existente, siempre evaluar si hay algo mejorable o que pueda
escribirse de forma ms clara. Si se puede refactorizar, hacerlo en el momento; si se puede
mejorar, pero es algo complejo o que llevar ms tiempo, preparar una tarea posterior para
"mantenimiento preventivo" y hacerla lo antes posible (futuro cercano, no lejano:)
Usar los comentarios estrictamente necesarios, pero usarlos bien.
Los comentarios deben explicar brevemente la funcionalidad no-obvia a primera vista, de otro
modo, sobran y mejor no ponerlos
Ejemplo 1: Cdigo para mejorar
If condicin1
Else
If condicin2
Else
If condicin3
Else
EndIf
EndIf
EndIf

Ejemplo 1: Cdigo mejorado


Do Case
Case condicin1
Case condicin2
Case condicin3
Otherwise
EndCase

Ejemplo 2: Comentario obvio


*-- Muestra un mensaje
MESSAGEBOX( "Este es un mensaje!" )

Ejemplo 2: Optimizacin
MESSAGEBOX( "Este es un mensaje!" )

Ejemplo 3: Comentario obvio


*-- Si lActivateEjecutado=.F.
IF NOT lActivateEjecutado THEN
...(cdigo)

Ejemplo 3: Comentario ms til


*-- Si no se ejecut el evento activate
IF NOT lActivateEjecutado THEN
...(cdigo)

Beneficios:
Cuanto ms simple es un mtodo, menos cdigo tiene y ms fcil de entender y mantener es
Menos cdigo implica menor probabilidad de errores

Los nombres de mtodos y variables que indican conceptos precisos y limitados, facilitan la
legibilidad del cdigo, su mantenimiento, su refactorizacin y su encapsulacin
Un cdigo fcil de ver y mantener, implica un menor costo de mantenimiento

11. Desarrollar, Preparar Tests, Refactorizar y ejecutar Tests


Recomendaciones:
Las tareas de un ciclo de desarrollo ptimo, sin un orden especfico, son:
Desarrollar la funcionalidad
Crear tests automatizados (siempre que aporte beneficios)
Refactorizar el cdigo para simplificarlo lo ms posible
Ejecutar los tests antes creados para verificar que no se haya roto nada.
El orden de estas tareas puede variar dependiento del paradigma de programacin que se est
usando. Por ejemplo, si se usa TDD (Test Driven Development o Desarrollo Orientado por Tests),
los Tests Unitarios automatizados es lo que se hace primero para generar lo que se conoce
como "contrato", y luego se realiza el desarrollo para cubrir esa funcionalidad (y cumplir con el
"contrato" funcional)
La refactorizacin es parte de la tarea de desarrollo y no una mejora independiente para una
etapa posterior o futura.
Crear Tests Unitarios automatizados para cualquier funcionalidad o mtodo donde el test aporte
valor, por ejemplo, para mtodos de clculo, de evaluacin de decisiones, de procesos y de
cualquier funcionalidad, por pequea que sea, cuyo mal funcionamiento pueda ser muy perjudicial
para el sistema. No tiene sentido hacer Tests sobre cada mtodo existente, porque hacerlos
tambin conlleva un coste, y se debe buscar un equilibrio.

Beneficios:
El hecho de realizar estas tareas de desarrollo (desarrollo, tests, refactorizacin) permite
maximizar la calidad desde el principio
La refactorizacin permite optimizar, depurar, limpiar y aclarar el cdigo que se est
escribiendosin cambiar la funcionalidad, de cara a facilitar el mantenimiento del mismo
Los Tests Unitarios automatizados permiten realizar comprobaciones automatizadas de procesos
o funciones importantes para el sistema y adems, como se mantienen en el tiempo, sirven
como pruebas de regresin para las siguientes versiones, lo que implica un gran ahorro de tiempo
de pruebas manuales
Donde personalmente comprob que TDD ahorra tiempo, es para la solucin de incidencias,
donde se sabe de antemano qu respuesta se esperaba de una funcin o proceso. En estos
casos, se hacen primero los tests para reproducir el problema o error (sale el test en rojo), luego
se hace la correccin del cdigo y finalmente se vuelve a ejecutar el test, que ya debe salir en
verde, lo que tambin permite comprobar que el test estaba bien hecho y que hace lo que debe.

12. Usabilidad
La usabilidad es la facilidad de poder usar un sistema.
Nota: Los efectos especiales que a algunos desarrolladores les gusta agregar a sus sistemas, a veces
terminan haciendo que la usabilidad del mismo empeore, por lo que se debe tener cuidado en esto.

Recomendaciones:
Permitir recorrer los controles con el teclado con un orden lgico y no catico (normalmente con
la tecla Tab o Enter), comenzando por arriba a la izquierda, e ir avanzando en sentido abajoderecha
Minimizar el uso de lneas y cajas 3D que tan de moda estuvieron con Windows 95 (1995)
En el diseo de las pantallas, realizar agrupaciones y separaciones funcionales por medio de
espaciado entre bloques, lo que sustituye a las lneas que antes se ponan por todos lados
En vez de usar cajas (shapes, lines) para agrupar controles, intentar usar una lnea de separacin
a modo de ttulo y espacios a izquierda, derecha y debajo que separen del resto
Alinear ttulos y campos, tanto verticalmente como horizontalmente, y usar el mismo espaciado
entre controles
Usar siempre el mismo tipo de alineacin de etiquetas: si se alinean a la izquierda, o a la
derecha ms cerca de los datos, hacerlo igual en todos los forms del sistema
Todas las acciones que se lancen desde el form deben poder hacerse con un control claramente
visible y pensado para tal accin (por ejemplo, un label no est pensado para eso, un botn de
comando s)
Evitar el bloqueo de la navegacin por la pantalla. Por ejemplo, no deberan mostrarse mensajes
modales (tipo messagebox) por el solo hecho de recorrerla. La navegacin debera ser libre.
Intentar utilizar mecanismos no bloqueantes para mostrar mensajes al usuario. Por ejemplo, la
lnea de estado inferior, un espacio especial de notificacin o una ventana que el usuario pueda
invocar con una tecla o botn.
Hacer un uso inteligente de los colores y las notificaciones grficas, como iconos o mensajes.
Por ejemplo, ante un error de ingreso por parte del usuario, se puede colorear el fondo de dicho
control para que el usuario lo vea y de esta forma no lo bloquea
Utilizar el control adecuado para el tipo de ingreso de datos o de seleccin requerido. Por
ejemplo, no usar varios checkbox para simular on optingroup
Disear dejando el espacio suficiente para los datos. El usuario debera poder ver el dato
completo sin necesidad de hacer scroll dentro de un textbox demasiado pequeo, por ejemplo, o
debera poder ver una opcin seleccionada completa en un combobox sin necesidad de
desplegarlo.
En los cuandros de dilogo o pantallas de accin que requieran alguna decisin del usuario,
poner siempre un botn para Cancelar o Salir, ya que algo como "Aceptar" solamente, no es una
opcin.
Aprovechar la posibilidad de redimensionamiento de los forms y hacer buen uso de la propiedad
Anchor, que permite redimensionar los controles
Evitar los colores chillones y optar por colores tranquilos (hay guas sobre esto)
Dado que hay sistemas en los que el usuario trabaja todo el da, el diseo y la usabilidad deben
considerarse como algo muy importante, y evitar elementos que distraigan su atencin
Ejemplos de diseo:

Ejemplo 1: Mal diseo


No sera mejor permitir Cancelar?
Un claro ejemplo de lo que podra ocurrir si no se permite:

Ejemplo 2: Mal diseo


Cajas y cajas y cajas dentro de cajas...

Ejemplo 3: Buen diseo


Este diseo que permite navegar sin bloquear al usuario con mensajes modales. Rpidamente se pueden ver
los campos que tienen algn error (fondo rojo) y un mensaje en una zona especial indica el error ocurrido
ms inmediato. Adems el botn Guardar no se habilita hasta que est todo correcto, pero siempre se
puede Salir y abandonar el proceso. Un botn extra podra permitir ver todos los errores de validacin y
posibles sugerencias de solucin en un form aparte:

Ejemplo 4: Buen diseo


Observar a la derecha, un solo cuadro y 3 bloques de informacin separados por espacio, y un panel inferior
separado por la sola presencia de los 4 botones de comando. Todo el conjunto usando tonos pastel entre
vvidos y tranquilos, y muy amenos:

Beneficios:
Un recorrido ordenado por la interfaz, permite predictibilidad
Una interfaz clara minimiza los errores y aumenta la satisfaccin del usuario
Un buen diseo permite que el usuario pueda ser ms eficiente, pueda hacer las tareas en menor
tiempo y pueda distenderse

13. Usa Control de Versiones


[Artculo] Para qu sirve? Por qu es necesario?

Nota final:
Esto no es todo, hay ms, pero esta es una buena base para poder trabajar en un equipo o en solitario, ya
que todas estas prcticas tienen como objetivo final el facilitar la comprensin y legibilidad del cdigo, su
encapsulacin, tambin minimizar el costo de su mantenimiento y maximizar la satisfaccin y eficiencia del
usuario.

Hasta la prxima!

Вам также может понравиться