Todo el mundo necesita un código limpio, pero no todos lo tienen que hacer de la misma forma, ni todos necesitan hacerlo de la misma manera. En el desarrollo de software hay que saber diferenciar el "qué" del "cómo". Un principio por encima de "clean code" es: la ingeniería es un compromiso. Siempre tienes que comprometerte con un punto y sacrificar otro. Pero siempre tienes que comprometerte con tus objetivos. El error de "clean code" no es el "qué" se quiere, sino en el "cómo" lograrlo, en parte al ignorar lo abstracto que es el concepto de "código limpio", la subjetividad del lector y la relatividad del contexto. Siempre el "cómo" debe subordinarse al "qué", en este caso, un código limpio estará sucio si interfiere con sus objetivos.
creo que estos posts que estan saliendo contra clean code son en resumen un "te han enseñado mal ingles, yo te dire como realmente se enseña en mi curso" 😂😂
Correcto, con la competencia que hay se tiene que llamar la atención, y hay esa tendencia en buscar algo muy asentado y poner un título espectacular: "Kubernetes no vale la pena", "no hay que testear!!", etc. En ningún momento del libro pone que sean leyes, sino recomendaciones de gente que ha programado mucho y se ha peleado con muchos tipos de proyecto.
Clean code se adecua al modelo de dominio. Hay que tener un criterio de decidir que arquitectura o tipo de código debemos hacer dependiendo del problema o contexto, clean code en un código de alto rendimiento o bajo nivel no tiene sentido,pero en una regla de negocio si lo veo bien
El problema que plantean en el minuto 10:27, es que están pensando solo en servicios de cara a la web, y el clean code, debería aplicarse a todo el código de una empresa. Como caso personal, donde trabajo, aprendí muchisimo de buenas practicas de desarrollo, porque el codigo que tenian era muy ordenado, pero de poco servía, ya que de cara al cliente una api se demoraba 2 segundos en responder.
Yo desarrollo software critico usando DO-178C y nuestro criterio de diseño es verificabilidad. Todo lo demás es secundario. Luego como dice el video, nuestro estandard de código tiene limites muy estrictos en cuanto a complejidad ciclomática, nested calls, single return por función, y un largo etc. Para mi clean code se reduce a un problema de acoplamiento y cohesión.
No paro de estar de acuerdo con todo lo que mencionan. Dicen todo lo que pienso del código limpio. Este canal es de los mejores en cuanto a Arquitectura y Código mantenible se refiere.
Conclusión busquen referencias sobre calidad de software, si tus funcionalidades tienen un ciclo de vida amplio es un buen sintoma de la calidad de tu producto, si las funcionalidades fallan rápidamente después de ser liberado es porque en terminos de calidad algo está fallando de manera critica, aplica conceptos, mira referencias, itera para mejorar, pero no te abrumes con el esta bien o esta mal, porque al sol de hoy eso enloquece, todos los dias dicen XY es el santo grial y esos mismos salen con otro video diciendo "te voy a explicar porque lo estas haciendo mal con XY"
Buen video. Creo que el problema de este libro es que acaba siendo el típico manual corporativo para escribir código en java… Pero si dejas de lado las explicaciones y ejemplos del tío Bob, en realidad los conceptos que da no son malos.
@@josepuente8486básicamente en muchos casos clickbait, y en otros llamar la atención. Al final, lo comentado en Clean Code no es perfecto, pero se dan muchas directivas válidas para mejorar la legibilidad, ampliabilidad (no se si existe esa palabra o me la he inventado 😂) y mantenimiento del código, que al final es lo que más importa cuando se está desarrollando.
Lo realmente importante sería preguntarse: ¿Qué ha hecho Robert C. Martin como ingeniero? ¿Qué software altamente demandado y que requiera soporte, robustes y desempeño ha creado/participado? (Hasta donde sé, vive de dar conferencias y vender su libro/cursos, esto no es algo malo pero puede estar muy alejado del campo de batalla). Todo el mundo tiene derecho a expresar sus ideas y plasmarlas en un libro, pero que algo esté en un libro no lo vuelve válido. Muchas cosas dependen del contexto. De la misma forma pasa con los patrones de diseño, todos ellos vienen de las limitaciones que tenía Java en los 90s. Es muy importante entender el contexto.
@@uni-tbasics3038 realmente los conceptos que explica en su libro son "copias" del trabajo de gente como Martin Fowler, Bertrand Meyer, etc. Al final, Clean Code es un compendio de buenas prácticas que estaban repartidas por distintos libros y charlas. Esa por ello que cuando se trabaja en un proyecto complejo y que requiere un mantenimiento de años muchas de esas prácticas ayudan. Por otro lado, muchos de los patrones de diseño se pueden aplicar a programación funcional y permiten evitar el reinventar la rueda. En mi experiencia el "estilo libre", que implica no seguir ninguna buena práctica y no utilizar en temas complejos ningún patrón, con el tiempo se va transformando en un lastre.
@@uni-tbasics3038 totalmente de acuerdo. Pero los principios, las restricciones de las que habla, siguen teniendo vigencia en gran parte y en la mayoría de ámbitos. Mucho de lo que escribe no son más que una recopilación de buenas prácticas de varios autores a lo largo de muchos años. Los videos que lo critican no argumentan ni la mitad de lo que has hecho tú.
Acabo de venir de ver a Midu criticando el clean code y alucinaba, tanto que voy a pasar de ver sus videos, me parecen patéticos, insulsos, sin base , sus opiniones son simples, sin argumentación .. venía un poco cabreado!! a ver, me gusta "code clear" pero que no lo aplico del todo.. es como programar.. uso el contexto y lo aplico cuando hace falta.. os doy mi voto.. vosotros SI SABEIS de que va el asunto!!!!
Me sorprende lo que mencionan sobre el Clean Code siendo ‘un juego de contraposiciones’. 🎲 ¿Realmente se ha vuelto más un arte de balancear reglas que una guía práctica?
Esto me parece el acabose, volvemos a reinventar la rueda, en un año habrá gente reclamando a la vuelta al monolito solo para sacar visitas y reacciones. Y en 2 volvemos a los JSP y EJB
Gracias chicos por protegernos del contenido ahí afuera. Mucha gente sube videos con mucho salseo y comentarios llamativos solo para generar controversia y mas visitas... Ustedes no, y eso se agradece ❤
Si mucho WTFs, pero son exposiciones de lo que quería explicar el autor con la tecnología que tenía en su momento, a mí me lloran los ojos cuando veo lógica y plantilla en el mismo archivo de un componente de react, o códigos de back con 5 ifs anidados. Así que no esté actualizado con "tecnologías actuales" los principios y recomendaciones son perfectamente válidos.
En el 2022 ya me tiraron por los suelos varias normas de este libro. Pero ha sabido vender muchos libros, eso hay que reconocerlo. Igual que las metodologías ágiles el 90 por ciento de veces se transforman en un circo
Muchos conceptos están muy acoplados al estilo Java, sobretodo el polimorfismo, cientos de clases solo para conseguir que una capa no vea a la otra, pero acabas teniendo código ofuscado, en programación funcional junto con un DDD simple no usando arquitectura hexagonal y feature slicing muchos conceptos no sirven por que quieres todo lo relativo a la feature dentro no desperdigado en cosas comunes, sinceramente es un libro un tanto obsoleto, muchas empresas tienen sus evangelistas por qué llevan toda la vida con Java pero lo simple que lo puedes hacer con otros lenguajes no tiene sentido complicar en capas y más capas que vas dando más saltos que Will Smith en Hancock.
Todo el mundo necesita un código limpio, pero no todos lo tienen que hacer de la misma forma, ni todos necesitan hacerlo de la misma manera. En el desarrollo de software hay que saber diferenciar el "qué" del "cómo". Un principio por encima de "clean code" es: la ingeniería es un compromiso. Siempre tienes que comprometerte con un punto y sacrificar otro. Pero siempre tienes que comprometerte con tus objetivos. El error de "clean code" no es el "qué" se quiere, sino en el "cómo" lograrlo, en parte al ignorar lo abstracto que es el concepto de "código limpio", la subjetividad del lector y la relatividad del contexto. Siempre el "cómo" debe subordinarse al "qué", en este caso, un código limpio estará sucio si interfiere con sus objetivos.
Muy bueno felicitaciones chicos 🙂
Like, comentario, set y partido para Codely!
creo que estos posts que estan saliendo contra clean code son en resumen un "te han enseñado mal ingles, yo te dire como realmente se enseña en mi curso" 😂😂
Correcto, con la competencia que hay se tiene que llamar la atención, y hay esa tendencia en buscar algo muy asentado y poner un título espectacular: "Kubernetes no vale la pena", "no hay que testear!!", etc. En ningún momento del libro pone que sean leyes, sino recomendaciones de gente que ha programado mucho y se ha peleado con muchos tipos de proyecto.
de midudev no hables xD
Peeo como midu?? Si midu ni curso vende xD @@Elba_Nanito
Clean code se adecua al modelo de dominio. Hay que tener un criterio de decidir que arquitectura o tipo de código debemos hacer dependiendo del problema o contexto, clean code en un código de alto rendimiento o bajo nivel no tiene sentido,pero en una regla de negocio si lo veo bien
El problema que plantean en el minuto 10:27, es que están pensando solo en servicios de cara a la web, y el clean code, debería aplicarse a todo el código de una empresa. Como caso personal, donde trabajo, aprendí muchisimo de buenas practicas de desarrollo, porque el codigo que tenian era muy ordenado, pero de poco servía, ya que de cara al cliente una api se demoraba 2 segundos en responder.
Yo desarrollo software critico usando DO-178C y nuestro criterio de diseño es verificabilidad. Todo lo demás es secundario. Luego como dice el video, nuestro estandard de código tiene limites muy estrictos en cuanto a complejidad ciclomática, nested calls, single return por función, y un largo etc. Para mi clean code se reduce a un problema de acoplamiento y cohesión.
Buenisimo el canal que tienen chicos. Saludo desde chile!🇨🇱
Hay momentos en los que iría y sus abrazaría 😂. Gran video.
Me ha gustado mucho a partir de la parte del analisis de primeagen!
Buenos conceptos fueron tirando en el medio, así da gusto.
No paro de estar de acuerdo con todo lo que mencionan. Dicen todo lo que pienso del código limpio. Este canal es de los mejores en cuanto a Arquitectura y Código mantenible se refiere.
Cracks!! ❤🔝🔝👏🏼
Gente como se aplica la arquitectura cuando quieres desarrollar un sistema de sesiones como el de whatsapp y whatsapp web?
Sería bacán que trajeran los mejores libros que recomiendan
Buen video!
Conclusión busquen referencias sobre calidad de software, si tus funcionalidades tienen un ciclo de vida amplio es un buen sintoma de la calidad de tu producto, si las funcionalidades fallan rápidamente después de ser liberado es porque en terminos de calidad algo está fallando de manera critica, aplica conceptos, mira referencias, itera para mejorar, pero no te abrumes con el esta bien o esta mal, porque al sol de hoy eso enloquece, todos los dias dicen XY es el santo grial y esos mismos salen con otro video diciendo "te voy a explicar porque lo estas haciendo mal con XY"
Buen video. Creo que el problema de este libro es que acaba siendo el típico manual corporativo para escribir código en java… Pero si dejas de lado las explicaciones y ejemplos del tío Bob, en realidad los conceptos que da no son malos.
muy bueno, no sumandose a la moda de hacerse los cool con lo de que Clean Code no va mas
Sí! No entiendo por qué esa moda!?
@@josepuente8486básicamente en muchos casos clickbait, y en otros llamar la atención. Al final, lo comentado en Clean Code no es perfecto, pero se dan muchas directivas válidas para mejorar la legibilidad, ampliabilidad (no se si existe esa palabra o me la he inventado 😂) y mantenimiento del código, que al final es lo que más importa cuando se está desarrollando.
Lo realmente importante sería preguntarse: ¿Qué ha hecho Robert C. Martin como ingeniero? ¿Qué software altamente demandado y que requiera soporte, robustes y desempeño ha creado/participado? (Hasta donde sé, vive de dar conferencias y vender su libro/cursos, esto no es algo malo pero puede estar muy alejado del campo de batalla).
Todo el mundo tiene derecho a expresar sus ideas y plasmarlas en un libro, pero que algo esté en un libro no lo vuelve válido. Muchas cosas dependen del contexto. De la misma forma pasa con los patrones de diseño, todos ellos vienen de las limitaciones que tenía Java en los 90s. Es muy importante entender el contexto.
@@uni-tbasics3038 realmente los conceptos que explica en su libro son "copias" del trabajo de gente como Martin Fowler, Bertrand Meyer, etc. Al final, Clean Code es un compendio de buenas prácticas que estaban repartidas por distintos libros y charlas. Esa por ello que cuando se trabaja en un proyecto complejo y que requiere un mantenimiento de años muchas de esas prácticas ayudan.
Por otro lado, muchos de los patrones de diseño se pueden aplicar a programación funcional y permiten evitar el reinventar la rueda.
En mi experiencia el "estilo libre", que implica no seguir ninguna buena práctica y no utilizar en temas complejos ningún patrón, con el tiempo se va transformando en un lastre.
@@uni-tbasics3038 totalmente de acuerdo. Pero los principios, las restricciones de las que habla, siguen teniendo vigencia en gran parte y en la mayoría de ámbitos. Mucho de lo que escribe no son más que una recopilación de buenas prácticas de varios autores a lo largo de muchos años. Los videos que lo critican no argumentan ni la mitad de lo que has hecho tú.
Acabo de venir de ver a Midu criticando el clean code y alucinaba, tanto que voy a pasar de ver sus videos, me parecen patéticos, insulsos, sin base , sus opiniones son simples, sin argumentación .. venía un poco cabreado!! a ver, me gusta "code clear" pero que no lo aplico del todo.. es como programar.. uso el contexto y lo aplico cuando hace falta.. os doy mi voto.. vosotros SI SABEIS de que va el asunto!!!!
Me sorprende lo que mencionan sobre el Clean Code siendo ‘un juego de contraposiciones’. 🎲 ¿Realmente se ha vuelto más un arte de balancear reglas que una guía práctica?
Bueno por poner un caso ideal para el Buggy Code ¿que tal usarlo en los algoritmos de depp learning?
excelente
Que vuelva el espagueti! 💣💥
Esto me parece el acabose, volvemos a reinventar la rueda, en un año habrá gente reclamando a la vuelta al monolito solo para sacar visitas y reacciones. Y en 2 volvemos a los JSP y EJB
Gracias chicos por protegernos del contenido ahí afuera. Mucha gente sube videos con mucho salseo y comentarios llamativos solo para generar controversia y mas visitas... Ustedes no, y eso se agradece ❤
Falta uno que hable de clean arquitecture
Los ejemplos de codigo de Clean Code me producen muchos WTFs.
Si mucho WTFs, pero son exposiciones de lo que quería explicar el autor con la tecnología que tenía en su momento, a mí me lloran los ojos cuando veo lógica y plantilla en el mismo archivo de un componente de react, o códigos de back con 5 ifs anidados. Así que no esté actualizado con "tecnologías actuales" los principios y recomendaciones son perfectamente válidos.
Ajustarse al 100% al Clean Code es el negro. Oponerse al 100% es blanco. Como todo en la vida, hay una infinita escala de grises. Ni más ni menos.
con lo cual...
En el 2022 ya me tiraron por los suelos varias normas de este libro. Pero ha sabido vender muchos libros, eso hay que reconocerlo. Igual que las metodologías ágiles el 90 por ciento de veces se transforman en un circo
Clarita las explicaciones
0:34 Jajaja 😂
vaya parece que va dirigido al Midudev
Lo que estáis contando viene a ser el claro ejemplo del antipatrón Martillo de Oro, en los 4 ejemplos.
el men del bigote no es el javier santa olaya jajajja
Tiene sentido pero sólo en lo básico, es decir, no repetir código y nombrar correctamente variables, métodos y clases. El resto es inútil.
el clean code esta mas enfocado al backend...
el clean code es mas heavy en C# y C++ .
Muchos conceptos están muy acoplados al estilo Java, sobretodo el polimorfismo, cientos de clases solo para conseguir que una capa no vea a la otra, pero acabas teniendo código ofuscado, en programación funcional junto con un DDD simple no usando arquitectura hexagonal y feature slicing muchos conceptos no sirven por que quieres todo lo relativo a la feature dentro no desperdigado en cosas comunes, sinceramente es un libro un tanto obsoleto, muchas empresas tienen sus evangelistas por qué llevan toda la vida con Java pero lo simple que lo puedes hacer con otros lenguajes no tiene sentido complicar en capas y más capas que vas dando más saltos que Will Smith en Hancock.
Leche! No usar clean code vamos apañaos
En mi trabajo no les gusta CLEAN porque los code reviewers son jrs y no le entienden jajaja
Cuando dijeron lo del curso me di cuenta que no estaba viendo de Platzi. 😅😅
no seais amarillistas
Es justo lo que intentamos con este vídeo. En qué te ha parecido que lo seamos?