A Philosophy of Software Design: el Clean Code modern?

Hay libros que te enseñan a escribir código y hay libros que te enseñan a pensar mejor. Y si tuviera que escoger solamente un libro de esta segunda categoría, escogería a filosofi of software design, de John Osterhoud. El libro que yo considero el sucesor spiritual de clean code. Bienvenido la serie del club de lectura con Betatek, una serie en la que analizamos libras técnicos y resumimos sus ideas principales. Y en este vídeo, te voy a hablar de complejidad y modularización. En resumen, de cómo hacer un mejor diseño de software. Y es que este libro es muy bueno explicando alto nivel que es todo esto de la complejidad, ¿qué hace que un software sea complejo y difícil de mantener con diferentes ejemplos y diferentes maneras de detectar? cuando estás haciendo algo incorrecto. En el oco conductor de todo el libro

es que es el objetivo que tenemos nosotros como desarrolladores, es hacer software poco complejo, es decir, reducir la dificultad para entender un código. de hecho, en el libro se define la complejidad de la siguiente manera. La complejidad es lo que un desarrollador experimenta cuando en un punto del tiempo está intentando conseguir un objetivo. Lo que intenta yo es distinguir la complejidad tal como la entendemos como un mente, que sería pues tener un sistema grande, con un montón de ficheros, con un montón de funcionalidades, cuando en realidad un proyecto muy grande puede no tener complejidad siempre y cuando sea fácil trabajar en él. Es por ello que yo ofrece una definición alternativa a modo de fórmula matemática. La complejidad de un sistema C se determina por la complejidad de cada parte, pondérada por la fracción del tiempo que los

desarrolladores gastan trabajando en esa parte. Básicamente si sumamos todas estas complejidades tenemos la complejidad total del sistema. La C es decir, si nosotros eliminamos el tiempo que un desarrollador está trabajando en estas partes que tienen complejidad virtualmente es como si estuvieramos eliminando la complejidad del sistema. Es por esto que la idea de este libro es tan interesante. En resumen, plantear un dicino de software que haga que no tengas que trabajar ni tocar la complejidad hace que, virtualmente, sea mucho menos complejo trabajar en ese proyecto. Aunque por debajo tengo un montón de algoritmos superdaros, tengo un montón de funcionalidades super extrañas, pero si están muy bien aisladas y no tienes que tocarlas, a la práctica no existen. Y para conseguir esto, en este libro se hace muchísimo enfasis en los dos tipos de pensamiento que tenemos la gente que

trabaja en desarrollo de software, que es el trabajar de manera estratégica o el trabajar de manera táctica. Y de hecho, yo he dicho textualmente que este es uno de los elementos más importantes para el diseño de buen software, la mentalidad. La mentalidad táctica sería esa mentalidad en la que tú desarrollas software simplemente para que funcionen. Hoy en día eso es super común y más con el auge de la inteligencia artificial en el que a la que funciona, ya no te preocupas de nada más. El problema que describe Jones sobre esta metodología, sobre esta mentalidad de trabajo, es que es muy corto plazista. Es decir, estas intentando apagar los juegos que tienen entendidos en cada momento, pero no estás planteando un sistema que realmente soporte a los ingenios. O incluso que no se pueda incendiar. Según este libro, esta

es la causa de que los sistemas cada vez se vaya volviendo más complejos y más difíciles de manera. que no pensamos de una manera estratégica. El primer paso para pensar de manera estratégica es asumir que el código funciona no es suficiente. Hay que tener en cuenta también la estructura a largo plazo del proyecto. El libro dice de exoalmente, no deberías pensar en código funcional como tu principal objetivo. Tu principal objetivo debería ser producir un buen diseño que casualmente funciona. Eso sí, también tiene unos capítulos dedicados a... ¿Cuánto tenemos que invertir a pensar de manera estratégica? Teniendo en cuenta, pues, dificultades de entrega, gestes que nos están presionando o pues el tiempo que podemos tardar en tener algo para el mercado. Pero, argumentos sigue siendo el mismo. ¿Cuánto más programemos de manera estratégica más podremos mantener la velocidad de

desarrollo a la ropa? En resumen, el libro no míega que si desarrollas de manera táctica, al principio va a seguir más rápido, porque no le digas tanto tiempo a plantear como tiene que lucir la estrategia futuro. Ahora bien, si desarrollas de manera estratégica preocupándote del diseño de software, a la larga vas a acabar siendo capaz de mantener un progreso mucho más rápido, porque no tendrás tanta complejidad, porque no tendrás tanta deuda técnica y por lo tanto podrás seguir entregando de una manera escalable. Ahora bien, hemos hablado de la complejidad y de la importancia de tener un buen diseño, pero como detecta realmente que estás haciendo un buen diseño o no? Pues en este libro también se algunas técnicas para que puedas detectar si estás haciendo malas asacciones o si tienes que invertir más tiempo en el pensamiento estratégico.

De lo mostra. Una de las señales que te indica que estás añadiendo complejidad a tu software es lo que en el libro se denomina amplificación del cap. ¿Cuántas veces has tenido que hacer una implementación pequeña de algo? Lo que sea, en un sistema de vaco, en un sistema de fronten, ya se ha quedado teniendo que tocar. un montón de ficheros repartidos por un montón de carpetas. Esto lo que indica es que tu cambio se tiene que amplificar. Tienes que tocar un montón de piezas diferentes para poder aplicar esa nueva característica del producto o para regular ese book. Normalmente cuando ocurre algo así es sintoma de una de estas tres cosas. Obien tienes lógica duplicada que se podría refactorizar. Obien tienes dependencias que no están muy bien planteadas. Obien tienes información que se está filtra en los que están

