Todos somos Hemingway

♪ Hola a todos, bienvenidos a la Gran Charla de Wear All Hemi. Mi nombre es Krasimir Tzonev y trabajo para una empresa llamada Antidote. Ayudamos a los pacientes a acceder a ensayos clínicos y utilizamos React en todas nuestras aplicaciones de front-end. Cuando no estoy trabajando, paso la mayor parte del tiempo con mi familia. Tenemos dos hijos, así que tengo que llevarlos un poco a la escuela y al jardín de infantes. No sé cocinar en casa, así que mi esposa cocina. Yo lavo los platos. Solía correr antes. Últimamente no corro tanto, pero solía hacerlo. Y durante todas estas tres actividades, en realidad estaba escuchando audiolibros. Así es como mantengo mi cerebro activo. Y empecé escuchando libros de no ficción y luego pasé a los libros de ficción. Y en algún momento, siendo yo mismo autor, pensé por qué no hacer mi cuarto libro una obra de ficción. Hasta ahora solo había escrito libros técnicos, así que pensé por qué no probar algo diferente. Y lo tomé como un proyecto, así que empecé a abordarlo como abordo todos mis otros proyectos, básicamente viendo cómo hacerlo, porque no tengo experiencia escribiendo ficción. Así que decidí ver un tutorial al respecto, como en este caso fue más bien escuchar otros libros, que son libros sobre cómo escribir un libro. Y los encontré realmente útiles y empecé a sacar algunas citas, algunos tips de allí. Y cuando tenía esta lista grande, la revisé y me di cuenta de que en realidad, la mayoría de estos tips también funcionaban para el desarrollo de software. No era solo sobre escribir ficción, por ejemplo. Algunos de estos consejos eran realmente buenos para los programadores. Y si miramos la fecha de la primera novela y la fecha del primer programa, vemos que hay una gran brecha. Así que probablemente todas estas personas que escriben increíbles libros de ficción tienen algo que enseñarnos. Y aproximadamente en este momento, vi una charla de Jane Creighton en React Conf 2019 llamada React es Ficción y pensé, oh mierda, no solo soy yo. Hay otras personas que también se dieron cuenta de lo mismo. Así que hoy he decidido compartir con ustedes los consejos más importantes que he encontrado. Y espero que les resulten útiles.

Hacer preguntas todo el tiempo es realmente un buen enfoque para encontrar mejores soluciones. El problema es cuando no tienes suficiente experiencia, no sabes qué preguntas hacer. Entonces, ¿cómo puedes obtener más experiencia? Bueno, Hemingway dijo que cuando estaba escribiendo, era necesario que leyera y Stephen King tiene otra cita sobre si no tienes tiempo para leer, no tienes tiempo para escribir. Estoy bastante seguro de que leer mucho código, especialmente el de tus colegas o de tu base de código porque tienes que hacer revisiones de solicitudes de extracción, por ejemplo. Pero de lo que estoy hablando

Hay otro patrón que realmente me gusta. Y este es el patrón de componente función como hijo. Este es un ejemplo de Formic. Pero creo que el primer lugar donde vi este patrón fue en la biblioteca de enrutamiento de React. Y aquí, si no sabes cómo funciona esto, podríamos ir directamente a la biblioteca de Formic y ver cómo hay este componente Formic. Oh, leen los hijos de las props. OK, así que esta es la prop nativa de React. Oh, y simplemente llaman a los hijos como una función, lo cual, la primera vez que lo vi, fue un poco extraño. Pero los hijos realmente pueden ser cualquier cosa. Incluso podrían ser una cadena o un número. No importa para React. Entonces, este patrón en particular, para ser honesto, es mi favorito porque le da cierta responsabilidad al componente, como en este caso Formic, pero al mismo tiempo puede proporcionar algo fuera de él, como en el consumidor del componente. Así que lee el código de los demás, especialmente todas estas bibliotecas realmente populares, porque generalmente estos proyectos son una colaboración entre muchos desarrolladores, y estoy bastante seguro de que, colectivamente, han hecho algo realmente inteligente y han tomado decisiones interesantes y buenas. Así que si tienes la oportunidad, solo revisa algunas de estas bibliotecas.

