Mario Antonio Chow Plata
Miguel Teheran
ProfesorJhoan Sebastián Lopera Gallego
Adrian Peralta
Carlos Isael Ramírez González
Cristian Gonzalez Alvarez
Alfonso Navarro
Company_adminAnggi Vanesa Pallares Solis
David Torres M
Miguel Teheran
ProfesorDavid Elias Gatica Morales
Miguel Andres Rendon Reyes
wilking trinidad
Adrian Peralta
Juan Pablo Ruiz
Alfredo Nazareth Salazar Rodriguez
rodrigo tarrillo
Alfredo Nazareth Salazar Rodriguez
Leandro Cosme Tomassini
Mathías Cabrera
Alfonso Navarro
Company_adminJhoan Sebastián Lopera Gallego
Leonardo Valdivieso
Resumen:
Buenas Prácticas
Código Limpio
Cómo lo logramos
Deuda técnica
Refactoring
Excelente resumen!
Gracias!
"Seguridad" no solo es autenticación (eg login) y autorización (eg accesos), sino también controlar todo input, evitar problemas de logica de negocio, etc.
Sería interesante cursos sobre código seguro porque es más fácil y hasta trivial atacar que defender.
Concuerdo contigo, yo igual pensaba que la seguridad era la proteccion de contraseñas, pero ademas es la verificacion de los datos.
TERMINOLOGIA
- Buenas practicas
Conjunto de estandares comprobados y verificados que brindan guias faciles de aprender y comprender , permitiendo tener una estructura similar para multiples proyesctos.
- Codigo Limpio
Es un codigo que sigue buenas practicas, es facil de entender, analizar, mantener, actualizar y escalar.
¿Como se logra?
- Deuda tecnica
Son problemas tecnicos que ocurren durante la fase de desarrollo del software, dichos problemas deben ser arreglados si o si en el futuro.
Ejemplos:
- Refactoring
Proceso que se realiza al codigo para mejorar cualquier aspecto ya sea de seguridad, rendimiento, legibilidad, soporte, etc...
Los cambios que se realizen deben ser recurrentes disminuyendo la deuda tecnica, ademas, no deben afectar al cliente/negocio, puesto que el objetivo de esto no es hacer un cambio radical en el software.
https://platzi.com/cursos/solid-csharp-net/ => lanzamiento en 5 días a partir de la fecha de hoy 17/01/2023...
🤔Resumen 🤔
✍️Mientras que las buenas prácticas establecen las reglas generales, el refactoring y el código limpio son acciones específicas para mejorar el código existente, y la gestión de la duda técnica es la consideración importante para evitar problemas a largo plazo.
Cuanto tiempo debe durar un refactoring?
Los refactoring son un ciclo y nunca acaban, se deben hacer continuamente cada vez que el código va creciendo o programarlo para cada cierto numero de tiempo como 3 meses. En duración realmente no se tiene algo definido muchas veces los refactoring nos ayudan mucho a evitar deuda técnica ahorrando tiempo a futuro
Un codigo siempre debe estar listo para pode escalarlo
Buenas prácticas.
Utilizar los estándares comprobados y verificados que nos permiten resolver desafíos comunes en los proyectos de la mejor forma posible. A pesar de todas las alternativas por las que se pueden optar, la diferencia con la buena práctica, es la guía que nos proporciona para solucionar el problema de la mejor manera.
Una de las ventajas de las buenas prácticas es su facilidad de adopción, tanto como para comprender y aprender, por lo tanto replicables en todo los proyectos.
Código Limpio.
Podríamos denominar código limpio, al base de código que sigue las mejores prácticas que se utilizan actualmente en el mercado para dejar un proyecto que: - Es legible, - Tiene facilidad para escalar (Se extiende el código con más funcionalidades), - Se mantiene con facilidad (Por ello tiene una vigencia prolongada), - Puede actualizar sus dependencias,
¿Cómo logramos código limpio?
- Sostener un bajo acoplamiento, utilizando clases abstractas e interfaces, para no tener un dependencia directa entre los diferentes componentes del sistema. - Utilizar un sintaxis simple y moderna. - Evitar incorporar muchas librerías de terceros, que puedan dificultar su actualización. - Crear una buena distribución de responsabilidades, asignando a cada clase una sola responsabilidad. - Creación de componentes pequeños, para que puedan leerse fácilmente y también en futuro, ampliar sus funcionalidades. - Evitar hacer pocos componentes con muchas funcionalidades, será difícil acercase al proyecto por su poca legibilidad.
Deuda técnica.(Technical debt)
Ésta, representa los problemas técnicos que puede tener un software, los que son adquiridos durante la fase de desarrollo y que al final se van a solucionar en el futuro, queramos o no queramos, vamos a tener que solucionarlo. Pueden ser los aspectos de seguridad, rendimiento, escalabilidad, etc.. Que no se tuvieron en cuenta, que causen posterior al lanzamiento de la aplicación, fallas críticas. El mantenimiento de estos errores, podría costar aún más que la creación de la aplicación.
Refactoring
Modificación del código para el mejoramiento en cualquier aspecto como (rendimiento, seguridad, legibilidad, soporte, entre otros) sin alterar la lógica del negocio y funcionamiento de la aplicación. Los beneficios de hacer refactoring promueven los pasos para lograr el código limpio, disminuyendo la deuda técnica del proyecto. La recurrencia en estas estrategias siempre mantiene una base limpia de trabajo.
here we go
Escuchar "tecnologías no comprobadas" me hace acordar de Ports & Adapters (Hexagonal) que ayuda a no depender de tecnologías especificas (frameworks, db, orm, etc.)
por nosotros mismos es importante un código limpio, el día de mañana nosotros mismos debemos dar mantenimiento a nuestro desarrollo, y no sabemos que hemos escrito.
Estos conceptos son verdaderamente fundamentales. Llevaba tiempo sin ver que alguien lo explicara de forma tan clara.
Resumen:
Buenas Prácticas
Estándares comprobados y verificados Resuelven desafíos de escenarios comunes Brindan guías fáciles de aprender y comprender Permiten tener una estructura similar para múltiples proyectos Código Limpio
Un código que sigue las buenas prácticas Código fácil de entender y analizar Código fácil de mantener Código fácil de actualizar Código fácil de escalar Cómo lo logramos
Mantener bajo acoplamiento Utilizar sintaxis simple y moderna Evitar incorporar muchas librerías de terceros Distribución de responsabilidades Creación de componentes pequeños Deuda técnica
Se refiere a los problemas técnicos que puede tener un software que son adquiridos durante la fase de desarrollo y que deben ser solucionados en el futuro. Puede estar presente en cualquier aspecto de una aplicación como: Seguridad, rendimiento, escalabilidad, etc. A veces puede resultar más costosa que el mismo desarrollo. Refactoring
Proceso de cambios sobre un código para el mejoramiento en cualquier aspecto (rendimiento, seguridad, legibilidad, etc.) Lo más importante es hacer cambios manteniendo la lógica de negocio sin afectaciones. Debe ser recurrente. Disminuye la deuda técnica a futuro.
No olvides la parte donde plantea el caso hipotético de que el programador Junior hace las cosas rápido🤡
Terminología clave en C#:
Buenas prácticas: Normas y principios para escribir código legible, mantenible y eficiente. Ejemplos:
Refactoring: Reorganizar y mejorar el código sin modificar su comportamiento. Se busca:
Código limpio: Código que es fácil de entender, modificar y mantener. Se caracteriza por:
Deuda técnica: Costo de mantener y mejorar un código que no se ha escrito siguiendo buenas prácticas. Se genera por:
En resumen:
Consejos:
Hello everyone! I share my repository where you can find the summary of this course!
Never stop learning!😃
Huy eso si lo hace las empresas de revisar código viejo ya en producción sin haber la necesidad, lo he escuchado varias veces, hasta en el libro de Robert C Martin, pero sera q existen esos espacios en las empresas??
De acuerdo
Creo que se puede depender de librerias de 3ros. Si se vuelven obsoletas se deberian cambiar por otras. Un adaptador podria usarse para que no se acople demasiado