solid

Recursos de programación de solid
Analizamos 5 ejemplos de código donde la gente de LeanMind nos ayuda a identificar lo que han denominado como reglas de Código Sostenible. Al fin y al cabo, conceptos que orbitan alrededor de Clean Code y que nos ayudan a conseguir un código fácil de mantener 😊 Veremos código y hablaremos de cómo aplicar este tipo de buenas prácticas para seguir mejorando y desarrollemos aplicaciones y webs que sean fáciles de entender y modificar 🤟 ﹤🎙️﹥ Invitados ├ María Soria (desarrolladora en LeanMind): https://twitter.com/marietait3 ├ Adrián Ferrera (desarrollador en LeanMind): https://twitter.com/adrianferrera91 ├ Carlos Blé (director de LeanMind): https://twitter.com/carlosble ├ LeanMind: https://twitter.com/leanfulness_es └ Libro Código Sostenible (descuento: "CODELY10"): https://savvily.company.site ﹤🔖﹥ Cursos relacionados ├ 🧱 Principios SOLID aplicados: https://pro.codely.com/library/principios-solid-aplicados-36875/about ├ 🧼 Refactoring de Code Smells a Clean Code: Bloaters: https://pro.codely.com/library/refactoring-de-code-smells-a-clean-code-bloaters-62290/about ├ 🧹 Refactoring de Code Smells a Clean Code: Change Preventers: https://pro.codely.com/library/refactoring-de-code-smells-a-clean-code-change-preventers-70287/210883/about/ ├ 🏭 Patrones de Diseño: Creacionales: https://pro.codely.com/library/patrones-de-diseno-creacionales-167860/359848/about/ └ ♻️ TDD: Test-Driven Development: https://pro.codely.com/library/tdd-test-driven-development-179143/402180/about/ ﹤🍍﹥ CodelyTV ├ 🎥 Suscríbete: https://youtube.com/c/CodelyTV?sub_confirmation=1 ├ 🐦 Twitter CodelyTV: https://twitter.com/CodelyTV ├ 🧔🏻 Twitter Javi: https://twitter.com/JavierCane ├ 📸 Instagram: https://instagram.com/CodelyTV ├ ℹ️ LinkedIn: https://linkedin.com/company/codelytv ├ 🟦 Facebook: https://facebook.com/CodelyTV └ 📕 Catálogo cursos: https://bit.ly/cursos-codely #CleanCode #CódigoSostenible #CódigoLimpio
Analizamos el repositorio con el que puedes arrancar un proyecto de 0 en #TypeScript listo para aplicar todos los patrones de #DomainDrivenDesign. Cuidaremos desde la estructura de directorios para que el planteamiento escale a medida que añadimos Bounded Contexts y módulos, hasta las distintas herramientas de testing que usaremos para cada tipología de test, pasando por pequeñas joyas como Helmet 😊 Fer Vilas es desarrollador en Audiense, gente TOP que trabajan con volúmenes de datos brutales aplicando proyecciones de datos para los distintos bounded contexts, eventos de dominio, y demás patrones de DDD 🔷 Este video es parte del Curso de DDD en TypeScript 👉 https://bit.ly/ddd-curso 🐙 Esperamos que con la utilidad que presentamos, el template repository de DDD en TypeScript puedas levantar tu nueva app en menos de 5 minutos: 1️⃣ https://github.com/CodelyTV/typescript-ddd-skeleton 2️⃣ https://github.com/CodelyTV/typescript-ddd-example Otros cursos relacionados: 👉 De JavaScript a TypeScript bit.ly/js-curso 👉 Curso de Refactoring: Change Preventers https://pro.codely.tv/library/refactoring-de-code-smells-a-clean-code-change-preventers-70287/210878/about/ 👉 Curso de SOLID https://pro.codely.tv/library/principios-solid-aplicados-36875/77070/about/ {▶️} CodelyTV ├ 🎥 Suscríbete: https://youtube.com/c/CodelyTV?sub_confirmation=1 ├ 💡 Twitter Fer: https://twitter.com/fer_vilas ├ 🐦 Twitter CodelyTV: https://twitter.com/CodelyTV ├ 🧔🏻 Twitter Javi: https://twitter.com/JavierCane ├ 📸 Instagram: https://instagram.com/CodelyTV ├ ℹ️ LinkedIn: https://linkedin.com/company/codelytv ├ 🟦 Facebook: https://facebook.com/CodelyTV └ 📕 Catálogo cursos: https://bit.ly/cursos-codely
Tras haber aplicado Golden Master, ya con nuestro código cubierto con tests de caracterización, en este video refactorizamos e introducimos una nueva funcionalidad con TDD. Usamos una estrategia en la que aislamos el código a modificar con técnicas de refactoring como Extract variable, Extract Method y Extract class. La hemos denominado estrategia Hit&Run, ya que nos olvidamos de refactorizar todo el código que hay alrededor. ♻️ Este video es parte del Curso de TDD 👉 https://bit.ly/ctv-tdd Otros cursos relacionados: 👉 Curso de Refactoring: Bloaters https://pro.codely.tv/library/refactoring-de-code-smells-a-clean-code-bloaters-62290/176553/about/ 👉 Curso de Refactoring: Change Preventers https://pro.codely.tv/library/refactoring-de-code-smells-a-clean-code-change-preventers-70287/210878/about/ 👉 Curso de SOLID https://pro.codely.tv/library/principios-solid-aplicados-36875/77070/about/ 👉 Curso de IntelliJ https://pro.codely.tv/library/exprimiendo-intellij-idea-49135/104101/about/ {▶️} CodelyTV ├ 🎥 Suscríbete: https://youtube.com/c/CodelyTV?sub_confirmation=1 ├ 🐦 Twitter CodelyTV: https://twitter.com/CodelyTV ├ 🧔🏻 Twitter Javi: https://twitter.com/JavierCane ├ 👨🏻‍🌾 Twitter Dani: https://twitter.com/dsantaka ├ 📸 Instagram: https://instagram.com/CodelyTV ├ ℹ️ LinkedIn: https://linkedin.com/company/codelytv ├ 🟦 Facebook: https://facebook.com/CodelyTV └ 📕 Catálogo cursos: https://bit.ly/cursos-codely
Este panel de discusión es sobre Java. Ponentes: Nacho Cougil - Senior Software Engineer | Java Champion - Dynatrace Anyul Rivas - Senior Software Engineer - Roche Alejandro Moleiro - Platform Engineering Manager - Adevinta Christian Ciceri - Software Architect - Apiumhub Cristina Verdi - Founder - Code Sherpas Temas cuebiertas: - Solid principles - Java Architecture - Docker - DDD - TDD - Legacy Code - Refactoring El público también ha participado, haciendo preguntas, discutiendo cosas.
En este vídeo te comparto 100 (sí, CIEN!) trucos para ayudarte a programar mejor. 👨‍💻 ¡Apúntate al Black Friday de Codely! 👉 https://bit.ly/codely-bf Los trucos que vemos: 1. Nivel de identación 2. Evita else 3. Encapsula los primitivos 4. Encapsula las colecciones 5. Sigue la ley de Demeter 6. No abrevies 7. Mantén tus entidades pequeñas 8. No clases con más de 2 dependencias en los constructores 9. No hagas getters/setters. Tell don't ask 10. Utiliza Object Calisthenics 11. Utiliza un Linter 12. Utiliza las GitHub actions para CI y CD 13. Usa un analizador estático del código 14. Sigue la regla de 3 repeticiones para evitar abstracciones prematuras 15. Ten un fichero "EditorConfig" 16. Llas I de las interfaces 17. La I de SOLID no significa inyección de dependencias 18. Versiona tus configs con dotly.sh 19. Cuando crees un recurso utiliza PUT 20. Busca la simplicidad en tu SO e IDE 21. Prueba en tu local la `beta`, pero en producción la `.1` 22. Si haces una web con light/dark theme haz que el tema se cambie según las preferencias 23. Utiliza light theme si estás en un ambiente con mucha luz 24. Y que puedas sobreescribirlo y sea configurable 25. Utiliza herramientas como ray.so o carbon.now.sh 26. Gestión de snippets 27. Hay tipografías que tienen un italic: Victor Mono, dank.sh 28. Si tienes dislexia utiliza comic mono 29. Si eres daltónica utiliza ese modo en todo lo que utilices 30. Aprovecha el Black Friday para formarte 31. No refactorices y cambies el comportamiento a la vez 32. No hagas una Pull Request que mezcle ambos 33. No hagas refactors si no tienes tests 34. Utiliza parallel change 35. cmd+shift+t para recuperar la última pestaña cerrada 36. Aprende un lenguaje muy diferente 37. Llega un punto donde el lenguaje es un detalle de implementación 38. Una de las cosas más complicadas de programar es ponerle nombre a las cosas 39. Y otra es saber dónde ponerlas 40. No utilices el argumento *porque lo dice menganita*, da argumentos reales 41. Es imposible hacer un código libre de errores/bugs 42. También es imposible modelar 100% tu dominio 43. El DDD tiene una parte táctica y otra estratégica 44. Los devs nos solemos centrar en la táctica 45. Ambas partes se unen en el lenguaje ubicuo 46. El UML no es el mal. Ta bien. Tampoco mucho. Pero ta bien 47. Bebe café 48. Pulsa control+k en github 49. Pusla control+shift+k 50. Pulsa t en GitHub 51. Pulsa . en GitHub 52. Sigue a ladybenko, moure, midu y manz 53. Ves a conferencias presenciales 54. No intentes empezar un proyecto con 100 microservicios desde 0 55. Depende 56. eXtreme programming 57. Cuando aprendemos está bien empezar a construir la casa por el tejado 58. Prepara algo para enseñar a los demás, es la mejor manera de aprender sobre un tema 59. Lee sitios como hackernews o mira el café con Codely 60. Organiza tu código por módulos y no por conceptos 61. Pon el tipo de retorno a todas tus funciones públicas 62. Modela tus errores con Either en lugar de lanzar excepciones 63. Gestiona los nulls utilizando un Maybe 64. Qué es una Mónada 65. Javascript no se va a comer el mundo 66. Aprende typescript 67. Haz descansos 68. Haz deporte 69. YAGNI, GRASP, Object Calisthenics 70. No te asustes por las siglas 71. CQRS no te obliga a tener un query y command bus 72. Pon límites o aviso de ellos en aws, gcp o lo que uses para no arruinarte 73. Hacer que un panel de grafana/kibana/datadog sea bonito hace que la gente lo use más 74. No hace falta que te aprendas al 100% los lenguajes de prometheus/influx 75. Ten una buena observabilidad de tu sistema 76. Con opentracing puedes saber todo lo que pasa en tu sistema 77. Usa `exa` en lugar de `ls` 78. Usa `bat` en lugar de `cat` 79. Usa `autojump` o `z` para navegar 80. Comando `tldr` 81. Alias para abrir el directorio actual en tu IDE 82. Encripta tu disco duro 83. Consistencia eventual 84. Evita utilizar joins 85. Explain 86. Intenta que main sea siempre estable por si algún día has de hacer un git bisect 87. Diferencia infraestructura de dominio 88. Busca ir un pasito más allá al hacer tutoriales de quick start 89. n8n no code 90. Star a repositorios de GitHub interesantes y follow al equipo Codely para ver sus stars 91. No uses lo nuevo 92. Considera usar un navegador que no sea Chrome 93. No uses valores arbitrarios en z-index 94. Hazte listas en Twitter 95. Usa Conventional Commit 96. Si no te acuerdas de un shortcut en VSCode presiona ctrl+shift+p 97. TIPs en X minutos ponlos a 2x y los verás en la mitad de tiempo 98. Descubre que puedes hacer con las developers tools de tu navegador 99. A programar se aprende programando 100. Like al vídeo y suscríbete {▶️} CodelyTV ├ 🎥 Suscríbete: https://youtube.com/c/CodelyTV?sub_confirmation=1 ├ 🐦 Twitter CodelyTV: https://twitter.com/CodelyTV ├ 💂‍♂️ Twitter Rafa: https://twitter.com/rafaoe ├ 📸 Instagram: https://instagram.com/CodelyTV ├ ℹ️ LinkedIn: https://linkedin.com/company/codelytv └ 📕 Catálogo cursos: https://bit.ly/cursos-codely
Con este principio se pretende minimizar el efecto cascada que puede suceder cuando cambiamos el comportamiento de una clase. Si existen clientes que dependan de ella, es posible que tengan que cambiar su comportamiento también. #KnowledgePills​​​ #Develop​ #SoftwareDesign #OpenClosed-Principle #Solid Descarga nuestras píldoras de conocimiento en formato ficha 👉 https://lk.autentia.com/2HeLWT8 ​​​ Síguenos en nuestras redes para estar al día de las novedades: - Twitter: https://goo.gl/MU5pUQ ​​​ - Instagram: https://lk.autentia.com/instagram ​​​ - LinkedIn: https://goo.gl/2On7Fj/ ​​​ - Facebook: https://goo.gl/o8HrWX ​​
La S de los principios SOLID es el principio más conocido, pero uno de los más complicados de entender. ¡Hoy os contamos cómo sacarle todo el jugo! 🚥 ¡Haz nuestro curso de refactoring! 👉 http://bit.ly/curso-refactor 🔗 Enlaces mencionados ├ Vídeo de la S de SOLID de Codely del 2015 https://www.youtube.com/watch?v=c97P1UmF1cs ├ Post Uncle Bob sobre SRP https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html ├ Paper de Uncle Bob sobre SRP https://www.cs.utexas.edu/users/downing/papers/SRP-1996.pdf ) └ Paper de Dijkstra sobre Separation of Concerns https://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF {▸} Codely ├ 🎥 Suscríbete: https://youtube.com/c/CodelyTV?sub_confirmation=1 ├ 🐦 Twitter Codely: https://twitter.com/CodelyTV ├ 💂🏼 Twitter Rafa: https://twitter.com/rafaoe ├ 🧔🏻 Twitter Javi: https://twitter.com/JavierCane ├ 📸 Instagram: https://instagram.com/CodelyTV ├ ℹ️ LinkedIn: https://linkedin.com/company/codelytv ├ 🟦 Facebook: https://facebook.com/CodelyTV └ 📕 Catálogo cursos: https://bit.ly/cursos-codely
Refactoring, Code Smells, SOLID, Clean Code, Clean Architecture… Todo está muy relacionado y hoy vamos a ver una estructura con Smells para refactorizarla y lograr un código más mantenible y escalable. ✌️ Sin duda, la Arquitectura del Software es uno de los temas de los que más nos gusta hablar. 😊 🚥 ¡Haz nuestro curso de refactoring! 👉 http://bit.ly/curso-refactor Para ello vamos a ver un Code Smell del tipo Change Preventer y cómo aplicar Split Phase Refactoring paso a paso. El refactoring (o refactorización) es la forma para reestructurar nuestro código, modificando su estructura interna sin modificar su comportamiento. Para ello siempre necesitamos una buena base de testing. {▸} Codely ├ 🎥 Suscríbete: https://youtube.com/c/CodelyTV?sub_confirmation=1 ├ 🐦 Twitter Codely: https://twitter.com/CodelyTV ├ 💂🏼 Twitter Rafa: https://twitter.com/rafaoe ├ 🧔🏻 Twitter Javi: https://twitter.com/JavierCane ├ 📸 Instagram: https://instagram.com/CodelyTV ├ ℹ️ LinkedIn: https://linkedin.com/company/codelytv ├ 🟦 Facebook: https://facebook.com/CodelyTV └ 📕 Catálogo cursos: https://bit.ly/cursos-codely
Seguimos con la saga de buenas prácticas y con otro de los principios S.O.L.I.D. basados en las enseñanzas del tío BOB (Robert C. Martin - Clean Code). Si en capítulos anteriores de esta saga veíamos el principio de responsabilidad única, hoy nos vamos a centrar en la letra O. La O hace referencia a Open/Closed principle (principio Abierto/Cerrado) y nos viene a referir que un objeto o entidad dentro de nuestro código debe estar abierto a la extensión pero cerrado a la modificación. Este conc...
Siguiendo con nuestro manual de buenas prácticas, hoy nos adentramos dentro de uno de los estándares más conocidos en el mundo de la programación. En este caso, los principios S.O.L.I.D, están fuertemente ligados a la programación orientada a objetos y establecen cinco reglas que ayudarán a que nuestro código sea más legible y más mantenible. Sólo como pequeña introducción, decir que S.O.L.I.D. significa "sólido" en inglés, pero aunque esta palabra dice ya mucho por si sola, se trata de una re...