Buenas prácticas

Usar una estructura de proyecto estándar

src
    ├── main
    │   ├── java                   Application/Library sources
    │   ├── resources              Application/Library resources
    │   ├── filters                Resource filter files
    │   └── webapp                 Web application sources
    │   
    └── test
        ├── java                   Test sources
        ├── resources              Test resources
        └── filters                Test resource filter files

Nomenclatura

• Los nombres de clases e interfaces deben ser sustantivos y tener la primera letra en mayúscula.
• Los nombres de métodos deben ser verbos.
• Los nombres de variables deben ser cortos y significativos.
• Los nombres de paquetes deben ir en minúsculas.
• Las constantes deben ir en mayúsculas.

Legibilidad frente a reutilización

La reutilización es uno de los conceptos más defendidos en el desarrollo de software. Disminuye el tiempo de desarrollo y reduce el esfuerzo necesario para mantener el software cuando los desarrolladores comprenden muy bien los componentes reutilizables.

Aunque el concepto de reutilización suena muy bien y tiene muchos beneficios, también tiene muchas trampas potenciales, especialmente cuando se trabaja en una base de código desconocida. Cuando se trabaja con aplicaciones de gran tamaño, la reutilización del código puede reducir la legibilidad, la usabilidad y la mantenibilidad si no se cuenta con un diseño adecuado.

Una mala legibilidad del código dificulta la depuración y aumenta el esfuerzo necesario para mantener la base de código. Esto puede suponer un reto, especialmente cuando se trata de incorporar nuevos desarrolladores al proyecto. Por lo tanto, cuando desarrolle software, asegúrese de no priorizar la reutilización sobre la legibilidad.

Mejorar el código con herramientas de análisis estático y dinámico

Usar comentarios útiles y documentar

El uso adecuado de los comentarios y la documentación puede desempeñar un papel importante en la escritura de código Java limpio. Aunque el código debe ser legible y autoexplicativo, a veces es imposible evitar la lógica compleja. Sin embargo, usando comentarios estratégicos dentro del código, puedes explicar la lógica detrás de algunas partes del código que no son sencillas.

En Java, los desarrolladores pueden aprovechar dos tipos de comentarios: los comentarios de documentación y los comentarios de implementación. Los comentarios de documentación se dirigen a los usuarios de la base de código, mientras que los comentarios de implementación están pensados para los desarrolladores que trabajan en la base de código.

Uso coherente y adecuado del formateo de código

Mantener un formato y un estilo de codificación coherentes en su equipo y su base de código es importante si desea escribir un código Java limpio en equipo. Los espacios en blanco y la sangría son esenciales para mantener un estilo de codificación coherente.

Restringir el número de parámetros en los métodos

Demasiados parámetros pueden indicar que el método aborda más de un problema y viola el principio de responsabilidad única.

Aprovechar las pruebas unitarias y el desarrollo basado en pruebas (TDD)

Las pruebas unitarias consisten en escribir pruebas para funciones, métodos y clases individuales con el fin de garantizar que funcionan de forma aislada. TDD también es una práctica de desarrollo popular que consiste en escribir pruebas antes del código.

Principios SOLID

• Principio de responsabilidad única (SRS): El principio de responsabilidad única establece que una clase solo debe tener una responsabilidad. Seguir el principio SRS garantiza que escribimos código conciso, legible y mantenible.
• Principio abierto-cerrado (OCP): El OCP establece que las clases deben estar abiertas para la extensión, pero cerradas para la modificación, excepto cuando se corrigen errores. Este principio le permite agregar nuevas características sin introducir errores o romper la funcionalidad existente. En Java, puede utilizar interfaces o clases abstractas para ampliar la funcionalidad de las clases existentes.
• Principio de sustitución de Liskov (LSP): El principio LSP establece que deberíamos poder usar superclases con sus respectivas subclases indistintamente sin romper la funcionalidad de nuestro programa. El uso de este principio le permite utilizar la herencia correctamente y escribir código Java limpio desacoplado.
• Principio de segregación de interfaz (ISP): Este principio establece que debemos optar por interfaces enfocadas más pequeñas en lugar de grandes monolíticas. El uso de este principio nos permite escribir código Java modular y limpio donde las clases de implementación se centran solo en los métodos que les conciernen.
• Principio de inversión de dependencia (DIP): Este principio enfatiza el acoplamiento flexible, garantizando que los componentes como las clases solo dependan de abstracciones y no de sus implementaciones concretas. DIP nos ayuda a aplicar código Java limpio utilizando Inversion of Control (IoC) e inyección de dependencias.

Principios KISS y DRY

El principio DRY establece que, como desarrollador, debe asegurarse de que su código no se duplica varias veces en el sistema. Eliminar la duplicación de código mejora la capacidad de mantenimiento del código y facilita la búsqueda y corrección de errores.

El principio KISS enfatiza que debemos esforzarnos por mantener el diseño y el desarrollo del software que construimos simple y directo.

La estructura de los archivos fuente

Un archivo fuente típico en Java contiene diferentes elementos que son clave en la ejecución de cualquier programa Java. Para mantener la legibilidad de su código, debe aplicar una estructura coherente del archivo fuente. Aunque no existe un enfoque único para estructurar su archivo fuente, hay guías de estilo populares que puede seguir.

Normalmente, un orden típico de la estructura de un archivo fuente en Java comienza con las sentencias package seguidas por las sentencias import estáticas y no estáticas, precedidas por una clase primaria de nivel superior.

    // Class variables
    private static int count;
    private String name;
    
    // Instance variables
    private int age;
    private List<String> hobbies;
    // Constructors
    public MyClass() {
        // Constructor implementation
    }
    
    public MyClass(String name, int age) {
        // Constructor implementation
    }
    
    // Methods
    public void setName(String name) {
        // Method implementation
    }
    
    public String getName() {
        // Method implementation
    }
    
    public void addHobby(String hobby) {
        // Method implementation
    }
    
    // Other methods
    
}
// Additional classes (if any)
class MyStaticClass {
    // Class implementation
}

Evitar la codificación rígida de valores

La codificación rígida consiste en incrustar valores directamente en el código fuente del programa en lugar de utilizar variables. Alterar el código fuente de su programa es la única manera de cambiar los valores codificados en sus programas. Los valores codificados limitan la reutilización y la capacidad de prueba y también puede conducir a la duplicación y el comportamiento no deseado de su programa.

Para mejorar la reutilización, comprobación y mantenimiento del código, que son características clave de un código Java limpio, es importante que evite los valores codificados de forma rígida en el código fuente de su programa. En su lugar, sustituya los valores codificados por abstracciones como variables constantes o enums.

---

Referencias

• https://dzone.com/articles/best-practices-for-writing-clean-java-code?edition=836496