en los que

están En el libro será preferencia a los modulos profundos con interpaces sencillas. Es decir, si yo tengo mucha complejidad o culta dentro de lo que sea una clase, la interfaz que luego se va a utilizar desde fuera de la clase para interactuar con esta complejidad tiene que ser sencillas. Lo que hemos dicho antes tenemos que ocultar la complejidad y no tener que dedicar tiempo

a tocarla. Yo no os terjo a otras bastante insistentenes, el problema no es que una clase sea muy grande o sea muy pequeña. El problema es que tanta de la realidad está ocultando esa clase. Puedes tener una clase de miles de líneas que si es los miles de líneas, porque yo que sé es un algoritmo largísimo. oculta en la complejidad y simplifican la complejidad del sistema total porque te dan simplemente una pequeña función que tú puedes utilizar super simple eso ya sirve eso ya está eliminando y disminuyendo la dificultad de mantenimiento del código por eso a veces digo que este libro es el suceso espiritual de Kingcout precisamente porque esta explicación se parece un poquito a la explicación de la segregación de interfaces de los principios solitos Ahora bien, explicado de una forma mucho más aplicable, mucho más

realista al desarrollo de su afuérmode. Entonces, de todo lo que estamos hablando, mientras vamos a ir en este libro, es de un concepto clave, el de ocultar información. Básicamente, explicado al ton nivel, decidir qué se muestra y qué no se muestra, es una de las decisiones clave que tenemos que hacer nosotros como desarrolladores cuando estamos diseñando su afuérmode. De hecho, el libro dice que es una de las decicciones que más impacto tiene sobre la mantenibilidad del código. Esplico porque, básicamente, ocultar información significa que los detalles importantes de la implementación de algo no se filtren. fuera del módulo. El objetivo de esto es que si yo tengo que modificar una decisión, por ejemplo, tengo que cambiar de implementación de una base de datos, tengo que cambiar cómo se hace una cuera y tengo que cambiar el protocolo que yo

utilizo, pues cuando yo quedo hacer un cambio de este estilo, solamente tenga que hacerlo en un solo sitio. De te cuenta que esto se parece mucho cuando estamos hablando de los principios solitos, pero explicado de una manera mucho más adaptada al contexto actual. Y te veía comentar ahora un ejemplo de algo que yo me encontré que violaba directamente lo que se decía en este libro en un proyecto en el que trabajé hace unos años. Se trataba de un proyecto super sencillo era una ápico en Express, una ápica ATP con sus rutas, con sus peticiones, básicamente podíamos entenderlo como una especie de crud medio res. Lo que pasa es que teníamos toda la parte de Express. plantada y luego cuando nos íbamos a funcionar y ya de dominio es decir, funcionalidades dentro de nuestra propia aplicación. ¿Qué no tendrían

por qué saber si se están ejecutando por RHDTP o si se están ejecutando con cualquier otra cosa? Pues en esta capa, que en teoría tenía que hacer abstracta, también le lanzábamos, le pasamos por parámetro, pues la recuest. de Express. Es decir, nuestras funciones de dominio tenían que conocer que se estaba utilizando htp, porque tenían que entrar a la ricoest, tenían que mirar los headers y en función de esa ciencia una sección es vuotras. Claramente, no estaba bien desacoplado, no había una buena modulación. Si yo quería cambiar Express, por otro tipo de transporte, por ejemplo, para utilizar mi proyecto como una celeí. o lanzar ciertas funciones mediante eventos, pues no lo podía hacer de una manera sencilla. Estaba todo super acoplado, es decir, no había una ocultación de información. Y esto también añadía un nuevo concepto que también se

define en este libro a los desarrolladores, que es el concepto de carga cognitiva. Para tu poder trabajar de forma esficiente, para poder hacer un cambio, no vas a estar con entender el cambio que querías hacer a nivel de dominio. Tenía también que entender cómo estaba implementado. Si todo te llegaba de un gd, todo te llegaba a medio que sea un parámetro en el body de la petición en definitiva. Tenías que tener un montón de información en tu cabeza para poder hacer una tarea. Tenías mucha carga cognitiva. Imagínate un proyecto en el que simplemente para implementar una nueva característica, mira lo que quieres hacer, mira es que vento tener que mandar, hace una función que consume ser en todo lo proceso y devuelve un resultado. Simple ocuparte, ni de dónde viene, ni dónde va, ni dónde se guarda. Imagínate

un proyecto, en el que puedes desarrollar sin tener que conocer cómo funciona todo el ende. Para conseguir un proyecto así te recomendaría que le echara un ojo a este libro. Y si te ha gustado este vídeo y quieres ver más estrategias ya atocando código real sobre cómo se pueden implementar ciertos patrones que te podrían ayudar a ocultar esta complejidad de dejo por aquí un vídeo en el que habló de patrones de diseño. Se está trabajando en programación en el entador J2 este vídeo te parece la super interesante. Espero que les si vio te haya gustado si es si les si por favor suscríbete y déjame un buen like, dale también al botón de hype y nos vemos en la siguiente con más informática. Hasta otra!