He fracasado, intenté realizar un cambio, emprender un nuevo camino, alcanzar nuevas metas, llegar al éxito, pero aquello no funcionó. Pero he llegado al éxito después del fracaso.
¿Qué es el éxito?
Pues cada uno tendrá su definición de éxito, pero hay que tener mucho cuidado con algunas consideraciones de éxito.
¿Es éxito ganar mucho dinero? Depende del pago que debes realizar para conseguirlo.
¿El éxito es ir ascendiendo en puestos en la empresa? El principio de Peter golpea duro.
¿El éxito es tener un BMW, Mercedes, Lamborghini? Cuidado con la Jaula de Oro.
Si estás pensando que es mejor llorar en un Lamborghini, ánimo
Más no es mejor. Mejor es mejor
En el mundo en el que vivimos del ya, del ahora, de los perfiles de Instagram, LinkedIn, TikTok, Redes Sociales, de los Likes, etc. Parece que el éxito solo existe cuando se puede medir. Lo marcará el número de Likes, contactos, salario, estatus, nombre anglosajón de tu puesto de trabajo (¿Vice President? ¿En serio?), fotos de viajes, número de países visitados o fotos de comidas en restaurantes en Instagram.
Sin embargo, hay otros criterios no medibles que, en una primera instancia, por el simple hecho de no poder ser medidos y poder «demostrar» cuanto de eso tienes, son menospreciados. Y, sin ningún lugar a dudas, son los más importantes. Criterios como:
Sentirte realizado y valorado en el trabajo
Tener una red de amigos en el mundo laboral
Ocio
Tiempo libre
Tiempo de calidad con tu familia
Tiempo para hacer ejercicio o deporte
Es decir, tiempo para ser tú mismo, para desarrollarte como persona, para estar con los tuyos, para mejorar tu cuerpo, mente y energía, para ser feliz. El problema es que el dinero no puede comprar el tiempo, suele ser al revés, cuanto más dinero quieres ganar, menos tiempo te deja ese puesto de responsabilidad. ¿De verdad compensaba ese ascenso?.
Tu vida solo pasa una vez en tu vida
Y es que hay cosas que no tienen una segunda oportunidad.
Tus hijos sólo nacerán una vez en la vida, sólo tendrán edad para que les cuentes un cuento por la noche durante un periodo corto del tiempo.
Tu cuerpo, cuando quizás ya sea tarde, explotará diciéndote que no te has levantado de la silla durante años, que has dormido mal, que has tomado demasiado café o cervezas y que no has movido el culo.
Tu pareja estará contigo por costumbre, por inercia, por conveniencia, pero no compartiréis el camino común.
Y finalmente tú, te darás cuenta cuando tengas 50, 60 o 70 años que lo has dado todo por un proyecto que no es el tuyo, por una empresa que no es la tuya y que no has construido tu identidad aparte de ese trabajo. Que no eres nadie, y estás vacío, y cuando te jubiles, no sabrás qué hacer esas 10-12 horas al día que antes gastabas en el trabajo.
Ser, Estar, Parecer
De pequeño me enseñaron que los verbos copulativos son Ser, Estar y Parecer. Y hay gente que parece ser que se queda con el «Parecer» y se olvidan del «Ser» y del «Estar». Cierto es que ‘Ser’ y ‘Estar’ es mucho más complicado que ‘Parecer’, porque no tienen fin, no hay un momento en el que llega alguien que te pone la medalla del ‘Ser’ algo concreto y que para ‘Estar’ es necesario estar y gastar tu tiempo en ese ‘Estar’. Y es mucho más fácil «Parecer» porque no cuesta, no duele y no tienes que renunciar a nada.
Pirámide de Maslow
La pirámide de Maslow, también conocida como la jerarquía de las necesidades de Maslow, es una teoría psicológica propuesta por Abraham Maslow en su trabajo de 1943 «Una teoría sobre la motivación humana». Esta teoría sugiere que las necesidades humanas se encuentran organizadas en una jerarquía de cinco niveles, y que las necesidades más básicas deben ser satisfechas antes que los individuos puedan atender a necesidades más elevadas. La pirámide se divide en cinco niveles, que van desde las necesidades más básicas hasta las más complejas.
Si os dais cuenta, en una persona ‘sana’ (bueno eso es otro debate) primero hay que satisfacer ciertas necesidades básicas hasta llegar a la autorrealización. Nos podemos enrollar con esto de la pirámide de Maslow, pero si te interesa hay mucha información en Internet.
Conclusión
Cada uno tendrá su definición de éxito, y su forma de ver la vida. La mía, después de transitar sobre varios terrenos y después de muchos errores, es esta. Intento ser y estar en aquello que es importante, incluido el trabajo por supuesto. Y agradezco tener mucha gente en mi profesión que me quiere y me valora, y no sólo por mi valía profesional.
El éxito no es la clave de la felicidad. La felicidad es la clave del éxito. Si amas lo que haces, tendrás éxito.
Noooooo. El fin del mantenimiento de SAP Business Suite que, para algunos, puede ser un poco el fin del mundo.
¿Qué es eso del mantenimiento de SAP?
Antes de entrar en fechas y cuáles son las consecuencias de esto vamos a saber qué es eso del mantenimiento de SAP ECC, o de cualquier solución SAP que contiene la SAP Business Suite 7 (SAP ECC, CRM, SRM, HCM, SCM, etc.).
Como sabemos, SAP es una suite de soluciones empresariales estándar, Out-of-the-box, es decir, las empresas pagan una licencia por tener las funcionalidades SAP y tener sus sistemas SAP actualizados de correcciones y nuevas funcionalidades.
Esto, como puedes imaginar, es fundamental para una empresa que quiera tener unos sistemas robustos, seguros y actuales. Estamos en un mundo empresarial en el que tener unos sistemas de información potentes te proporciona una ventaja competitiva sobre tus competidores.
Fin del mantenimiento de SAP Business Suite 7
Pues si, el fin del mantenimiento extendido de SAP Business Suite 7 se acerca (luego veremos fechas) y esto es un problema para muchas empresas. ¿Por qué? ¿Va a dejar de funcionar mi SAP? No, eso no va a pasar, tus sistemas van a seguir funcionando pero, ahora bien, como tengas un problema no vayas a SAP a pedirle cuentas, ayuda o soporte, que no habrá nadie. Tampoco habrá nuevas notas o support packages. Y eso en sistemas con condiciones legales como Recursos Humanos (HCM) o contabilidad no tendrán estas actualizaciones legales disponibles. A partir del fin del mantenimiento extendido tu sistema SAP será como el WinRAR.
31 de diciembre de 2025: Fin del mantenimiento estándar de SAP ECC EhP-5. Todavía quedaría pasar a SAP ECC EhP6 pero ¿para qué?.
31 de diciembre de 2027: Este es el fin del mantenimiento estándar para SAP Business Suite 7. A partir de esta fecha, SAP ya no ofrecerá soporte completo (correcciones, actualizaciones y mejoras) para estas soluciones.
31 de diciembre de 2030: SAP ha extendido el mantenimiento extendido hasta finales de 2030 para aquellos clientes que aún no hayan migrado a SAP S/4HANA. Durante este periodo, los clientes pueden recibir actualizaciones limitadas, pero ya no habrá nuevas funcionalidades. Además, este tipo de soporte conlleva un coste adicional, habrá que ver si compensa pagar más por menos y además con la previsión de que se acabe el mantenimiento.
¿2027? ¿2030? Queda mucho tiempo
¿Seguro? ¿Cuánto tardas en implantar todo lo que tienes en tu ECC, CRM, SRM, etc. en un S/4 HANA y soluciones anexas? Entre analizar tus sistemas, publicación de RFP, selección de proveedor, análisis y diseño, implementación (hay cosas que no se migran tan fácil), faseado, arranque y corrección de incidencias hasta estabilización… ¿Cuánto tardas?
Madre mía! Y ahora ¿Qué hago?
Calma, todo va a ir bien
SAP lleva tiempo, mucho tiempo, avisando que esto va a pasar.
Ya allá por 2020 amplió la fecha de fin de mantenimiento que originalmente estaba en 2025 a 2027.
Además está el soporte extendido hasta 2030 y luego se guarda la posibilidad de negociar, con quien lo necesite, una ventana de soporte especial por cliente. Eso sí, desde ya mismo, las empresas que no están en S/4HANA se están perdiendo las innovaciones de SAP, y las que sí lo tienen contarán con esa ventaja contra la competencia.
Pero todavía hay tiempo, para eso estamos nosotros, los consultores, para guiar, ayudar y acompañar a este paso a S/4HANA y las nuevas soluciones. Y para dar el salto cualitativo que aportan las nuevas soluciones SAP (SAP Sales Cloud V2 por ejemplo)
En Conclusión
En tecnología hay varios momentos en los que hay ciertos saltos tecnológicos que te ves obligado a realizar. En el caso de SAP, el paso a S/4HANA es uno de ellos y, obviamente SAP quiere convertir sus clientes On-Premise SAP ECC en la nueva tecnología para evolucionar.
Hay que estar con los tiempos y evolucionar con la tecnología para no quedarse atrás. Hay tiempo para responder y empezar a andar.
Llevo desde los 18 años programando, y empecé por curiosidad y en casa. Es algo que se me da bien, me gusta y me genera satisfacción «crear» algo donde no lo había. Mi perfil profesional actual es bastante amplio, pero nunca quiero dejar ese aspecto de mi día día. Es algo que me llena, que me alegra…. hasta que veo algunas masacres de código que hay por el mundo, que me entran ganas de matar.
if dino_aux2-tipo = ‘velociraptor’ and dino_aux2-enfadado = ‘true’ or dino_tocho = ‘suelto’. Write:/ ‘Me voy’. endif. Viendo tu código te tenían que haber despedido hace tiempo, pero no habría película
Hoy voy a hablar de la calidad del código, no solo en su efectividad, también en su eficiencia, su facilidad de lectura y mantenimiento. A muchos les parecerá una tontería, algo sin importancia, pero un buen código simplifica mucho el mantenimiento, la reutilización, la lectura y documentación.
CleanABAP
Existe un proyecto en GitHub llamado Clean ABAP donde la comunidad de desarrolladores ABAP han sacado una guía de estilo de desarrollo ABAP con las mejores prácticas. Además está en varios idiomas, incluido el Español lo puedes ver aquí.
Y claro, yo iba a escribir mi libro de buenas prácticas desde mi punto de vista. Cosa que he hecho en algún proyecto al ver los desastres que la gente generaba en el sistema. Pero, al ver que ya había un consenso entre desarrolladores ABAP, y que no estaba solo en esto, pues mejor. Lo que voy a hacer es extraer de la guía de estilo CleanABAP aquellas recomendaciones que vea más necesarias. En la guía de estilo (lectura recomendadísima), se dividen las recomendaciones por áreas, vamos a respetarlas por si quieres ir a ver la fuente.
NOTA: Si estás viendo esto desde un móvil o tablet mejor en horizontal, las líneas de código se te van a cortar y hay cosas que no entenderás. No obstante, es preferible que lo leas desde el PC.
Formato
Optimiza para lectura, no para escritura
Siempre escribe pensando en la legibilidad del código, no en lo rápido que puedas escribirlo.
Bueno, yo con esta ya si que me corto las venas. Es un &#+%€ botón, pulsar un botón y te hace gran parte del trabajo.
Usa el Pretty Printer.
Usa el Pretty Printer
En serio. Usa el Pretty Printer.
Usa la configuración de Pretty Printer de tu equipo
Enlazado con lo anterior, tampoco estamos hablando de ingeniería. Es configurar tu Pretty Printer para que actúe de la forma que se consensue en tu equipo de trabajo. Yo, personalmente me gusta así:
Y esto es por lo siguiente:
Sangrar: Obvio, que el texto tenga sus correspondientes sangrías que te indiquen el nivel en el que estás es fundamental.
Conversión mayúsc./minúsc.: A mi me parece muy interesante que las palabras clave sean mayúsculas para ver claramente la acción que se está realizando e identificar las sentencias ABAP de variables, parámetros y literales.
" Ejemplo sin palabras clave mayúsculas select partner into lv_partner from but000 where bu_group = lv_clientes and xdele = abap_false and type = 1.
" Ejemplo con palabras clave mayúsculas SELECT partner INTO lv_partner FROM but000 WHERE bu_group = lv_clientes AND xdele = abap_false AND type = 1.
Por favor, usa el Pretty Printer.
No más de una sentencia por línea de código
Cada línea de código debe contener solo una sentencia, evitando mezclar varias operaciones en una sola línea.
Para mi esto es especial para los IFs con múltiples condiciones. Todo de seguido no se ve claramente.
" Ejemplo Incorrecto IF lv_total > 100 And lv_is_customer = 'X' AND lv_country = 'ES'. lv_discount = lv_total * 0.1. ELSE. lv_discount = 0. ENDIF.
" Ejemplo Correcto IF lv_total > 100 AND lv_is_customer = 'X' AND lv_country = 'ES'. lv_discount = lv_total * 0.1. ELSE. lv_discount = 0. ENDIF.
Aquí la posición de los AND y OR ya es manía personal, hay quien los pone al principio, a mi me gusta ponerlo al final y alinear las variables, los operadores y los AND/OR.
Mantén una longitud de línea razonable
Si la línea de código es demasiado larga, divídela en varias líneas para que sea más fácil de leer y seguir.
" Ejemplo Incorrecto SELECT carrid connid fldate FROM sflight INTO TABLE lt_sflight WHERE carrid = 'LH' AND connid = '0400' AND fldate = '20231010'.
" Ejemplo Correcto SELECT carrid connid fldate INTO TABLE lt_sflight FROM sflight WHERE carrid = 'LH' AND connid = '0400' AND fldate = '20231010'.
Vamos, no hay color. Mi manía personal es ponerlo en ese orden (SELECT, INTO, FROM, WHERE), y alineando desde el INTO. Además con las sentencias ABAP alineadas el código tiene más aire y se lee mejor. Se identifica claramente qué se selecciona, a donde se guarda, de qué tablas y con qué condiciones.
Usa una línea en blanco para separar cosas, pero no más
Utiliza una línea en blanco para separar lógicamente secciones del código, como declaraciones de variables y bloques de código, pero evita poner líneas en blanco innecesarias.
Los bloques de sentencias han de estar separados para su entendimiento. Todo junto no se lee bien.
" Ejemplo Incorrecto DATA: ls_order TYPE zorder, lv_total TYPE p DECIMALS 2, lv_discount TYPE p DECIMALS 2. ls_order-order_id = 'ORD001'. ls_order-customer_id = 'CUST001'. ls_order-status = 'OPEN'. lv_total = 500. lv_discount = lv_total * 0.1. ls_order-total_amount = lv_total. ls_order-discount_amount = lv_discount. INSERT zorder FROM ls_order.
" Ejemplo Correcto DATA: ls_order TYPE zorder, lv_total TYPE p DECIMALS 2, lv_discount TYPE p DECIMALS 2.
Alinea asignaciones al mismo objeto, pero no a objetos diferentes
Cuando asignas valores a varios atributos de un mismo objeto, puedes alinearlos para mejorar la legibilidad, pero evita alinear asignaciones entre diferentes objetos.
" Cómo lo hago yo lo_instance->set_data( EXPORTING iv_name = lv_name iv_age = lv_age iv_address = lv_address iv_order_id = lv_order_id ).
Fíjate en el alineamiento de los =, hace que sepas claramente identificar parámetros de variables. Esto también lo suelo hacer los IFs con los comparadores, pero eso ya es manía personal.
" Ejemplo Incorrecto IF lv_status EQ 'A' AND lv_subtype NE 'X' AND lv_amount GT 100. lv_result = 'Valid'. ELSE. lv_result = 'Invalid'. ENDIF.
" Cómo lo hago yo IF lv_status EQ 'A' AND lv_subtype NE 'X' AND lv_amount GT 100. lv_result = 'Valid'. ELSE. lv_result = 'Invalid'. ENDIF.
Nomenclatura
Usa nombres descriptivos
Los nombres de variables, clases y métodos deben ser lo suficientemente claros para que cualquier desarrollador entienda su propósito sin necesidad de contexto adicional. Por ejemplo
" Declaraciones no descriptivas DATA: lv_amt TYPE i, lt_cust TYPE TABLE OF but000, lt_items_aux TYPE TABLE OF crmd_orderadm_i.
" Declaraciones con nombres descriptivos DATA: lv_total_amount TYPE i, lt_customers TYPE TABLE OF but000, lt_items_completed TYPE TABLE OF items.
No cuesta nada y se lee todo mejor, eso sí, se consecuente con usar cada uno para lo que es, no vayas a meter en lt_items_completed cualquier tipo de posiciones de pedido porque te venga bien.
Usa sustantivos para las clases y verbos para los métodos
Las Clases deberían representar conceptos o entidades y, por lo tanto, se nombran como sustantivos.
" Ejemplos order_calculator order_utils
Los Métodos representan acciones o comportamientos, por lo que deben nombrarse con verbos.
Para mejorar la legibilidad en ABAP, se prefiere el uso de snake_case en lugar de camelCase o PascalCase en variables y métodos. El uso de snake_case es una convención ampliamente utilizada en el código ABAP debido a su compatibilidad con otras herramientas del ecosistema SAP y porque ayuda a mejorar la claridad del código, haciéndolo más legible y fácil de seguir para los desarrolladores.
" Ejemplos Incorrectos DATA: TotalAmountDue type p decimals 2. DATA: itemstoadd type table of items.
" Ejemplos Correctos DATA: lv_total_amount_due TYPE p DECIMALS 2, lt_items_to_add TYPE TABLE OF items.
Constantes
Usa constantes en lugar de números mágicos
Evita usar números sin contexto directamente en el código. En su lugar, define constantes para mejorar la legibilidad.
" Ejemplo Incorrecto IF lv_value > 42.
" Ejemplo Correcto IF lv_value > gc_max_allowed.
Sabemos que el 42 es «El sentido de la vida, el universo y todo lo demás» pero a lo mejor en tu proceso no es el sentido de ese número. Usa constantes, puedes declararlas en un INCLUDE TOP o bien en una clase estática que aglutine varias constantes.
Prefiere clases de enumeración a interfaces de constantes
Esto lo he añadido por el punto anterior. Lo que yo suelo hacer es crear una serie de clases UTIL con métodos estáticos, con un sentido funcional cada una, y sus constantes correspondientes. Voy a poner un ejemplo:
CLASS zcl_crm_ofertas_util DEFINITION. PUBLIC SECTION.
" Constantes para los estados de la oferta CONSTANTS: c_estado_abierto TYPE char10 VALUE 'E0001', c_estado_cerrado TYPE char10 VALUE 'E0002'.
" Métodos estáticos CLASS-METHODS: get_datos_oferta IMPORTING iv_oferta_id TYPE char10 RETURNING VALUE(rt_oferta_datos) TYPE TABLE OF zcrm_oferta.
CLASS-METHODS: get_interlocutores IMPORTING iv_oferta_id TYPE char10 RETURNING VALUE(rt_interlocutores) TYPE ztt_interlocutores. ENDCLASS.
Y las constantes c_estado_abierto y c_estado_cerrado podemos usarlo en cualquier código para comprobar si un pedido tiene ese estado.
IF lv_estado_pedido EQ zcl_order_util=>c_estado_abierto. " Hacer cosas ENDIF.
Variables
Prefiere declaraciones in-line que al inicio
Este apartado no estoy al 100% de acuerdo, porque soy de vieja escuela, antes de que las declaraciones In-line estuviesen disponibles y suelo hacer bastantes declaraciones al inicio. No obstante, creo que tiene bastante razón.
" Ejemplo Incorrecto METHOD calculate_discount. DATA: lv_discount TYPE p DECIMALS 2, lv_total_amount TYPE p DECIMALS 2, lt_clientes TYPE TABLE OF but000.
SELECT * INTO TABLE @DATA(lt_clientes) FROM but000 WHERE bu_group EQ zcl_bp_util=>c_agrupación_cliente. ENDMETHOD.
Lo importante es conocer las declaraciones In-line que son muy útiles y aportan claridad y limpieza al código.
No encadenes declaraciones
Cada declaración debe ocupar una línea por sí misma. Esto facilita el seguimiento de las variables.
" Ejemplo Incorrecto DATA: lv_value TYPE i, lv_discount TYPE p, lv_total TYPE p.
" Ejemplo Correcto DATA: lv_value TYPE i, lv_discount TYPE p, lv_total TYPE p.
A lo que yo añado lo siguiente
Usa «DATA:» y evita usar múltiples DATA
Entras en un código y te encuentras con esto
DATA lv_es_cliente TYPE bu_partner. DATA lt_pedidos_abiertos TYPE TABLE OF zpedidos. DATA ls_pedidos_abiertos TYPE zpedidos. DATA lv_fecha_creacion TYPE datum. DATA lv_sociedad TYPE werks. DATA lt_pedidos_cerrados TYPE zpedidos.
Pero ¿Para qué ponemos tantos DATA. Si ponemos solo un DATA: el Pretty Printer se va a encargar de darle mucho aire y alinear los TYPE.
DATA: lv_es_cliente TYPE bu_partner. lt_pedidos_abiertos TYPE TABLE OF zpedidos. ls_pedidos_abiertos TYPE zpedidos. lv_fecha_creacion TYPE datum. lv_sociedad TYPE werks. lt_pedidos_cerrados TYPE zpedidos.
Vamos. no hay color, y eso que he puesto un ejemplo con seis líneas, he llegado a ver decenas de DATA juntos. Ya sabes, usa el Pretty Printer.
Tablas
Prefiere INSERT INTO TABLE a APPEND TO
Usar INSERT INTO TABLE es más versátil y claro para la inserción de datos en tablas internas. Además el uso del APPEND da errores en las tablas de tipo SORTED y en INSERT INTO TABLE lo gestiona bien.
" Ejemplo Incorrecto APPEND ls_cliente TO lt_clientes.
" Ejemplo Correcto INSERT ls_cliente INTO TABLE lt_clientes.
Ocupa lo mismo y no da problemas.
Prefiere LINE_EXISTS a READ TABLE o LOOP AT
En lugar de leer tablas para verificar si una línea existe, usa la función LINE_EXISTS, que es más clara y eficiente. Esto no lo suelo usar mucho, porque soy vieja escuela, pero me parece muy interesante.
" Ejemplo Incorrecto READ TABLE lt_table WITH KEY id = lv_id TRANSPORTING NO FIELDS. IF sy-subrc = 0. WRITE: 'La línea existe'. ELSE. WRITE: 'La línea no existe'. ENDIF.
" Ejemplo Correcto IF line_exists( lt_table[ id = lv_id ] ). WRITE: 'La línea existe'. ELSE. WRITE: 'La línea no existe'. ENDIF.
Strings
Usa | para construir textos
En ABAP, puedes usar | para concatenar y construir cadenas de forma más limpia que con las antiguas funciones CONCATENATE.
" Ejemplo menos eficiente CONCATENATE lv_name lv_surname INTO lv_fullname.
Este es uno de los principios básicos de CleanABAP. Es mejor hacer un método que haga una cosa cada vez para que el código se pueda leer de forma sencilla y coherente. Para que el método haga una cosa nos tenemos que asegurar que:
Tiene pocos parámetros: Un método que hace una sola cosa debería tener pocos parámetros de entrada. Tener muchos parámetros indica que el método podría estar haciendo más de una tarea
No tiene parámetros booleanos de entrada: Los parámetros booleanos en un método pueden ser una señal de que el método realiza dos cosas: una cuando el valor es verdadero y otra cuando es falso.
Tiene exactamente un parámetro de salida: Un método que hace una sola cosa debería tener solo un resultado. Si devuelve más de un valor, probablemente esté realizando múltiples tareas
Es corto: Un método debe ser corto y directo. Si un método es demasiado largo, es una señal de que está realizando múltiples tareas.
Desciende un nivel de abstracción: Un buen método debe enfocarse en un solo nivel de abstracción. No debe mezclar operaciones de bajo nivel (como acceso a base de datos) con operaciones de alto nivel (como lógica de negocio)
Lanza un solo tipo de excepción: Si un método lanza múltiples tipos de excepciones, es probable que esté haciendo más de una cosa
No puedes extraer más métodos de él con un significado claro: Si no puedes dividir un método en varios métodos más pequeños que tengan un propósito claro y diferenciado, entonces probablemente el método está bien estructurado.
No puedes agrupar sus sentencias en secciones lógicas: Si las sentencias de un método se pueden agrupar en diferentes secciones, es probable que el método esté realizando múltiples tareas.
Mensajes
Haz que los mensajes sean fáciles de encontrar
Para hacer los mensajes fáciles de encontrar en una búsqueda desde la transacción SE91. Realmente yo usaba la sentencia incorrecta, pero la recomendación es no usar eso.
" Ejemplo Incorrecto IF 1 = 2. MESSAGE e001(ad). ENDIF.
" Ejemplo Correcto MESSAGE e001(ad) INTO DATA(message).
Comentarios
Exprésate en código, no en comentarios
El código bien escrito debe ser lo suficientemente claro para no requerir comentarios excesivos.
" Ejemplo Incorrecto " Calcula el total con el descuento lv_total = lv_total - lv_discount.
Usa nombres descriptivos en lugar de comentarios, ya que esto hace el código más autoexplicativo.
Los comentarios no son excusa para nombrar mal objetos
Los nombres de variables y objetos deben ser claros y descriptivos por sí mismos, sin depender de comentarios para su explicación.
" Ejemplo Incorrecto " Cantidad Total DATA: lv_tot_amnt TYPE i.
" Ejemplo Correcto DATA: lv_total_amount TYPE i.
El nombre de la variable debe ser suficientemente descriptivo para evitar depender de comentarios innecesarios.
Usa métodos en lugar de comentarios para segmentar tu código
Es más eficiente y claro usar métodos con nombres descriptivos para organizar las diferentes tareas dentro del código. Esto mejora la legibilidad y el mantenimiento del código, además de seguir el principio de hacer una sola cosa en cada método.
Los comentarios pueden volverse obsoletos o estar mal escritos, lo que puede generar confusión. Sin embargo, los métodos con nombres claros y bien definidos hacen que el propósito de cada sección sea evidente, eliminando la necesidad de comentarios explicativos.
" Ejemplo Incorrecto METHOD process_order. " Validación del cliente IF lv_customer_id IS INITIAL. RETURN. ENDIF.
" Calcular el total lv_total = calculate_total( lt_items ).
" Aplicar el descuento IF lv_discount > 0. lv_total = lv_total - lv_discount. ENDIF.
" Guardar el pedido en la base de datos save_order( lv_order_id ). ENDMETHOD.
METHOD save_order. INSERT INTO zorders VALUES iv_order_id. ENDMETHOD.
El diseño va en los documentos de diseño, no en el código
Evita incluir detalles de diseño en el código, ya que esto pertenece a la documentación externa. El diseño debe documentarse fuera del código para evitar que el código se vuelva innecesariamente complicado de leer.
" Ejemplo Incorrecto " Este método sirve para crear pedidos de venta con los datos de " entrada de cliente, datos organizativos, productos y precios. " Los tipos de posición se calcularán en base al tipo de cliente y el " tipo de pedido que se quiere crear. " Para eso se llamará a la tabla ZTB_TIPO_POS y se recuperarán los " tipos de posición. " El estado del pedido será siempre "Abierto" METHOD crear_pedido_ventas.
Nadie se lee esto, además puede quedar fácilmente obsoleto al cambiar el contenido del método. Si el código se entiende, no hace falta hacer explicaciones de más.
Usa » para comentar, no *
Es preferible usar » para líneas de comentario porque se identan automáticamente al nivel donde aplican al usar Pretty Printer.
" Ejemplo Incorrecto CASE lv_estado. WHEN c_abierto. * Comentario en abierto
WHEN c_en_proceso. * Comentario en proceso
WHEN c_cerrado. * Comentario en cerrado
ENDCASE.
" Ejemplo Correcto CASE lv_estado. WHEN c_abierto. " Comentario en abierto
WHEN c_en_proceso. " Comentario en proceso
WHEN c_cerrado. " Comentario en cerrado
ENDCASE.
Borra el código en lugar de comentarlo
El código obsoleto debe ser eliminado en lugar de ser comentado para evitar confusión. Para algo está la gestión de versiones, el código que pasa por muchas manos y correcciones se vuelve imposible de leer.
No agregues prototipos ni comentarios de fin de métodos (INTERESANTE)
Los comentarios estándar de la firma de métodos o performs no aportan valor y generan ruido en el código. Estos comentarios pueden haber tenido sentido décadas atrás, cuando los entornos de desarrollo eran limitados, pero en los entornos modernos de ABAP (SE24, SE80, ABAP Development Tools en Eclipse), ya no son necesarios, porque la firma del método está fácilmente accesible con herramientas integradas.
" Ejemplo Incorrecto *&---------------------------------------------------------------------* *& Form CHECK_ORDER *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* * -->P_LV_ABAP_BOOL text * -->P_LV_COUNTRY text * -->P_LV_CUSTOMER_ACTIVE text * -->P_LV_HAS_DISCOUNT text * <--P_LV_TOTAL text * <--P_LV_SPECIAL_CUSTOMER text *---------------------------------------------------------------------- FORM check_order USING p_lv_abap_bool p_lv_country p_lv_customer_active p_lv_has_discount CHANGING p_lv_total p_lv_special_customer.
" Ejemplo Correcto FORM check_order USING p_lv_abap_bool p_lv_country p_lv_customer_active p_lv_has_discount CHANGING p_lv_total p_lv_special_customer.
En Conclusión
Me ha quedado algo largo, y eso que he hecho una selección de las recomendaciones que me parecen más interesantes. A pesar de eso, además yo tengo alguna manía más que realizo en mi día a día (no voy a añadir más leña). En entradas posteriores seguiremos hablando de esto pero desde un punto de vista de comprobar la calidad del código existente.
Por último, si solo me tuviese que quedar un un básico, diría:
Hoy traigo Mitología Griega que me encanta, todo muy coherente con el sentido del blog (no). Bueno, veréis como sí tiene que ver con nuestra profesión (o cualquiera) y las motivaciones, debilidades y fortalezas humanas.
(Todas las imágenes han sido generadas con ChatGPT y Dall-E 3)
El Mito de Ícaro
Cuenta la leyenda de la mitología griega que Ícaro era el hijo de Dédalo, un talentoso inventor y arquitecto ateniense. Dédalo era famoso por haber construido el Laberinto en Creta, donde el rey Minos encarceló al Minotauro (esa es otra historia), una criatura mitad hombre y mitad toro.
Sin embargo, tras ayudar a Teseo a matar al Minotauro y escapar del Laberinto, Dédalo cayó en desgracia con el rey Minos. Como castigo, el rey Minos encerró a Dédalo y a su hijo Ícaro en una torre alta en Creta para evitar que escaparan y difundieran los secretos del Laberinto. Sin embargo, Dédalo, con su ingenio, ideó un plan para huir: construir alas hechas de plumas de aves y cera para Ícaro para poder volar sobre el mar y escapar de la isla.
Antes de iniciar el vuelo, Dédalo advirtió a Ícaro que no volara demasiado alto ni demasiado bajo. Si volaba demasiado bajo, el agua del mar empaparía las alas y lo haría caer. Si volaba demasiado alto, el calor del sol derretiría la cera que mantenía las plumas unidas.
Lleno de emoción por la experiencia de volar, Ícaro olvidó las advertencias de su padre y, embriagado por la sensación de libertad, comenzó a ascender cada vez más alto en el cielo. Al acercarse demasiado al sol, la cera de sus alas comenzó a derretirse, haciendo que las plumas se desprendieran. Sin posibilidad de mantener el vuelo, Ícaro cayó desde el cielo y se hundió en el mar, donde se ahogó. El lugar donde Ícaro cayó fue nombrado en su honor: el Mar Icario.
Reflexión sobre el Mito de Ícaro
La leyenda de Ícaro se puede interpretar como una advertencia sobre los peligros de la desmesura, el exceso de confianza y la desobediencia. La ambición de Ícaro lo llevó a ignorar los límites y las precauciones, lo que resultó en su caída.
Para mi, o sobre lo que yo quiero reflexionar en este artículo, es que hay que tener cuidado con la ambición, saber medir los riesgos, controlarse y controlarlos. Nada es gratis y, si intentas volar muy cerca del sol, es muy posible que te quemes.
Así que la próxima vez que sientas el deseo de volar más alto que nunca, recuerda que incluso el cielo tiene sus límites. Pero, claro, eso no significa que no debamos intentar volar.
El Mito del Ave Fénix
En un rincón lejano del mundo, mucho antes de que la humanidad pudiera siquiera imaginar criaturas fantásticas, existía un ser único, majestuoso y envuelto en misterio: el Ave Fénix. Era un ave radiante como ninguna otra, con plumas doradas y rojas que parecían llamas vivientes. Pero lo que hacía especial al Fénix no era solo su belleza, sino su increíble capacidad para renacer de sus propias cenizas.
Cuenta la leyenda que el Fénix vivía en un paraíso escondido, donde el tiempo pasaba de manera diferente. Su vida no era corta como la de otras aves, sino que duraba siglos. Sin embargo, el Fénix sabía que, al igual que todo en el universo, su tiempo también llegaría a su fin. Cuando empezaba a sentir el peso de los años y la fatiga en sus alas, el Fénix se preparaba para el gran momento: su renacimiento.
Cuando el tiempo llegaba, volaba hasta lo más alto del cielo y, desde allí, descendía en un vuelo majestuoso hacia su nido hecho de ramas de especias y plantas aromáticas. Una vez en su nido, el Fénix dejaba que las llamas lo envolvieran, ardiendo con un fuego brillante y purificador. Todo su cuerpo se consumía en ese fuego, hasta que no quedaba más que un montón de cenizas.
Pero aquí es donde ocurría el milagro: de esas mismas cenizas, entre el humo y el calor residual, nacía un nuevo Fénix, joven y lleno de vida. Con un poderoso aleteo, este nuevo ser emergía, más hermoso, con más energía y más resplandeciente que antes. Y así, una y otra vez, el Fénix vivía y moría, solo para resurgir con más fuerza.
Reflexión sobre el Mito del Ave Fénix
Resumen rápido: Cuando te caes, te levantas, aprendes y mejoras.
El mito del Ave Fénix es un poderoso mensaje sobre resiliencia, renacimiento y esperanza. El Fénix simboliza la capacidad de resurgir de las cenizas, incluso después de haber pasado por momentos de destrucción o pérdida.
Este mito nos recuerda que, aunque atravesemos dificultades, fracasos o situaciones dolorosas, siempre existe la posibilidad de volver a levantarse y comenzar de nuevo, renovados y fortalecidos.
¿Por qué cuento esto? ¿Qué relación tiene?
Bueno, digamos que es una reflexión personal que estoy contando en público. Es muy fácil convertirse en Ícaro, querer volar demasiado cerca del sol pero que tus capacidades, tu entorno, las alas que tienes o el destino donde quieres volar te hagancaer, y la caída esdura.
Pero es más difícil, una vez habiéndote convertido en cenizas, como el Ave Fénix, al volar tan cerca del Sol, resurgir de tus cenizas, aprender de los errores y hacer que ese tropiezo sea una lección aprendida que te haga resurgir con más fuerza, siendo más consciente de lo bueno que tienes y queriendo mejorar.
Jorge Ocampos 