Summary
Como escribe JacquesB, no todos están de acuerdo con el "Código Limpio" de Robert C. Martin.
Los proyectos de código abierto que encontró que estaban "violando" los principios que esperaba probablemente tengan otros principios.
Mi perspectiva
Resulta que superviso varias bases de código que se adhieren mucho a los principios de Robert C. Martin. Sin embargo, realmente no afirmo que estén bien , solo puedo decir que funcionan bien para nosotros , y que "nosotros" es de hecho una combinación de al menos
- el alcance y la arquitectura de nuestros productos,
- las expectativas del mercado objetivo / cliente,
- cuánto tiempo se mantienen los productos,
- la metodología de desarrollo que utilizamos,
- la estructura organizativa de nuestra empresa y
- hábitos, opiniones y experiencias pasadas de nuestros desarrolladores.
Básicamente, esto se reduce a: cada equipo (ya sea una empresa, un departamento o un proyecto de código abierto) es único. Tendrán diferentes prioridades y diferentes puntos de vista y, por supuesto, harán concesiones diferentes. Estas concesiones, y el estilo de código que resultan, son en gran medida una cuestión de gustos y no pueden demostrarse como "incorrectas" o "correctas". Los equipos solo pueden decir "hacemos esto porque funciona para nosotros" o "deberíamos cambiar esto porque no funciona para nosotros".
Dicho esto, creo que para poder mantener con éxito grandes bases de código a lo largo de los años, cada equipo debe acordar un conjunto de convenciones de código que consideren adecuadas para los aspectos mencionados anteriormente. Eso puede significar adoptar prácticas de Robert C. Martin, de otro autor, o inventar las propias; puede significar escribirlos formalmente o documentarlos "por ejemplo". Pero deberían existir.
Ejemplo
Considere la práctica de "dividir el código de un método largo en varios métodos privados".
Robert C. Martin dice que este estilo permite limitar los contenidos de cada método a un nivel de abstracción; como ejemplo simplificado, un método público probablemente solo consistirá en llamadas a métodos privados como verifyInput(...)
, loadDataFromHardDisk(...)
, transformDataToJson(...)
y finalmente sendJsonToClient(...)
, y estos métodos tendrían los detalles de la implementación.
- A algunas personas les gusta esto porque los lectores pueden obtener una visión general rápida de los pasos de alto nivel y pueden elegir sobre qué detalles desean leer.
- A algunas personas no les gusta porque cuando quieres conocer todos los detalles, tienes que saltar en la clase para seguir el flujo de ejecución (esto es a lo que JacquesB probablemente se refiere cuando escribe acerca de agregar complejidad).
La lección es: todos tienen razón, porque tienen derecho a opinar.