Clean Code Course - Capítulo 2 (PDF)

WEBVTT 00:00:00.000 --> 00:00:09.840 Muy buenas y bienvenidos al segundo capítulo del curso de Clean Code de Mastermind. Este capítulo 00:00:09.840 --> 00:00:14.240 va a ser el primero donde vamos a ver realmente ejemplos de código y vamos a hablar de cómo poner 00:00:14.240 --> 00:00:19....

WEBVTT 00:00:00.000 --> 00:00:09.840 Muy buenas y bienvenidos al segundo capítulo del curso de Clean Code de Mastermind. Este capítulo 00:00:09.840 --> 00:00:14.240 va a ser el primero donde vamos a ver realmente ejemplos de código y vamos a hablar de cómo poner 00:00:14.240 --> 00:00:19.800 nombres a las cosas, que es seguramente una de las facetas más difíciles a la hora de programar, 00:00:19.800 --> 00:00:25.800 decidir exactamente qué nombre tenemos que poner a variables o a funciones. El libro de Robert C. 00:00:25.800 --> 00:00:31.240 Martin nos da algunos consejos que pueden ser súper útiles a la hora de decidir qué nombres 00:00:31.240 --> 00:00:39.680 darle a las cosas y he resumido aquí en este fichero de 01.nombres.ts los que yo creo que 00:00:39.680 --> 00:00:45.480 son más importantes o los que se alejan un poco del sentido común como tal. Vamos a irlos viendo 00:00:45.480 --> 00:00:51.400 uno a uno hasta ver exactamente qué consejos nos da Robert C. Martin a la hora de nombrar cosas. 00:00:52.120 --> 00:00:58.040 El primer consejo que vemos es el de utilizar nombres que reveren la intención de nuestro código, 00:00:58.040 --> 00:01:04.080 es decir, utilizar nombres que al leerlos tengamos contexto, tengamos información de 00:01:04.080 --> 00:01:09.960 exactamente lo que se está, digamos, intentando hacer. El ejemplo que ponemos aquí pues vendría 00:01:09.960 --> 00:01:16.840 a ser este ejemplo de mal código, una variable llamada de, que básicamente es un número. Fijaros 00:01:16.840 --> 00:01:21.840 que simplemente leyendo esto nosotros no sabemos lo que hace este código, no sabemos la intención 00:01:21.840 --> 00:01:28.680 detrás de esto. Tenemos que añadirle un comentario. Cuando es necesario poner comentarios para dar 00:01:28.680 --> 00:01:34.360 contexto a nuestro código es una muy buena señal que nos dice, hey, cuidado, tenemos quizá que 00:01:34.360 --> 00:01:39.640 replantear cómo hemos escrito esto, tenemos quizá que replantear el nombre. Y fijaros que un ejemplo 00:01:39.640 --> 00:01:45.840 mejorado sería cambiar simplemente la de por este nombre de aquí. Fijaros que hemos cogido 00:01:45.840 --> 00:01:52.240 simplemente el comentario y lo hemos, entre comillas, puesto como nombre de la variable. Claro, 00:01:52.240 --> 00:01:57.000 si nuestra variable ya se llama directamente días desde el registro, no hace falta añadir aquí un 00:01:57.000 --> 00:02:02.840 comentario porque ya se lee directamente. Por lo tanto, este primer consejo lo que nos dice es esto, 00:02:02.840 --> 00:02:08.080 que tenemos que poner los nombres que ya tienen el contexto suficiente para ahorrarnos directamente 00:02:08.080 --> 00:02:14.320 tener que hacer comentarios. Aquí podríamos ver en una función real, en esta función getItems, 00:02:14.320 --> 00:02:19.000 cómo si nosotros leemos estas tres líneas, prácticamente no sabemos lo que está haciendo. 00:02:19.000 --> 00:02:23.720 Si nosotros miramos estas tres líneas, lo que vemos es que estamos en una función que nos devuelve 00:02:23.720 --> 00:02:30.080 un conjunto de ítems, asumimos que es un conjunto de ítems, que le tenemos que pasar también un 00:02:30.080 --> 00:02:37.720 conjunto de ítems y que nos devuelve de este conjunto que le pasamos algo filtrado, por algo 00:02:37.720 --> 00:02:44.720 que el estatus sea 1, pero no sabemos exactamente lo que significa, no tenemos contexto de lo que 00:02:44.720 --> 00:02:50.520 está haciendo aquí. Esto sería muy tentador, pues poner comentarios, poner rollo allItems es un 00:02:50.520 --> 00:02:57.480 conjunto de usuarios o esta función devuelve, rollo documentación, esta función devuelve los 00:02:57.480 --> 00:03:04.960 usuarios que tienen el estado activo, pero si nos fijamos realmente no es necesario. Aquí hemos 00:03:04.960 --> 00:03:10.800 directamente sacado este atributo de aquí a una variable, este es otro consejo que nos da que es 00:03:10.800 --> 00:03:17.240 no tener números mágicos, esto se llama un número mágico porque es un número hardcoded aquí, no 00:03:17.240 --> 00:03:23.000 sabemos por qué está aquí ni lo que significa, así que directamente le ponemos un nombre y fijaros 00:03:23.000 --> 00:03:27.840 que hemos renombrado las funciones para indicar lo que están haciendo. Aquí tenemos claramente 00:03:27.840 --> 00:03:33.680 que esta función nos devuelve los usuarios activos y que le estamos pasando usuarios. Solamente 00:03:33.680 --> 00:03:39.600 leyendo esto ya vemos que lo que se está haciendo es un filtrado a los usuarios por el estado activo, 00:03:39.600 --> 00:03:44.320 por lo tanto no tenemos que añadir ningún tipo de comentario, no es necesario, ya se entiende 00:03:44.320 --> 00:03:49.520 directamente con esta visualización. Se podría mejorar un poco más si por ejemplo esto no fuera 00:03:49.520 --> 00:03:54.480 una constante como tal y si fuera un enumerado o alguna cosa de estas, pero entendéis el concepto, 00:03:54.480 --> 00:04:00.480 es básicamente ponerle los nombres a las cosas para que el que lo lea sepa lo que se está 00:04:00.480 --> 00:04:06.760 haciendo de un primer vistazo y esto es básicamente el tema de utilizar nombres que revelen la 00:04:06.760 --> 00:04:12.640 intención del código, utilizar nombres que revelen el contexto, que revelen 00:04:12.640 --> 00:04:20.280 lo que se quiere hacer y esto nos lleva también al segundo consejo que es este de aquí, no 00:04:20.280 --> 00:04:25.480 utilizar nombres que puedan desinformar, de la misma forma que queremos utilizar nombres que 00:04:25.480 --> 00:04:32.280 den contexto, queremos evitar dar nombres que confundan. Algo muy común es por ejemplo utilizar 00:04:32.280 --> 00:04:38.120 el tema de listas o el nombre de listas cuando estamos dando nombres a conjuntos de cosas como 00:04:38.120 --> 00:04:42.960 por ejemplo un array, pero fijaros que puede llegar a ser confuso porque nosotros podemos 00:04:42.960 --> 00:04:51.320 llamar account list a un array de cuentas o podemos llamar account list a un conjunto de 00:04:51.320 --> 00:04:58.360 cuentas, fijaros que uno es un array y otro es un objeto, los dos son conjuntos de cuentas 00:04:58.360 --> 00:05:04.000 igualmente, claro esto puede llevar a confusión porque alguien al leer directamente list, si está 00:05:04.000 --> 00:05:11.920 programando utilizando este código, pues puede llegar a asumir que esto es un array, 00:05:11.920 --> 00:05:18.720 en cambio aquí no sería un array, sería un objeto, entonces mucho cuidado con todo el tema de poner 00:05:18.720 --> 00:05:25.200 nombres de cosas que pueden llevarse a confusión, siempre pensar muy bien si yo leyera esto sin ver 00:05:25.200 --> 00:05:31.000 la definición, sin ver la instanciación de esta variable, sería capaz de deducir de un primer 00:05:31.000 --> 00:05:37.520 vistazo lo que es y Robert C. Martin recomienda una cosa que yo creo que es bastante acertada, 00:05:37.520 --> 00:05:44.880 sobre todo si utilizáis typescript que tiene los tipos incorporados y es el de oye al final list 00:05:44.880 --> 00:05:49.680 puede llevar a confusión porque alguien entenderá que es un conjunto, que es un array, que es un objeto 00:05:49.680 --> 00:05:54.080 o lo que sea, pero lo que sabemos claro es que esto sí que es un conjunto de cuentas por lo tanto 00:05:54.080 --> 00:05:59.360 vamos a llamarlo directamente accounts, una de las recomendaciones del libro es no utilizar 00:05:59.360 --> 00:06:05.000 ni prefijos ni sufijos para determinar los tipos de las variables, eso lo va a definir el propio 00:06:05.000 --> 00:06:10.080 lenguaje, eso lo va a definir por ejemplo typescript con el tipado o incluso javascript lo puede 00:06:10.080 --> 00:06:15.400 definir porque realmente tienen tipos, aunque no estén explícitamente en el código como tal, 00:06:15.400 --> 00:06:24.320 entonces es mejor práctica no colocar los tipos en los nombres. Un siguiente consejo que me gustaría 00:06:24.320 --> 00:06:30.080 destacar es colocar los nombres pensando en el autocompletado, ahora hemos hablado del tema de 00:06:30.080 --> 00:06:36.400 pos colocar prefijos o sufijos para determinar ciertas cosas, puede ser bastante común pues 00:06:36.400 --> 00:06:44.000 tener un conjunto de enrutadores o de controladores o un conjunto de objetos o de variables que 00:06:44.000 --> 00:06:50.200 determinan cosas similares, pues por ejemplo podrían ser controladores http o rutas http o 00:06:50.200 --> 00:07:00.560 servicios o cualquier cosa de estas. Es muy común querer colocar el autocompletado o el prefijo 00:07:00.560 --> 00:07:05.680 común al final, pues por ejemplo fijaros aquí tenemos el handler user service o el handler 00:07:05.680 --> 00:07:13.400 company service o el handler account service. Fijaros que la alternativa sería poner directamente 00:07:13.400 --> 00:07:19.080 user service handler, company service handler o account service handler, ¿cuál creéis que es 00:07:19.080 --> 00:07:25.800 mejor? Imaginaros que yo tengo un conjunto de user service handler, user service controller y user 00:07:25.800 --> 00:07:32.960 account manager o un conjunto de objetos que se referencien al user, si yo pensara en el autocompletado 00:07:32.960 --> 00:07:38.360 quisiera ser mucho más eficiente a la hora de poner nombres pensando en autocompletado, yo tengo 00:07:38.360 --> 00:07:45.040 que poner los prefijos diferentes delante, ¿por qué? Porque si yo ahora aquí quiero llamar a algo 00:07:45.040 --> 00:07:51.680 del user, fijaros que ya me sale directamente los primeros el user service handler, en cambio si yo 00:07:51.680 --> 00:07:56.960 ahora pongo handler, fijaros que aquí tengo que escoger cuál de los handlers quiero. Simplemente 00:07:56.960 --> 00:08:01.160 es algo a tener en cuenta, depende mucho de la situación, de cómo creéis que se utilice 00:08:01.160 --> 00:08:06.280 vuestro código, cómo creéis que sea la experiencia a la hora de desarrollar con vuestro código, si 00:08:06.280 --> 00:08:12.000 queréis poner los prefijos comunes antes o después, simplemente algo tener en cuenta, en función del 00:08:12.000 --> 00:08:19.160 autocompletado si ponéis los prefijos distintos como prefijo lo que va a hacer es que al autocompletar 00:08:19.160 --> 00:08:24.440 os salgan primero todo lo que empieza por user, simplemente un consejo porque a veces va bien 00:08:25.160 --> 00:08:32.400 poder distinguir ya sea por tipo, ya sea por dominio o lo que sea. El siguiente consejo que me gustaría 00:08:32.400 --> 00:08:38.160 comentar de Robert C. Martin es el de distinguir correctamente los nombres de las cosas, el consejo 00:08:38.160 --> 00:08:42.720 concreto que nos da es que es mucho mejor dar nombres distintos que indiquen claramente el 00:08:42.720 --> 00:08:48.040 uso, no simplemente ir con los nombres que nos dan las templates, dejadme explicar esto, imaginaos 00:08:48.040 --> 00:08:53.120 que nosotros tenemos un conjunto de cuentas, que sería básicamente un array de unos objetos que 00:08:53.120 --> 00:08:58.120 son cuentas, que tienen el nombre de la cuenta y el valor, la cantidad de dinero que hay en esa cuenta 00:08:58.120 --> 00:09:06.040 y pues tenemos esta función, esta función que básicamente lo que nos hace es un reduce, fijaros 00:09:06.040 --> 00:09:13.600 que el reduce es muy común utilizar los nombres a y b, pero claro un poco para glaseando lo que 00:09:13.600 --> 00:09:20.680 hemos dicho antes, yo leo esto y realmente tengo que saber lo que hace el reduce para poder entender 00:09:20.720 --> 00:09:25.600 lo que está haciendo este código, de acuerdo, de primeras no tengo contexto de lo que está 00:09:25.600 --> 00:09:33.200 haciendo este código, en cambio si yo le pongo unos nombres más correctos, unos nombres que dan 00:09:33.200 --> 00:09:39.480 más contexto, yo aquí, vale, puedo no entender exactamente lo que hace el reduce, pero de primeras 00:09:39.480 --> 00:09:44.280 solo por el nombre de la variable, fijaros que antes era a y ahora es accumulated value, valor 00:09:44.280 --> 00:09:50.000 acumulado, ya sé que se está acumulando algo, fijaros que me está dando mucho contexto, también 00:09:50.000 --> 00:09:55.080 está dando contexto de qué es este cero, me está diciendo que es el valor inicial, por lo tanto ya 00:09:55.080 --> 00:10:00.000 sin saber ni siquiera lo que hace el reduce, sé que le estoy pasando un valor inicial y que estoy 00:10:00.000 --> 00:10:07.960 acumulando algo en accumulated value y también veo pues que le estoy pasando de la account actual 00:10:07.960 --> 00:10:13.480 de la que estoy analizando, le estoy pasando el valor, por lo tanto ya me está dando mucho contexto 00:10:13.480 --> 00:10:18.760 sin ni siquiera saber lo que hace el reduce, aquí en cambio tengo que entender muy bien cómo funciona 00:10:18.760 --> 00:10:24.040 el reduce, tengo que ir a la documentación del reduce para saber exactamente qué es lo que está pasando, 00:10:24.040 --> 00:10:31.080 en cambio aquí aún sin saberlo pues más o menos puedo llegar a tener una cierta idea y eso que el 00:10:31.080 --> 00:10:35.720 reduce personalmente no creo que sea una de las construcciones más legibles, lo he puesto 00:10:35.720 --> 00:10:40.920 expresamente por eso, que incluso siendo una construcción un poco compleja, un poco confusa, 00:10:40.920 --> 00:10:47.480 se puede llegar a dar un contexto bastante útil a la hora de escoger simplemente los nombres. 00:10:48.920 --> 00:10:53.880 También se recomienda evitar sinónimos, a la hora de poner nombres evitar sinónimos que puedan 00:10:53.880 --> 00:10:59.320 significar lo mismo, por ejemplo ¿cuál es la diferencia real entre producto info y entre 00:10:59.320 --> 00:11:05.480 product data?, fijaros que es el mismo tipo, es la misma estructura de datos, realmente 00:11:05.480 --> 00:11:10.800 estamos usando info o estamos usando data, no hay ninguna diferencia, es totalmente arbitrario, 00:11:10.800 --> 00:11:15.960 simplemente nos tenemos que decidir por uno de ellos, si queremos utilizar info pues tenemos 00:11:15.960 --> 00:11:22.760 que utilizar info de forma consistente, no podemos tener en el mismo proyecto product info 00:11:22.760 --> 00:11:29.880 y user data, ¿por qué?, ¿qué es info y qué es data?, son cosas distintas, debería ser product 00:11:29.880 --> 00:11:37.160 info y user info o product data y user data, un poco tener la 00:11:37.160 --> 00:11:44.920 consistencia de cuando haya sinónimos intentar pillar una convención, coger una convención en 00:11:44.920 --> 00:11:50.560 el proyecto y decir vale pues todo lo que tenga información extra va a tener info o data, escoger 00:11:50.560 --> 00:11:58.880 un poco los nombres y evitar confusión, también por ejemplo si nosotros podemos definir el tipo 00:11:58.880 --> 00:12:04.200 customer, ¿por qué definir el tipo customer object?, ¿qué diferencia hay entre estos dos 00:12:04.200 --> 00:12:12.600 tipos?, lo más fácil es simplificar, es decir si nos podemos ahorrar el sufijo object y 00:12:12.600 --> 00:12:17.000 directamente llamarlo customer, es mucho mejor primero llamarlo customer, también lo mismo con 00:12:17.000 --> 00:12:21.920 product info y product data, si puedo llamarlo simplemente product, ¿por qué tengo que ponerle 00:12:21.920 --> 00:12:29.440 el sufijo info o el sufijo data?, igual con user, ¿por qué user info versus user a secas?, entonces 00:12:29.440 --> 00:12:36.400 la tendencia es que es mucho mejor simplificar, al final el contexto ya viene por el 00:12:36.400 --> 00:12:40.720 propio nombre, ya sabemos que es un usuario, asumimos que dentro del usuario va a haber la 00:12:40.720 --> 00:12:47.320 información del usuario, no hace falta complicarnos demasiado y esto también pasa si pensamos en los 00:12:47.320 --> 00:12:52.760 atributos dentro de los tipos, a mí me pasa mucho personalmente que cuando hago un tipo y le digo 00:12:52.760 --> 00:12:57.680 vale pues va a ser account y va a tener un account name, acabo poniéndole un account name, acabo 00:12:57.680 --> 00:13:03.040 poniéndole el prefijo account a prácticamente todo lo que está dentro de ese tipo, fijaros que eso 00:13:03.040 --> 00:13:08.400 cuando lo ves así en la definición de tipo no pasa mucho pero luego cuando lo utilizas te das 00:13:08.400 --> 00:13:15.360 cuenta de que acabas poniendo account punto account name, te genera mucho ruido visual, en cambio si 00:13:15.360 --> 00:13:21.640 directamente ponemos el name aquí sin poner el prefijo account vemos que queda mucho más 00:13:21.640 --> 00:13:29.160 limpio, ¿por qué pasa esto?, a mí personalmente me pasa porque siempre tengo la tendencia a diferenciar 00:13:29.160 --> 00:13:34.560 por ejemplo nombres o ideas, me pasa mucho con ideas, con nombres, con emails o con cosas de 00:13:34.560 --> 00:13:41.400 estas, por ejemplo yo puedo tener un account name y puedo tener un username y un product name, entonces 00:13:41.400 --> 00:13:47.120 como para mí todos son names y creo diferenciarlos, mi mente directamente le pone el prefijo porque me 00:13:47.120 --> 00:13:53.960 olvido que luego realmente en el código se va a ver así account punto name, ya están con el namespace, 00:13:53.960 --> 00:13:58.800 ya están diferenciados cuál es el nombre de un account o cuál es el nombre de un usuario, por lo 00:13:58.800 --> 00:14:05.360 tanto no hace falta ir poniendo siempre el prefijo. Otro consejo que nos da Robert en el libro, aunque 00:14:05.360 --> 00:14:11.080 creo que este es bastante de sentido común, es de utilizar nombres pronunciables, al final esto va a 00:14:11.080 --> 00:14:17.720 ser leído por otros desarrolladores lo más seguro, por lo tanto no ganamos nada quitando las vocales 00:14:17.720 --> 00:14:24.920 por ejemplo, en vez de systemer tendríamos que poner customer, digamos que no ganamos nada por 00:14:24.920 --> 00:14:29.840 intentar simplificar o intentar acortar los nombres, es mucho mejor tener un nombre largo 00:14:29.840 --> 00:14:35.480 legible que un nombre corto no legible, porque también mentalmente yo al menos cuando leo el 00:14:35.480 --> 00:14:43.000 código siempre lo leo en voz alta entre comillas, mentalmente con voz, por lo tanto es mucho más 00:14:43.000 --> 00:14:48.440 fácil leer esto que no leer esto. No voy a gastar mucho tiempo en este porque creo que es bastante 00:14:48.440 --> 00:14:56.440 de sentido común, pero también puede no ser tan obvio, por ejemplo aquí porque está puesto 00:14:56.440 --> 00:15:03.760 con timestamp pero podríamos tener generator tsp, claro podríamos decir no pero es que timestamp 00:15:03.760 --> 00:15:10.680 lo hemos acordado como tsp, poner timestamp es mucho más cómodo y mucho más legible, generator 00:15:10.680 --> 00:15:22.960 tsp, fijaros que ya lo lees así no tsp, pues para eso ponemos tsp, en principio no, mucho mejor que 00:15:22.960 --> 00:15:31.760 si es un timestamp pues ponga timestamp, no hace falta ir acortando los nombres. Lo siguiente es 00:15:31.760 --> 00:15:37.000 utilizar nombres que nos permiten ser buscados, la recomendación que nos dan es que si una variable 00:15:37.000 --> 00:15:42.880 o constante se utiliza en varios sitios o está jarcodeada, es decir es un número mágico, se le 00:15:42.880 --> 00:15:48.960 tiene que dar un nombre sí o sí, porque básicamente para poder no solamente leerla mejor sino poderla 00:15:48.960 --> 00:15:54.520 buscar después. Si yo aquí tengo que buscar cosas es que no me voy a acordar, me tengo que acordar yo 00:15:54.520 --> 00:15:59.440 que sé, pues que aquí había un 34, de hecho no sé ni lo que está haciendo este código, tengo que 00:15:59.440 --> 00:16:05.440 acordarme que había un 34 para luego buscarlo, hacer control f, intentar encontrar esto, en cambio 00:16:05.440 --> 00:16:10.520 aunque sea más largo, si yo le pongo nombres, si quiero buscar este código, pues sé que puedo 00:16:10.520 --> 00:16:16.040 buscar por workbase, ¿por qué? porque le he puesto nombres a todas las variables, es decir he quitado 00:16:16.040 --> 00:16:22.640 todos los valores jarcoded y los he puesto arriba, ya tengo muchos ganchos en los que buscar, puedo 00:16:22.640 --> 00:16:28.600 buscar por el workbase per week, puedo buscar por el nombre number of tasks, por lo que sea y fijaros 00:16:28.600 --> 00:16:35.920 que también al darle mejores nombres a las variables que estoy utilizando también se llega a 00:16:35.920 --> 00:16:40.360 entender mejor lo que está haciendo este código, veo que estoy iterando un conjunto de 00:16:40.360 --> 00:16:45.600 tareas, veo que estoy haciendo algún tipo de operación con los días, porque llego a ver que 00:16:45.600 --> 00:16:54.560 estos son días, veo que estoy acumulando 10 tareas por semana, por lo tanto digamos que nos da mucho 00:16:54.560 --> 00:17:00.800 más contexto, esto es como un conjunto de cosas que estaban mal, cosas que estaban mal y que con 00:17:00.800 --> 00:17:06.240 todos los consejos que hemos ido viendo hemos visto cómo mejora realmente el código y aunque sea más 00:17:06.240 --> 00:17:14.040 largo, algunos dirán que esto es demasiado verboso, pero se entiende y es un poco el objetivo, se 00:17:14.040 --> 00:17:21.520 entiende y es más fácil de leer. Luego hay un tema que yo creo que es discutible, un poco controversial 00:17:21.520 --> 00:17:27.040 a mi gusto, que Robert C. Martin nos recomienda no utilizar tipos en los nombres, es un poco lo que 00:17:27.040 --> 00:17:32.560 hemos visto antes con la lista, pero en este caso lo tenemos por ejemplo con strings, es decir 00:17:32.560 --> 00:17:37.720 lo que nos dice Robert C. Martin es que es preferible tener este tipo de nombres directamente 00:17:37.720 --> 00:17:44.160 phone que tener phone string, los tipos dice ya nos lo da el propio lenguaje, los propios tipos del 00:17:44.160 --> 00:17:50.200 lenguaje, no tenemos por qué decir que algo es un string o no, esto yo estoy totalmente de acuerdo 00:17:50.200 --> 00:17:56.200 si estamos utilizando TypeScript, porque ya tenemos la notación de tipo. Ahora bien, hay un 00:17:56.200 --> 00:18:03.680 caso específicamente en JavaScript donde a mí personalmente creo que es preferible tener el tipo 00:18:03.680 --> 00:18:11.120 y es en la definición de parámetros de funciones, en los parámetros de funciones de JavaScript tú 00:18:11.120 --> 00:18:18.280 puedes tener phone y puedes tener mucha confusión sobre si esto va a ser un string o si va a ser un 00:18:18.280 --> 00:18:25.480 número o si va a ser cualquier tipo, o si va a ser cualquier cosa, en cambio si tú ves que el que 00:18:25.480 --> 00:18:32.000 ha escrito esta función ya le ha puesto de nombre de parámetro phone string, ya llegas a ver la 00:18:32.000 --> 00:18:37.480 intención de ese atributo, llegas a ver que él en verdad está esperando que tú le pases aquí un 00:18:37.480 --> 00:18:42.960 string, por lo tanto creo que en JavaScript en el específico caso de los parámetros a funciones 00:18:43.240 --> 00:18:51.800 puede ser aceptable incluso a veces preferible pasarle, ponerle en los nombres el sufijo con 00:18:51.800 --> 00:18:58.680 el tipo, ya digo con TypeScript es totalmente innecesario porque la propia firma de la función 00:18:58.680 --> 00:19:05.880 ya le puedes poner el tipo y todo perfecto. Y para acabar el capítulo me gustaría comentar 00:19:05.880 --> 00:19:11.440 algunos consejos extra que nos podemos encontrar por el libro que creo que son también un poco 00:19:11.440 --> 00:19:17.560 de sentido común pero que puede ser útil simplemente nombrarlos para que los conozcáis, 00:19:17.560 --> 00:19:23.920 principalmente nos dice oye una palabra por concepto, esto va similar a lo que he explicado 00:19:23.920 --> 00:19:28.840 de los temas de los sinónimos, si yo puedo utilizar info no tengo que utilizar info y data 00:19:28.840 --> 00:19:33.280 por diferentes lados, lo que pasa es que aquí está un poco más enfocado a funciones, pues por 00:19:33.280 --> 00:19:42.320 ejemplo si yo tengo, me estoy utilizando algo como account service punto get account, por ejemplo si 00:19:42.320 --> 00:19:49.840 estoy utilizando gets no debería tener en otro servicio, pues yo que sé, user service fetch 00:19:49.840 --> 00:19:55.800 account, ¿por qué? porque yo no sé qué diferencia un get de un fetch, realmente están haciendo lo 00:19:55.800 --> 00:20:02.000 mismo, están obteniendo el valor, por lo tanto cuando son sinónimos o conceptualmente son lo 00:20:02.000 --> 00:20:08.120 mismo, por ejemplo get y fetch, tienes que escoger uno y tienes que intentar ser consistente en toda 00:20:08.120 --> 00:20:16.240 tu base de código, en todo tu proyecto de utilizar los mismos, ¿por qué? porque así quitas pesadez 00:20:16.240 --> 00:20:21.440 mental a la hora de tener que descubrir si esta clase era con fetch o esta clase era con get o esta 00:20:21.440 --> 00:20:27.040 clase era con obtain o lo que sea, queda mucho mejor y es mucho más sencillo y esto debería ser 00:20:28.000 --> 00:20:34.440 si todo es con la misma palabra, que da igual que sea get o que sea fetch, lo importante no es tanto que sea 00:20:34.440 --> 00:20:41.240 una u otra sino que sean la misma, ¿vale? para mantener la consistencia, la consistencia y las 00:20:41.240 --> 00:20:48.840 convenciones en los proyectos de software son muy importantes y también para acabar utilizar 00:20:48.840 --> 00:20:53.160 nombres que sean fácilmente reconocibles por el negocio o que sean nombres conocidos por la 00:20:53.160 --> 00:20:57.760 industria, si estás haciendo un proyecto que tiene muchas reglas de negocio y tiene mucha 00:20:57.760 --> 00:21:04.080 nomenclatura de negocio, utilízala, ¿vale? si tienes que definir un concepto y no es un user, no es un 00:21:04.080 --> 00:21:09.960 usuario sino que es un nombre que puede tener el negocio, pues por ejemplo podría ser un cliente 00:21:09.960 --> 00:21:16.920 o podría ser un suscriptor, por ejemplo imaginaos que es el caso de YouTube, utilízalo en el código, ¿vale? 00:21:16.920 --> 00:21:22.840 imaginaos ver en el código de YouTube, ¿vale? el servidor de YouTube que estás hablando de 00:21:22.840 --> 00:21:32.200 suscriptores y pone users, ¿vale? o clients, no se llegaría a entender tanto como subscribers 00:21:32.200 --> 00:21:37.160 directamente, ¿vale? aquí directamente si esto tiene un nombre específico en el dominio del 00:21:37.160 --> 00:21:42.720 negocio ya te está dando mucha información, los glosarios son importantes y si hay un glosario 00:21:42.720 --> 00:21:48.160 bien hecho utilizarlo sin miedo, se entenderá mucho mejor e incluso puede llegar a pasar que 00:21:48.160 --> 00:21:51.880 gente que no es programadora pueda llegar a ver el código o tú estés hablando de lo que hace tu 00:21:51.880 --> 00:21:57.360 código y te llegue a entender porque tú estarás diciendo las cosas en el mismo idioma que el 00:21:57.360 --> 00:22:04.920 negocio. Si no existe glosario de negocio o no es consistente o estamos hablando de cosas técnicas 00:22:04.920 --> 00:22:10.400 que no tienen un equivalente en el negocio, utiliza nombres conocidos por la industria, por ejemplo 00:22:10.400 --> 00:22:15.840 si estás utilizando un patrón builder, un patrón de diseño que se utiliza para construir objetos 00:22:16.840 --> 00:22:20.960 eso puede llegar a dar mucha información al desarrollador, es decir si yo tengo un 00:22:20.960 --> 00:22:28.920 account builder y realmente esta clase, este objeto es un builder del patrón builder esto 00:22:28.920 --> 00:22:33.120 me está dando ya muchísima información solamente porque estoy utilizando nombres conocidos por la 00:22:33.120 --> 00:22:39.320 industria, en este caso la industria de software, ¿vale? o si esto es una cola de trabajo, una cola 00:22:39.320 --> 00:22:46.800 de workers o lo que sea, yo puedo utilizar rollo users job queue, ¿vale? aquí ya estoy diciendo 00:22:46.800 --> 00:22:52.920 pues que esto es una cola de trabajos de algo relacionado con los users. Si existen nombres 00:22:52.920 --> 00:23:00.240 técnicos que pueden dar mucho contexto a la hora de leer el código, utilizarlos, ¿vale? Y esto es 00:23:00.240 --> 00:23:06.480 un poco así resumidamente los consejos que nos da Robert C. Martin en el primer capítulo de 00:23:06.480 --> 00:23:12.120 nombres, que sería el capítulo de cómo darles nombres con sentido a las cosas y ayudar a que 00:23:12.120 --> 00:23:17.560 la persona que lo lea tenga mucho más contexto. En el siguiente capítulo vamos a avanzar un poquito 00:23:17.560 --> 00:23:22.720 y no vamos a hablar solamente de nombres sino que vamos a hablar también de funciones. ¿Qué tan larga 00:23:22.720 --> 00:23:28.120 tiene que ser una función? ¿Qué tiene que hacer una función? ¿Puede hacer más de una cosa? Cosas de este 00:23:28.120 --> 00:23:33.880 estilo. Si os ha gustado este capítulo quedaros para el siguiente porque va a ser súper interesante. Nos vemos ahora mismo. 00:23:36.480 --> 00:23:39.480 Subtítulos realizados por la comunidad de Amara.org