Amigandonos con el entorno de desarrollo

Algunas buenas prácticas para tener en cuenta:

Control de versiones

Esto mismo lo hacemos varias veces al día y antes de subir algo nuevo al repositorio. Siempre corro los tests y si alguno da error, bueno, alguien subió algo indebido. Los tests y el repositorio nos ayudan a entender cuándo se rompió y por qué.

Git

A continuación te damos una lista de posibles recursos que deberían estar en el archivo .gitignore:

Eclipse

Por ejemplo, en un proyecto completo tener paquetes para el “dominio”, “controllers” y “vista” (si correspondiese) es una convención común. Cada uno de éstos agrupa las clases que tienen un concepto afín. Se podría seguir ahondando en la definición de subpaquetes agrupando, por ejemplo, por componente:

domain/
   ├── home
   ├── registration
   │   ├── Profile.java
   │   └── User.java
   └── settings
       ├── CustomPrivacy.java
       ├── DefaultPrivacy.java
       ├── Privacy.java
       └── Setting.java

De esta manera, logramos mayor granularidad en la organización de nuestras clases.

Otro uso de los paquetes, también relacionado con el concepto anteriormente mencionado Convention over Configuration, es el de identificar unívocamente a una aplicación. ¿Qué significa ésto? Que las clases que yo defina formen parte de un meta grupo que los identifique, y así evitar colisiones en los nombres que yo les ponga. Por ejemplo: yo puedo definir la clase Color, pero la api de Java AWT ya define una clase Color.

Es por este motivo que se utiliza el dominio de internet de la organización, pero “dado vuelta”. Por ejemplo si trabajamos para Google sería común encontrar paquetes del estilo com.google.blah. Para el ejemplo de Color, la api de Java la define como java.awt.Color. En nuestro caso podríamos usar, por ejemplo: ar.edu.materiaQueCursan.paquete.