Recomendaciones para los Programas ABAP, Cap. 2

Recomendaciones para los Programas ABAP, Cap. 2

- NO HARDCODEAR PALABRAS (USAR ELEMENTOS DE TEXTO)

Evitar hardcodear palabras en los mensajes, ya que se pueden usar elementos de texto. Recordemos que muchos de los programas se terminan traduciendo.

- MENSAJES DE ERROR CON CLASES DE MENSAJES.

En las USER EXITS, BADIS, FUNCIONES (e incluso en programas), es conveniente usar clases de mensajes (SE91) y un número no genérico porque facilita la búsqueda de la validación que se disparó.

Por ejemplo si quiero crear un pedido y aparece una validación Z y la misma no utiliza un NRO de mensaje propio, se complica hacer una referencia de utilización para ver cuál es la validación que se disparó.

EVITAR los mensajes del tipo: ZMM001 &&&

y USAR más del tipo: ZMM002 Error al crear el pedido, el proveedor & está bloqueado.

- REUSAR

Antes de ponerse a desarrollar un programa, verificar si ya no hay alguno que resuelve el problema que tenemos. O tal vez, si bien no hay alguno que haga lo mismo, puede haber alguno parecido.

Por ejemplo, si me piden un batch input para actualizar un campo de un CLIENTE, lo más probable es que alguien ya haya realizado un batch input para actualizar algún otro campo del CLIENTE. Entonces se puede copiar este programa y modificar lo que haga falta. ESTO PUEDE AHORRAR VARIAS HORAS DE DESARROLLO.

- GUARDA CON EL SELECT *

Si la cantidad de campos a leer de una tabla es chica (menos del 30% de los campos de la tabla), es preferible especificar los campos a leer que usar SELECT *.

Esto se debe a que de disminuye notablemente el tráfico entre el servidor de base de datos y el servidor de aplicación.

- GUARDA CON LA DEFINICIÓN DE TABLAS INTERNAS.

Si a una tabla interna se la define con el formato de una tabla y después de la carga con un SELECT, por más que se esté usando un

SELECT CAMPO1 CAMPO2

into table T_TABLA_INTERNA

Como el ancho de la tabla interna es igual al ancho de la tabla transparente, va a ocupar mucho espacio en memoria. Por eso es conveniente definir tablas internas con solamente los campos que hacen falta.

- PROBAR, PROBAR Y PROBAR

El tiempo que se le invierte a las pruebas no es tiempo perdido.

Cuando más tiempo se invierta (siempre y cuando las pruebas se realicen bien) más se disminuyen las probabilidades de errores cuando el programa esté en PRD. Y por supuesto, corregir un error en PRD tiene un costo mucho más alto que haber invertido un poco más de tiempo en las pruebas.

- INVESTIGAR, PROBAR Y DOCUMENTAR

Es conveniente documentar (para uno) aquello que haya descubierto o solucionado, porque es probable que en algún momento posterior (tal vez un año después) tenga que resolver el mismo problema. Y como es fácil olvidarse de estos temas, al documentar la forma de resolver algo que costó tiempo, se puede ahorrar muchas horas de desarrollo.