Robert Martin, Código limpio. Reseña del libro sobre “código kung fu” para desarrolladores

¡Hola javarashevitas! Este artículo es una reseña del libro “Código Limpio” de Robert Martin. Juntos buscaremos formas de mejorar y optimizar su código y, al final, le espera una tarea pequeña pero interesante. Cada día, cuando abrimos nuestro editor de código, nos enfrentamos a muchas clases, funciones y variables. La mejor opción es si este es su código escrito desde cero, escrito una vez, tiene pocas líneas, está trabajando en él solo, no hay ediciones ni soporte adicional por parte del cliente. ¡PERO! Como muestra la práctica, sí, creo que usted mismo comprende que esto no sucede. Básicamente, tendremos que interactuar de alguna manera con los miembros de nuestro equipo, mantener el código "hindú" y analizar los productos en millones de líneas. A menudo he escuchado respuestas como ésta de mis compañeros de formación: "Este código lo escribí yo y no se lo voy a mostrar a nadie", pero cuando veo solicitudes de ayuda con dicho código en Ayuda, me lleva mucho tiempo. tiempo (a veces realmente mucho tiempo) para profundizar y comprender lo que la persona quería decirme, ¡incluso quiero decir “borra y vuelve a escribir”! Aprecia el tiempo y la energía de las personas que quieren ayudarte, escribe correctamente y si no sabes cómo, nunca es tarde para aprender. El libro de Robert Martin se destaca entre los libros de este formato porque contiene muchos ejemplos en Java. Esta puede ser una declaración un poco fanática de mi parte, pero está escrita en estilo OOP, es decir, en la redacción de partes y secciones. Fácil de entender y leer, el libro es fácil de leer mientras viaja o por la noche antes de acostarse. Clean Code se divide en 3 partes. En la primera parte, se nos pide que repasemos la teoría del libro, aprendamos sobre patrones de diseño y reglas de buenos modales. La segunda parte nos invita a practicar la refactorización y la escritura, y la tercera parte es el resumen final del código que “huele” en los ejemplos. Bueno, el autor tocó muchos temas para los cuales necesitarás principalmente conocimientos de Java Core, pero también hay secciones dedicadas a JUnit Unit Tests, Log4j Logging, conocimiento de los patrones más simples en diseño (pero como dije anteriormente, no hay muchos de ellos, y todo lo incomprensible se puede buscar en Google con éxito, sí y analizarlo en el curso JavaRush). Todos los capítulos del libro no están relacionados entre sí; puede comenzar a leer con éxito desde el capítulo que desee. Un breve resumen de las ideas principales que recogí del libro. Agradecería sus comentarios sobre las mismas, en los que pueda compartir su propia visión sobre estas afirmaciones.

1. Comentarios == maldad.

En la mayoría de los casos, los comentarios son muletas con las que intentamos tapar nuestro código incorrecto. Y en algunos casos, también mienten sobre el propósito de los métodos o variables si hay una refactorización constante del código.

2. Código comentado, código muerto.

Dejar estos fragmentos de código en su aplicación equivale a basura. El código no utilizado se acumula con el tiempo e interfiere con la limpieza de su aplicación; verifique el código de dichos módulos de vez en cuando.

3. Encabezados de métodos, clases y variables.

Vale la pena escribir artículos separados para discutir este tema. No seas perezoso y escribe nombres que puedan indicar su propósito. Aprenda algunos estándares en la ortografía de títulos. Este tema es “imprescindible” para un estudio detallado.

4. Cada método y variable tiene su lugar en la jerarquía de clases.

Normalmente, una clase puede tener variables y métodos (estáticos y no estáticos), un constructor, clases anidadas e internas, y enumeraciones. En definitiva, hay mucha información y es necesario determinar el lugar de cada uno en la clase. Si miras las clases principales de Java, verás que la estructura está claramente estructurada, podemos ver cada parte en su lugar, por supuesto en tus proyectos puede cambiar dentro del proyecto, pero no en cada clase. Para mí, he definido la siguiente estructura de construcción: al comienzo de la clase tengo variables estáticas, luego variables de objeto + enumeraciones si existen. Después de las variables, defino los constructores de clases. Luego escribo métodos para trabajar con la clase. Después de los métodos escribo captadores y definidores. Y al final tengo clases internas. Puedes usar mi estructura o escribir la tuya propia en los comentarios.

