Galileo Educational System
Not logged in
|
Galileo Educational System
|
Not logged in
|
|
ESTANDARES DE DESARROLLO DE APLICACIONES PARA EL “TEAM GES”
Los estandares de desarrollo son sumamente importantes cuando estamos tratando con aplicaciones complejas ya que se hace dificil poder analizar secciones de la aplicacion. Cuando estamos revisando alguna seccion de la aplicacion se espera que dicha seccion tenga un orden y que el nombramiento tanto de los archivos como de las variables sigan una convencion esperada. Las cosas deben de estar estructuradas de una forma coherente para poder facilitar la busqueda dentro de la aplicacion.
Es muy molesto tener que perder el tiempo tratando de decifrar o rastrear secciones de codigo que no hemos escrito nosotros mismos; especialmente si la aplicacion cuenta con miles de lineas codigo y miles de archivos.
Es importante que sigamos estandares de desarrollo en nuestas aplicaciones para que otras personas puedan leer nuestro codigo y entender lo que esta pasando en la aplicacion; incluso, es importante para nosotros mismos ya que algunas personas no recuerdan la logica que utilizaron para desarrollar ciertas secciones de codigo despues de cierto tiempo.
Los estandares que se mencionan en este documento no se limitan a la codificacion de la aplicacion; el estandarizar una aplicacion inicia desde que la aplicacion se esta disenando.
Asi que definiremos algunos estadndares para las diferentes etapas que una aplicacion sufre.
DISENIO DE LA APLICACION:
Antes que nada escriba las ideas que tiene de la aplicacion en algun lugar en donde otras puedan revisarlas, por ejemplo en nuestro Wiki http://ges.galileo.edu/xowiki.
Muestre las ideas basicas de la aplicacion a otras personas. El ejercicio de que otras personas puedan revisar sus ideas iniciales le ayuda a obtener comentarios positivos acerca de la aplicacion; es bueno siempre estar abierto a recibir comentarios sobre las ideas que escribimos, esto amplia nuestro criterio y le da una mejor calidad a las ideas que queremos desarrollar.
Luego de tener claras las ideas que se van a desarrollar; realice un diagrama de la navegacion que va a tener la aplicacion. Identifique las paginas que se necesitan desarrollar junto con la funcionalidad que debe de ser incluida en cada una de las paginas; esto le ayudara a definir de groso modo cual sera la estructura general de su aplicacion. Es conveniente que esto tambien sea expuesto ante otras personas para poder obtener comentarios sobre la estructuracion que se ha disenado.
Defina los objetos que va a utilizar en su aplicaciones y las propiedades que dichos objetos van a tener. Es importante definir en este punto la interaccion que sus objetos van a tener con los diferentes servicios que la plataforma provee; como por ejemplo, si vamos a utilizar el sistema de permisos o el sistema de notificaciones. Estas desiciones influyen directamente en la codificacion que tengamos que realizar posteriormente.
CODIFICACION DE LA APLICACION:
Las aplicaciones que se escriban deben de seguir la convencion de estructura de paquetes que se define en el toolkit OpenACS (http://openacs.org/doc/current/packages.html).
Desde el momento en que los archivos de la aplicacion son creados deben ser agregados a nuestro sistema de versiones. Es extremadamente importante que continuamente este guardando en el repositorio los cambios que la aplicacion va sufriendo, esto como una medida de seguridad para usted.
Antes de empezar a codificar defina el conjunto de “test cases” que prueban “al menos” la funcionalidad basica que su aplicacion va a proveer. El escribir estos scripts de test le ahorrara mucho tiempo en el futuro cuando se introduzca nueva funcionalidad a su aplicacion ( funcionalidad que podria afectar el funcionamiento basico ).
Crear los scripts de base de datos que crean el modelo relacional que utlizara su aplicacion. Es importante que tambien se provean scripts que borren el modelo de datos de una manera coherente. Para la creacion de estos scripts existen standares importantes que debemos de tomar en cuenta:
Seguir los estandares en los nombres de los constraints que se utilizan (http://openacs.org/doc/current/eng-standards-constraint-naming.html).
Utilice indices en aquellos campos los cuales van a estar involucrados en busquedas; esto hara que el tiempo de respuesta de su aplicacion se reduzca sustancialmente.
Crear scripts que contiene las procedimientos que integraran sus librerias. En este punto es importante mencionar:
Definir los argumentos de los procedimientos como “switch's” y no como argumentos posicionales; esto hara mucho mas coherente la utilizacion de los procedimientos alrededor de la aplicacion. Esto ayuda a que las llamadas a procedimientos sean los mas explicitas posible.
Documente los procedimientos; es importante escribir un pequeno resumen sobre el proposito del procedimiento, asi como tambien lnda descripcion de cada uno de los parametros ( que valores podrian tomar ) y tambien describa el valor de retorno del procedimiento.
Utilice “namespaces” para los procedimientos de su aplicacion. Esto elimina posibles duplicidades entre los nombres de sus procedimientos y los de otra aplicacion.
Creacion de las paginas que son mostradas al usuario:
En este punto es indispensable seguir las convenciones de nombramiento de archivos que se definen en dentro de OpenACS (http://openacs.org/doc/current/eng-standards-filenaming.html). Idealmente el nombre del archivo debe de reflejar el contenido del mismo, por ejemplo si el archivo ejecuta alguna operacion en especifico o si contiene un conjunto de procedimientos para un fin en comun.
Documente las paginas. Escribe un pequeno resumen de la accion que la pagina realiza.
Recomendaciones generales para librerias y paginas mostradas al usuario:
Utilice archivos .xql para colocar los queries. Coloque aquellos queries que son especiales para postgresql en los archivos *-postgresql.xql ( utilice la misma analogia para aquellos que son dependientes de ORACLE ).
Utilice nombres de variables que denoten el significado de la misma; ver una variable con nombre “var_1” no agrega nada al contexto del codigo que estamos escribiendo. La idea es facilitar el entendimiento del codigo al ser leido por otra persona o incluso por nosotros mismos.
En lo posible, no mezclar codigo html con codigo tcl; ni mucho menos utilizar codigo html en los queries de sql; esto hace dificil el hecho de rastrear un problema relacionado con html mal generado. Limitese a utilizar codigo html en las paginas .adp.
Documente aquellas secciones de codigo que no son triviales; esto le facilitara en un futuro leer codigo facilmente, le ayuda a ahorrar tiempo.
TRASLADO DE LA APLICACION FINAL A EL AMBIENTE DE PREBAS:
Muestre su aplicacion a otras personas. Tome un grupo de personas que podrian comentarios constructivos a su aplicacion; es mucho mejor hacer cambios en esta etapa del desarrollo que realizarlos cuando la aplicacion esta siendo utilizada en produccion. Ademas, las personas que estan fuera del problema que esta usted resolviendo pueden darle un enfoque diferente que podria ayudar al usuario final; que al final, es el objetivo de todas las aplicaciones que desarrollamos.
Asegurese que todo lo que usted ha desarrollado esta guardado en el repositorio de control de versiones. Seguramente no querra que los usuarios se topen con cosas incompletas al utilizar su aplicacion.
Traslade su aplicacion al servidor de testeo. Realice una serie de operaciones para poner a prueba su aplicacion. Utilice datos que prodrian hacer que su aplicacion funcione.
Asegurese de correr sus “test cases” y que los mismos sean ejectutados con exito.
Idealmente en esta etapa de desarrollo, usted deberia de ejecutar tambien sus “test cases” que ponen a prueba la escalabilidad de su aplicacion; si no los tiene es un buen momento entonces para escribirlos.
Dependiendo de la naturaleza de su aplicacion, en algunos casos sera necesario utilizar scripts de upgrade o scripts de creacion de modelo de datos; es recomendable que estos upgrades se realicen utilizando el APM ( /acs-admin/apm ).
Si su aplicacion es una aplicacion totalmente nueva en GES, practique el proceso de instalacion de la aplicacion utilizando el APM.
Si se encontrar algun error en su aplicacion ( de cualquier tipo ); regrese a su ambiente de desarrollo y corrija el error. Luego de correjiro el error, repita todo el proceso para estar seguro de que su aplicacion funciona bien en el ambiente de pruebas.
TRASLADO DE LA APLICACION FINAL A PRODUCCION:
Actualice los archivos que sea necesario actualizar en el servidor de produccion.
Si la instalacion/upgrade de la aplicacion en el servidor de Produccion implica el reinicio del mismo; entonces se debera esperar el reinicio del GES, el cual se lleva acabo a las 4:30 a.m.
A continuacion se da una lista de casos en los que se necesita reiniciar el servidor de produccion.
Se necesita modificar modelo de datos: Esto implica que necesitamos que se ejecuten scripts sobre la base de datos en donde estamos agregando/modificando tablas, indices, constraints, etc. dentro de la base de datos.
Se necesita modificar/agregar funciones de plsql: Esto implica que necesitamos que se ejecuten scripts sobre la base de datos en donde estamos agregando/modificando funciones de plsql.
Se modificaron/agregaron archivos *-init.tcl: El contenido de un archivo cuyo nombre es de la forma *-init.tcl solamente es ejecutado 1 vez por el servidor. Y eso ocurre luego de que se han cargado todos aquellos procs que se encuentran en los direcotrios /tcl/ de los paquetes.
Se agregaron/modificaron definiciones de Service Contracts.
Es importante que tambien se identifique los casos en los que no es necesario realizar un reinicio del servidor:
Si solamente se aumento la version de un paquete para la creacion de un nuevo parametro.
Si solamente modificamos procs dentro dentro de archivos que NO pertenecen al patron *-init.tcl: Esto solamente requeriria recargar el paquete en cuestion.
Si modificamos cualquier archivo .adp o .tcl o .xql dentro del directorio /www/: En caso de modificar archivos .xql, es necesario solamente recargar el paquete en cuestion.
Si modificamos cualquier archivo .xql dentro del directorio /tcl: En este caso solamente se recarga el paquete en cuestion.
DIAGRAMA SOBRE EL CICLO DE DESARROLLO Y TRASLADO DE APLICACIONES A PRODUCCION.
Bad practices en codificacion: Algunos ejemplos de cosas que no se deben de hacer. La idea
es que todos aprendamos a no comenter los mismos errores: