Estándares de Desarrollo

De Thubanpedia
Revisión a fecha de 11:55 15 oct 2014; Vivatia (Discusión | contribuciones)

(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Saltar a: navegación, buscar


Estándares de desarrollo

Infraestructura

- IE 6 y 7 / Firefox 3.x
- MS-SQL 2000/2005
- JDK 1.4.2
- Tomcat 5.0.28


Librerías Java

- ZK 3.6.2
- Spring 2.5.5
- Spring Security 2.0
- Spring Security ZK 1.2.0
- Spring LDAP 1.2.1
- Jasper Reports 2.0.4
- Axis 1.4
- Hibernate 3.1
- C3P0 0.9.1.2
- Velocity 1.5
- Quartz 1.5.2
- PDFBox 0.7.3
- Log4j 1.2.14
- JUnit 3.8.1
- JAI 1.1.2
- ImageIO 1.1.0
- Java Mail 1.4
- Activation 1.1
- Apache Commons
   - Collection 3.2.1
   - Codec 1.3
   - io 1.3.1
   - logging 1.1.1
   - pool 1.3
   - lang 2.3
   - Discovery 0.2
   - Beanutils 1.7
   - fileupload 1.2.1
   - beanutils 1.7.0
   - Digester 1.7
- iText 1.3.1
- JTDS 1.2
- MySQL Connector 5.0.5
- Antlr 2.7.6rc1
- Asm 1.5.3
- aspectjweaver 1.5.3
- avalon-framework 4.1.3
- bcmail-jdk-136
- bcprov-jdk-136
- bsh 2.0b4
- Cglib 2.1_3
- Dom4j 1.6.1
- EH Cache 1.1
- Fontbox 0.1.0
- JCommon 1.0.0
- Jempbox 0.2.0
- Jfreechart 1.0.3
- POI 3.0.1 FINAL
- Xerces 2.6.0
- Xml-api 1.3.02
- XmlParserAPI 2.6.0
- XmlSec 1.4.0

Nomenclaturas del modelo de base de datos de Thuban®

Valores generales a todas las nomenclaturas

Los nombres de todos los objetos del modelo de Thuban® deben ser expresados en mayúsculas y en ningún caso pueden superar los treinta caracteres. Las palabras se deben separar con guión bajo y se preferirá que los nombres estén expresados en inglés.

Nombre de tablas

Los nombres de tablas están compuestos por dos partes separadas por un guión bajo.

La primera indica la pertenencia de la tabla y puede ser:

THUBAN Tablas internas de Thuban®
BPM Tablas de los procesos internos
JBPM Tablas de Workflow externo
QTZ Tablas de Quartz
IMT Tablas Legacy del PowerDesk de 32bit
SOL_EP Tablas de la solución de exportación de paquetes
[cliente]_[solución] Tablas particulares a la solución de un cliente*

*La segunda hace referencia a la finalidad de la tabla por ejemplo “USERS” o “MONITOR_RESULT_HISTORY” que contiene los datos de los usuarios y de la historia de los resultados de los monitores, respectivamente.


Nombre de columnas

Los nombres de las columnas están compuestos por dos partes separadas por un guión bajo. La primera hace referencia a la tabla a la que pertenece formando una sigla con la segunda parte del nombre, por ejemplo las columnas pertenecientes a “SOL_EP_DEF” o “THUBAN_MAIL_TEMPLATE” comenzaran con “D_” o “MT_”, respectivamente. La segunda parte del nombre de una columna hace referencia a los datos almacenados en la misma, por ejemplo “FC_ID” contiene los IDs de la tabla “THUBAN_FOLDER_CHECKLIST” y “FC_LINK_CLASS” contiene una FK a “THUBAN_DLINK” a la columna “CLASS_ID”.


Constraints

Al momento de la creación, se deben nombrar todas las restricciones y claves con los siguientes parámetros:

  • Las claves primarias llevarán de prefijo el nombre de la tabla y de sufijo, “PK”.
  • Las claves externas llevaran como prefijo “FK_” seguido por la sigla de la tabla base, guión bajo, la tabla destino y un número secuencial a las claves externas pertenecientes a la tabla.
  • Las restricciones del tipo único deben tener el prefijo “UQ__” seguido del nombre de la tabla a la que pertenecen y un número secuencial a las restricciones del tipo único que tiene la tabla.


Tipos de Datos

Por la utilización de Liquibase y la compatibilidad con distintos RDBMS, los tipos de datos aceptados, expresados en genérico, serán:


java.sql.Types.VARCHAR Para caracteres con un máximo de 4000 (MSSQL varchar, ORACLE varchar2).
java.sql.Types.INTEGER Para valores numéricos (MSSQL int, ORACLE number).
BOOLEAN Para valores boléanos (MSSQL bit, ORACLE number(1)) se prefiere este tipo de dato frente a un varchar(1) o un tinyint.
BLOB Para valores de byte (MSSQL image, ORACLE blob).
CLOB Para valores de caracteres (MSSQL text, ORACLE clob).
TINYINT Este tipo de dato no es admitido. Se puede reemplazar por un objeto del tipo BOOLEAN.

Estándares de código

  • Se utiliza siempre SUN Coding Style, a menos que se especifique lo contrario.
  • Se utiliza el guión bajo para variables privadas y protegidas de clases que no sean entidades ni componentes de UI.
  • Los prefijos para componentes de UI son:


COMPONENTE PREFIJO
Combobox cbo
List lst
Textbox txt
Checkbox chk
Radiobutton rdb
Grid grd
Groupbox grp
Label lbl


Métodos

  • Los nombres de métodos deben estar en inglés, pero se pueden poner comentarios en español.
  • Si se retorna un boolean, debe comenzar con el prefijo “is-”. Por ejemplo isValid();
  • Los eventos de UI deben comenzar con el prefijo “on-”. Esta condición ya es requerida en ZK para forward event, pero no para los casos en los que se extiende el componente de UI.
  • Los acrónimos de extensiones pueden ser utilizados en mayúsculas rompiendo la convención de letras mayúsculas. Por ejemplo: getPDFReader se entiende mejor que getPdfReader por más que no respete la convención.
  • Se debe comentar los métodos que tengan lógicas complejas (por ejemplo muchos “if” anidados) o que incorporen un factor de conversión (por ejemplo multiplicar por 3600 para pasar de horas a segundos).
  • Los “if” deben comenzar por la secuencia de ejecución más frecuente.

Variables

  • Las variables de clase con valores nulos se deben inicializar en "null-".
  • Los nombre de las variables deben tener sentido. No se debe utilizar variables tipo "aux" o "listc1".

Manejo de Excepciones

  • No dejar catch con ex.printStackTrace en ningún caso. En última instancia, se debe disparar un RuntimeException utilizando la excepción como parámetro del constructor.


Internacionalización (i18n)

  • Las keys de los archivos i3label deben estar en inglés.
  • Los archivos de i3label deben tener el mismo orden de keys en español e inglés para que sea más fácil para comparar.


  • La key se debe componer, para componentes de UI, por:

- Nombre de la clase java que controla la vista. Ejemplo: displayUI.

- Id o nombre de variable del componente. Ejemplo: btnSave.

- Propiedad del componente a establecer. Ejemplo: label o tooltip.


  • El messagebox se debe estar compuesto por:

- Nombre de la clase java que controla la vista. Ejemplo: displayUI.

- El prefijo "msg" seguido de la abreviación en ingles del tipo de mensaje. Ejemplo: msgInf, msgQst, msgWrn o msgErr.

- Descripción breve del mensaje. Ejemplo: msgQstDelete.

Commit

  • Al realizar un commit se debe agregar en un comentario el número de incidente de JIRA para que queden vinculados.