Se pueden leer cientos de tutoriales que te dicen como hay que trabajar, pero muchos de ellos son muy "olvidables" o dificiles de aplicar.
Por eso, la idea es hacer una síntesis de lo que realmente sirve y detectamos que valen la pena.
Todo es discutible y dependiendo del grado de profesionalismo algunos de estos pueden no aplicar, jeje
* Cada objeto de la aplicación que sea modificado conviene incluirlo en un proyecto.
Esto no es capricho!! es que tenemos una herramienta que recorre lo proyectos y te puede dar una lista de todos lo proyectos que usan un objeto determinado.
* Convención de nombrado de los proyectos.
(Empresa)_(Fecha)_(Indicador de Solicitud)_(Nombre Explicativo)
Ej: MPH_20090622_001_SourceCodeMix
Indicador de Solicitud: Las modificaciones realizadas por nosotros (sin que sea un requisito de un usuario en cuestión) tiene la denominación:
09x donde 0 = Ale, 1= Nico1, 2 = Nico2, 3 = Dani y 4 = [Nuevo]
Si somos tan originales de inventar más de un proyecto por día, entonces nos ponemos de acuerdo a los gritos!
Claro, el criterio puede variar según la cantidad de desarrolladores!
* Entornos
Desarrollo (Capa de USR)
Todos (o casi todos) nuestros desarrollos se hacen en estos ambientes.
A veces esto no se puede hacer porque el error o dato concreto depende del dato del cliente en concreto, así que so usan lo ambientes del prueba del cliente o... Productivo??? (con mucho cuidad claro, pero si hay urgencia..)
Testing (Capa de USR y CUS)
Para pruebas o si no se quiere interferir con los otros desarrolladores. Todas las pruebas se hacen en capa USR, pero se deben borrar al abandonar el ambiente.
Luego de aquí se genera un versión definitiva para productivo.
Productivo (Capa CUS)
Nunca, pero nunca se desarrolla en este ambiente!! Sólo se usa para tener un reflejo real del ambiente de productivo y para ver el posible impacto de la aplicación de un desarrollo al ser importado en el ambiente real.
* Convención de nombrado
Todas las tablas y clases que creamos tendrá el prefijo de la companía para la que se realizan.
Personalmente encuentro esta convención bastante desagradable, ya que al estar en una capa distinta a la del sistema debería bastar para distingir un objeto propio de uno del sistema.
Pero a sistema heredado no se le miran los dientes... Así que continuamos con la convención!
Otra cosa que es muy frea es que se pierde la lógica de Ax que relaciona por módulo y que permite un seguimiento rápido por nombre.
Ej: MPH_SecurityInjection
* Si se quiere hacer una funcionalidad paralela a la del sistema nunca duplicar un método, sino modificarlo. Si quiere mantener ambas versiones crear una clase heredada que pise el método con el mismo nombre pero que tenga un funcionalidad distinta
0 comentarios:
Publicar un comentario