Eliminando loops y condiciones con Collections
- Eliminaci贸n de variables temporales.
- Un solo nivel de indentaci贸n.
- Eliminaci贸n de sentencias if y foreach.
- C贸digo m谩s expresivo…..momento…..驴seguro que es m谩s expresivo? 馃
驴Es realmente m谩s expresivo?
En este 煤ltimo punto es donde quiero detenerme, exponer mi opini贸n y tambi茅n saber las suyas.
Cuando vi el v铆deo por primer vez, me acuerdo que quede fascinado con el resultado final. Pero ahora que me volv铆 a cruzar con el v铆deo y tengo un poco m谩s de experiencia (o estoy m谩s viejo e hincha pelotas, puede ser), no me fascino tanto 馃槙.
Volviendo a la pregunta anterior, 驴es m谩s expresivo?.
Mmm… no creo que lo sea. La verdad que no veo diferencias entre el c贸digo original y el c贸digo refactorizado, desde el punto de vista de la legibilidad.
驴Ustedes que piensan?, 驴no les parece lo mismo el c贸digo original con el refactorizado?
Si bien creo que el paquete Collections es genial, en este caso se esta haciendo un abuso, haciendo dif铆cil seguir el c贸digo. Y ac谩 es cuando me doy cuenta que no me gusta el c贸digo, porque uso la palabra 芦seguir禄 y creo que un c贸digo no se debe 芦seguir禄, sino 芦leer禄.
En el momento que te pierdes entre las lineas de c贸digo intentando entender que es lo que hace, es cuando comienza la se帽al de que algo no esta bueno.
Mi opini贸n
Creo que cuando queremos refactorizar un smell code, como el primer caso, podemos apoyarnos en las collections y a su vez, a帽adir algo de legibilidad porque no todo el mundo sabe a simple vista que hace la funci贸n flatMap() o porque al m茅todo sum() en un caso le pasamos un string y en el otro caso, no.
Siguiendo esta idea de collections + legibilidad, yo har铆a algo as铆:
Como pueden ver, fui reemplazando el c贸digo para darle un poco m谩s de sentido a lo que se esta haciendo. Fui reemplazando los m茅todos de la propia collection por unos m茅todos custom.
Y estos m茅todo custom los defin铆 de la siguiente forma para poder utilizarlos en el modelo que los tiene que usar.
- Cree una clase llamada
EmployeeCollectiony otraCustomerCollection. ambas extienden deCollection. - En cada una, cree m茅todos m谩s descriptivos.
- Y copie el c贸digo correspondiente.
4. Luego, el truco esta en sobrescribir el m茅todo newCollection() en cada uno de los modelos Employee y Customer, haciendo que devuelvan las clases de collection custom que cree en el paso anterior.
5. A la clase Customer tambi茅n le tengo que agregar la funci贸n calculateTotalOrders(), ya que este m茅todo no se ejecuta en una colecci贸n de customers, sino que se ejecute por cada uno de ellos.
Y esto sigue funcionando de la misma forma que la refactorizaci贸n original.
Si bien, sigo utilizando los m茅todos de Collection, creo que esta forma se entiende perfectamente que hacen los m茅todos flatMap() o filter() en cada caso, ya que el nombre del m茅todo que los encierra, es mas descriptivo.
En fin…
En mi opini贸n, el c贸digo debe ser entendible por cualquier persona programadora. Y no digo, por cualquier programador, a secas. Porque algunos programadores tienen la idea de que para ser buenos, deben ser capaces de entender cualquier c贸digo complicado, como si fuera un matem谩tico que debe entender todas las formulas matem谩tica complicadas. Pero esto es programaci贸n y como dice Robert C. Martin:
El c贸digo debe ser escrito para personas, porque los que lo van a entender tambi茅n son personas. 锘緾lic para tuitear
Tu c贸digo queda mucho m谩s claro, sin dudas. Y es m谩s f谩cil para generar pruebas automatizadas. Solo cambiar铆a tu fromAmsterdan() por un m茅todo que reciba la ciudad como par谩metro en vez de tenerla hardcodeada 馃檪
El video de Adam Wathan tiene ya 3 a帽os, si le preguntas hoy seguramente 茅l tambi茅n lo refactorizar铆a distinto 馃槈
Marcelo habr铆a que ver el tema de fromAmsterm() porque si la regla de negocio solo contempla Amsterdam entonces estar铆a de mas parametrizarla. Pero bueno, es v谩lido tu comentario porque todo depende del requerimiento que justamente no es lo que tenemos por ser un ejemplo. Lo que si, si te tomo lo del hardcode, hubiera Sido mejor que la ponga como una constante, c贸mo hice con 7500.
Y lo de Adam, seguramente. C谩lculo que su idea de la charla era hacer el m谩ximo foco sobre las collection.
Muchas gracias por tu comentario bro! 馃榾
Me parace genial tu refactorizacion. La verdad llevo solo un mes usando laravel y en el trabajo he visto c贸digos que no me han gustado nada. Te pierdes tratando de leer que hace realmente.
A mi parecer tu c贸digo es mas legible, pero agradecer铆a que me orienten un poco mas sobre las colecciones, a simple vista, el ejemplo sin simplificar los veo mas legible, ya que solo 9 lineas aprox., agradecer铆a si me orientan porque el agregar colecciones y clases lo hace mas legible, si veo que tiene mas lineas de c贸digo. Gracias de antemano.
Lo que me choca del refactor propueto es: 驴Que responsabilidades le pertenecen a las clases Collection?. Siento que terminan siendo helpers donde vas a arrojar todo.
Me encanta el concepto de las Collections Class y me encantar铆a que fueran parte del framework (i.e: Que User::where(…)->all() te retorne un UserCollection en vez de un Collection), pero, el ejemplo me causa el mismo ruido que me causa escuchar a gente hablar de DRY.
DRY se trata de no repetir la logica de negocios en varios lugares, no de juntar el c贸digo que se parece.
En lo personal prefiero dejar esos 芦helpers禄 inline dentro del controlador/servicio y no crear una clase con una responsabilidad super poco definida que aguanta todo
Como estas Luciano? Gracias por tu comentario.
Yo creo que las collections de cada modelo no terminar铆an siendo una bolsa de gatos o contener solo helpers. Estas clases deber铆an tener los m茅todos necesarios para trabajar con una colecci贸n de Users (por ejemplo) y sus m茅todos deber铆an reflejar la intenci贸n del dominio.
Tu c贸digo queda m谩s entendible para ti, pero para otro da igual, como bien dices 芦Encerraste nomas el flatMap禄 ahora para saber que chingados hace hay que ir a ver tus m茅todos que si bien, ya dan mas o menos una idea, pero no quita el problema al 100.
ESO SI, TU C脫DIGO QUEDO BIEN BONITO como debe ser. Pero creo que tienes TOC.
En lo personal prefiero ver 5 l铆neas de c贸digo y si no entiendo algo ir directamente a la funci贸n a ver que chingados hace… que andar navegando entre carpetas/clases hasta llegar a la puta funci贸n…
O sea no critico tu forma de trabajar es muy bonito hacer eso, pero volvemos a lo mismo es m谩s trabajo, tiraste m谩s lineas de c贸digo, hiciste m谩s carpetas… y aunque ganas LEGIBILIDAD EN EL C脫DIGO … ROBUSTECES EL Scafolding … Y a mi en lo particular no me gusta generar un mont贸n de archivos/carpetas o digamos no me gusta tener tanto 芦pedacer铆a de c贸digo禄. Sino solamente despedazar el c贸digo donde realmente es mucho y vale la pena.
芦que chingados hace禄, 芦creo que tienes TOC禄, 芦puta funci贸n禄?? Tranquilo amigo, no es necesario faltar el respeto y no ser educado.