Entonces, la última parte de mi presentación es realmente una pregunta. Nuevamente, vuelvo al punto donde tienes que hacer preguntas todo el tiempo. Entonces, mi pregunta principal suele ser, ¿quién es el lector? Y cuando estamos escribiendo libros de ficción, supongo que esta pregunta es un poco debatible, supongo, para los escritores de ficción, pero para los desarrolladores de software, creo que está muy claro que el código que estamos escribiendo no es solo para nosotros. Es principalmente para que otras personas lo consuman, lo lean, lo mantengan, lo amplíen. Por lo tanto, es importante escribir para otros, para otras personas. Y esto es lo que dijo Stephen King, escribe con la puerta cerrada, reescribe con la puerta abierta. Siempre recuerdo esta cita cuando reviso mis solicitudes de extracción antes de anunciarlas a mis colegas, porque incluso Hemingway dijo que el primer borrador siempre es una mierda, cito textualmente, pero luego de eso, tienes que volver atrás, tienes que preguntarte, ¿esta parte de la historia está siempre presente? Entonces, tienes que escribirlo de una manera que sea simple para que otras personas lo entiendan, sea simple para que otras personas incluso realicen la revisión de código. Si alguien pasa como una hora revisando tus 50 líneas de cambios, significa que no es realmente bueno. Entonces, si tomas este ejemplo, por ahora, no te enfoques en esta área, la prop action del componente form. Digamos que este es un componente sobre, se llama obtener correo electrónico, tenemos un campo de entrada llamado escribimos el correo electrónico. Cuando cambiamos algo, almacenamos el valor en un estado local llamado valor. Y tenemos un botón de enviar, que probablemente, si lo presionamos, vamos a la acción del componente form y registramos al usuario usando el correo electrónico. Entonces, esto lo considero un borrador. Y podría hacer un par de mejoras. La forma en que refactorizo mis componentes es primero mirar los componentes desde el exterior, como la API, lo que significa el nombre del componente y las props. Y en este caso, sé que este componente está registrando al usuario. No se trata solo de obtener el usuario del campo de entrada de correo electrónico. Se trata de realmente registrar a los usuarios, así que es mejor que lo llamemos simplemente registrar. Tenemos una prop llamada callback. Seguro que callback es una función, pero realmente no habla sobre por qué se dispara esta función más tarde. Entonces onSuccess, supongo, es mejor. Error ni siquiera parece una función. Entonces, desde el exterior, no tenemos idea de que tenemos que proporcionar una función, así que es mejor llamarlo onError. Al hacer estos pequeños cambios, aunque solo sea un cambio de nombre, ayudamos a otras personas a comprender mejor nuestro componente, incluso sin entrar en la implementación. Este es mi enfoque. Inicialmente, comienzo desde el exterior, miro la API, y generalmente solo cambio el nombre de las cosas. A veces encuentro props que no deberían estar allí. No forman parte de la historia, por ejemplo. Cuando avanzas hacia adentro, el valor es en realidad un correo electrónico, así que ¿por qué no llamarlo simplemente correo electrónico? Sería más fácil cuando estás leyendo el archivo de arriba a abajo, y cuando llegas al correo electrónico, simplemente ves que esto es un correo electrónico. Y ahora, esta pieza de lógica, que se trata de hacer las solicitudes usando este

Y con esto, quiero terminar mi presentación. Si te gustaron algunos de los tips que mencioné, te recomiendo encarecidamente que consultes estos libros porque los escuché. Y tal vez encuentres algo interesante también. Gracias por ver, por escuchar. Este es mi nombre de usuario de Twitter y este es el enlace para las diapositivas. Sí, gracias.