Reglas del diseño simple
Contenido del curso
Reglas del diseño simple
Contenido del curso
Carina Payleman
BinaryTreeCode
LEONARD CUENCA
Irving Juárez
Axel Enrique Galeed Gutierrez
José manuel Sanchez Juarez
Eugenio Condori
Brandon Lee Aguero Fernandez
Eric Daniel Cavanzo
Camilo Taborda
Alvaro Gonzalo Laruta Quiroz
Alex Condori Condori
Juan Pablo Ojeda Castañeda
Jonathan Javier Sanchez Rodriguez
Alejandro Gomez Maldonado
Reinaldo Mendoza
Maria Alejandra Luna Tito
Daniel Ochoa
Juan Martin Villanueva
Joan Alexander Valerio Rodríguez
Ricardo Andrey Cifuentes Martínez
Reinaldo Mendoza
4 reglas del diseño simple
Gracias men encanta con lo explicaste, de forma resumida y concreta. Es que a veces en los aportes se exeden mucho sobre explicando temas simples.
Clase 2: 4 reglas del diseño simple
Mantener la regla de DRY (Don't Repeat Yourself), NO siempre es sencillo. En muchos blogs he visto, esto casi siempre se refiere a modularización del código (dividir nuestro código en funciones más especificas). Y aunque esto es correcto, es solo la primera parte de esta regla. . Existen muchas otras variantes para aplicar esta regla que no son siempre "obvias" al momento de escribir código. Por ejemplo, considera las siguientes funciones: .
function sortNumArr(arr, asc = 1) { return arr.sort((a, b) => { let result = 0; if (a > b) result = asc ? -1 : 1 if (b > a) result = asc ? 1 : -1 return result; }); } function sortPeopleArr(peopleArr, asc = 1) { // Arr of person obj // { name: string, age: number } return peopleArr.sort((a, b) => { let result = 0; if (a.age > b.age) result = asc ? -1 : 1 if (b.age > a.age) result = asc ? 1 : -1 return result; }); }
. Hace exactamente lo mismo, estan ordenando un array de datos, ya sea de primitivos o de objetos. En este caso, no se esta respetando la regla de DRY. .
¿Cómo lo solucionamos? Con una abstracción
Vamos a crear una función que haga el algoritmo de ordenamiento, mientras que en uno de los argumentos le vamos a pasar el detalle, dependiendo del tipo de dato, al final queda algo como esto: .
function sortGeneralArr(comparator, asc = 1) { return function (arr) { return arr.sort((a, b) => { let result = 0; if (comparator(a, b)) result = asc ? -1 : 1; if (comparator(b, a)) result = asc ? 1 : -1; return result; }); }; } const sortNumArr = sortGeneralArr((a, b) => a > b); const numSortedArr = sortNumArr(numArr); const sortPeopleArr = sortGeneralArr((a, b) => a.age > b.age); const peopleArrSorted = sortPeopleArr(peopleArr);
En algún lado he escuchado lo siguiente: "Escribimos código para personas, no para máquinas." Esto haciendo referencia a que podemos escribir el código con las peores prácticas de todas forma la máquina lo va a entender, no así en el caso de una persona.
Para mí es esta la regla más importante
Respeta el principio DRY: "don't repeat yourself" junto con la ortogonalidad
Siempre es mejor prevenir un mal codigo que pasar demasiado tiempo intentando entederlo y refactorizando
Las 4 reglas del diseño simple
Para mi sería revela la intención del diseño, de esta manera cualquier desarrollador que lea el código pueda entender de la mejor manera lo que hace ese fragmento de código
Honestamente creo que las mas importantes o de mayor peso si serian tanto que pasen los test's(Debido a que si no lo pasan en si, si se genera el mismo caso pero en la realidad podria romperse o generar fallos que ya sabíamos) y el DRY ya que con este simplificamos mas el codigo y reducimos su cantidad, incluso llegando a entenderse mas fácil y siendo más rápido
hay profes demasiado geniales !!
yo pienso que es el de test
Puede ser muy teórico lo que menciona, pero a la hora de hacer un proyecto es sumamente importante tener en cuenta estos puntos. Así que esto va para: #developers #softwareengineers
Feedback Pareces una robot we, por fa mejora tus habilidades de oratoria, se nota desde la esquina que estás leyendo, esto por ende se le quita calidad y credibilidad al curso, te tienes que apropiar de tus palabras y de los conocimientos que tienes afianzados.
Es mejor prevenir que curar, una excelente reflexion para evitar la deuda tecnica desde que iniciamos el desarrollo.
puede por favor darnos algunos ejemplos de test o de cuales se pueden aplicar
Como minimo los tests unitarios, son esos donde se prueban funciones, la parte mas pequena de un proyecto, asi cuando hagas un cambio el test te va a decir si rompiste algo, luego idealmente serian pruebas de integracion y end to end
quizas para mi la mas importante es la de que el Codigo debe hablar por si mismo.
La regla más importante es seguir el principio DRY, hay códigos que repiten las mismas funciones, además casi siempre lo hacen por estar violando el último principio, de que una misma función haga muchas cosas, empiezan a copiar y pegar y modificar un solo parametro, lo que se debe hacer es el principio clásico "Divide y vencerás" asi mantenemos correctamente el DRY.
Buenas, para mi, el principio mas importa es pasar correctamente todos los test
Para mi sin dudas, la regla mas importante, sin quitarle el mérito a las demás es “Respeta el principio DRY (don’t repeat yourself)”. Al reutilizar código dentro de nuestro proyecto desde un método, estamos haciendo que este sea mas estable y mantenible.
Pienso que cada regla del diseño simple aporta demasiado como para definir una más importante que otra porque están muy ligadas entre sí. Revelar la intención del diseño se logra de una manera eficaz a menor cantidad de elementos contenga y procesos simples existan, para ello se debe respetar el principio DRY. A su vez, un código que no pueda ser probado eficientemente puede conducir a una equivoca interpretación de la intención.
Uy, esta difícil decidir la mas importante, diría que la separación de responsabilidad
