Leyendo el libro de Steven Feuerstein Oracle PL/SQL Programming 5ta ed. -el cual es dicho sea de paso material de referencia altamente recomendado para quienes desarrollan en PL- comparte los siguientes consejos que en su opinión son el resultado de haber capacitado, enseñar y trabajar con miles de desarrolladores en PL y en cuyo proceso ha obtenido algunas conclusiones sobre la forma en la que todos hacemos nuestro trabajo en el mundo de PL/SQL.
Falso. Si nos metemos así de pronto y de lleno a construir código convirtiendo al pie de la letra los requerimientos en cientos, miles o incluso cientos de miles de líneas de código, vamos a terminar con un caos total que es casi imposible de depurar y mantener.
No hay que entrar en pánico ante las fechas de entrega; lo más probable es que cumplas si haces una cuidadosa planeación.
Steven recomienda a resistir la presión de la entrega y a asegurarse de hacer lo siguiente antes de comenzar una nueva aplicación, o inclusive alguna parte específica de la aplicación:
Construir casos y scripts de prueba antes de escribir el código
Debes determinar como vas a verificar una implementación exitosa antes de escribir una sola línea código del programa. Haciéndolo, es más probable que la interfaz de tu programa sea la correcta, e identifiques plenamente qué es lo que tu programa necesita hacer.
Establecer reglas claras de como los desarrolladores escribirán las sentencias SQL en la aplicación
En general, Steven no recomienda que cada desarrollador escriba montones de SQL. En vez de eso, los queries que regresan un solo registro, inserts y updates deberían estar "ocultos" en procedimientos y funciones preconstruídos y bien probados (llamado encapsulamiento de información). Estos programas se pueden probar, optimizar y mantener de una manera más efectiva que solo sentencias SQL (algunas de ellas redundantes) desparramadas por todo el código.
Establecer reglas claras de como los desarrolladores manejarán las excepciones en la aplicación
Todos los desarrolladores del equipo deberían lanzar, manejar y registrar los errores de la misma manera. Para lograrlo, lo mejor es crear un solo paquete de manejo-de-errores que oculte los detalles de como se registran estos, que establezca como se lanzan y propagan las excepciones hacia arriba a través de bloques anidados, y que evite la codificación en duro de excepciones específicas-de-la-aplicación. Asegurarse de que todos usen ese paquete y que no escriban su propio código de manejo de errores complicado, que consume tiempo y que es propenso a errores.
Usar el "refinamiento paso a paso" (también llamado diseño top-down) para limitar la complejidad de los requerimientos a enfrentar en un momento dado
Si utilizas este enfoque, verás que las partes ejecutables de tus módulos son cortos y fáciles de entender, lo que hace que el código sea fácil de mantener y de mejorarlo con el tiempo. Los módulos locales o anidados juegan un papel clave en el seguimiento de este principio de diseño.
Estas son solo unas cuantas cosas importantes a tener en cuenta para antes de comenzar a escribir todo ese código. Solo recuerda: en el mundo del desarrollo de software, la prisa no solo hace cosas frágiles, prácticamente garantiza un generoso ofrecimiento de bugs y de fines de semana perdidos.
¡No desarrolles a las prisas!
Casi siempre estamos trabajando con tiempos de entrega apretados, o poniéndonos al día por alguno que otro contratiempo. No tenemos tiempo que perder y si mucho código que escribir. Asi que manos a la obra—¿cierto?Falso. Si nos metemos así de pronto y de lleno a construir código convirtiendo al pie de la letra los requerimientos en cientos, miles o incluso cientos de miles de líneas de código, vamos a terminar con un caos total que es casi imposible de depurar y mantener.
No hay que entrar en pánico ante las fechas de entrega; lo más probable es que cumplas si haces una cuidadosa planeación.
Steven recomienda a resistir la presión de la entrega y a asegurarse de hacer lo siguiente antes de comenzar una nueva aplicación, o inclusive alguna parte específica de la aplicación:
Construir casos y scripts de prueba antes de escribir el código
Debes determinar como vas a verificar una implementación exitosa antes de escribir una sola línea código del programa. Haciéndolo, es más probable que la interfaz de tu programa sea la correcta, e identifiques plenamente qué es lo que tu programa necesita hacer.
Establecer reglas claras de como los desarrolladores escribirán las sentencias SQL en la aplicación
En general, Steven no recomienda que cada desarrollador escriba montones de SQL. En vez de eso, los queries que regresan un solo registro, inserts y updates deberían estar "ocultos" en procedimientos y funciones preconstruídos y bien probados (llamado encapsulamiento de información). Estos programas se pueden probar, optimizar y mantener de una manera más efectiva que solo sentencias SQL (algunas de ellas redundantes) desparramadas por todo el código.
Establecer reglas claras de como los desarrolladores manejarán las excepciones en la aplicación
Todos los desarrolladores del equipo deberían lanzar, manejar y registrar los errores de la misma manera. Para lograrlo, lo mejor es crear un solo paquete de manejo-de-errores que oculte los detalles de como se registran estos, que establezca como se lanzan y propagan las excepciones hacia arriba a través de bloques anidados, y que evite la codificación en duro de excepciones específicas-de-la-aplicación. Asegurarse de que todos usen ese paquete y que no escriban su propio código de manejo de errores complicado, que consume tiempo y que es propenso a errores.
Usar el "refinamiento paso a paso" (también llamado diseño top-down) para limitar la complejidad de los requerimientos a enfrentar en un momento dado
Si utilizas este enfoque, verás que las partes ejecutables de tus módulos son cortos y fáciles de entender, lo que hace que el código sea fácil de mantener y de mejorarlo con el tiempo. Los módulos locales o anidados juegan un papel clave en el seguimiento de este principio de diseño.
Estas son solo unas cuantas cosas importantes a tener en cuenta para antes de comenzar a escribir todo ese código. Solo recuerda: en el mundo del desarrollo de software, la prisa no solo hace cosas frágiles, prácticamente garantiza un generoso ofrecimiento de bugs y de fines de semana perdidos.
Continuar leyendo...