5. Niveles de abstracción de métodos.

Para mí este fue el descubrimiento número uno. Cada método contiene operadores en un solo nivel de abstracción. No debes mezclar operaciones de varios niveles.

6. Manejo de errores.

Excepciones marcadas o no marcadas, ¿cuál es mejor usar en el proyecto (¿qué opinas?, ¿escribe comentarios)? Soy partidario de las excepciones comprobadas, pero el libro ayuda a observar las excepciones no comprobadas desde fuera. De hecho, una excepción no marcada no desfigura la firma del método, especialmente considerando que las excepciones "perforan" varias capas a la vez. El inconveniente del cambio más pequeño conduce a la redefinición de toda la cadena de métodos antes de detectarlo, lo que en muchos casos resulta extremadamente inconveniente para el desarrollo.

7. Formato de código.

El código con el formato adecuado no sólo es claro, sino también muy legible. Inmediatamente te haces una idea de los corchetes y las acciones que hay dentro. Usando el ejemplo de las condiciones en las construcciones if, else, no debes escribir todo en una línea, es mejor mover cadenas largas.

8. Negaciones en la condición.

Intenta evitar la negación en condiciones, esto es más un factor psicológico, nuestro cerebro no percibe bien la negación, ¡y sí! antes de que la expresión no se note. Por ejemplo, negar si (!condition.isTrue) es mejor reescribir el método, lo hará mucho más fácil así (condition.isFalse)

9. Las funciones deben realizar una operación.

Si su método realiza muchas operaciones, divídalas en métodos de operación única. Estos métodos son muy fáciles de respaldar, fáciles de probar y, si es necesario, reemplazados o eliminados.

10. No te repitas.

No repita el código DRY (No se repita). Esta es una de las reglas fundamentales que reducirá significativamente tu código, tenla en cuenta. Intente poner todos los fragmentos de código repetidos en una función separada. Por supuesto, podemos hablar mucho más sobre DRY, KISS (Keep it simple Stupid), SOLID , YAGNI. Estos términos son esenciales para la comprensión y el diseño. Vale la pena escribir un artículo aparte, tal vez vuelva a escribir sobre ellos, ya que este artículo está dedicado a una reseña del libro "Código limpio". Como prometí, una tarea pequeña y sencilla para ti. El programa debe calcular el índice de obesidad en función de los datos proporcionados. Escriba en los comentarios la cantidad de errores y correcciones en el código. PD El código funciona y cumple su función si se usa correctamente.

//Weight in kg.
//Height in metres.
public class sample {
    public static void main (String[] args) {
        humanIMB humanIMB = new humanIMB(80,1.52);
        System.out.println(humanIMB.Result());
    }
}
class humanIMB {
    public double W; //Weight Human
    public double H; // Height Human
    private static double imb;
    public humanIMB(double w, double h) {
        W = w;
        H = h;
        imb = W / (H * H);
    }
    public double takeW() {
        return W;
    }
    public void putW(double w) {
        W = w;
        imb = W / (H * H);
    }
    public double takeH() {
        return H;
    }
    public void putH(double h) {
        H = h;
        imb = W / (H * H);
    }
    public static double takeImt() {
        return imb;
    }
    public static String Result() {
        String  string = null;
        if (imb >=18.5 & imb <25) {
            string ="Норма, ты в форме!";
        }
        if (imb >=25 & imb <30) {
            string ="Предожирение. Эй, поосторожнее с пирожными ";
        }
        if (imb >=30) {
            string ="Ожирение. SCHWEINE! Хватит жрать, иди на треню!";
        }
        if (imb <18.5) {
            string ="Дефицит массы тела. В модели решил переквалифицироваться?";
        }
        return string;
    }
}