¿Sabías que la primera novela escrita data del año 1021? Su autora es la noble japonesa Murasaki Shikibu. Desde entonces, innumerables escritores han plasmado sus pensamientos en papel y numerosos lectores han experimentado sus historias. Las personas escriben durante décadas y nosotros, como desarrolladores de software, de alguna manera ignoramos su oficio. Nosotros también escribimos, no novelas, pero software. ¿No es acaso esto también escribir? Creas ficción o código, hay mucho en común. En esta presentación veremos qué tan cerca estamos de gigantes como Hemingway y Stephen King. ¿Podemos obtener algo de su sabiduría y aplicarla a nuestro trabajo diario como ingenieros? Ven a esta charla y obtendrás algunos consejos prácticos. Espero que mi presentación te convierta en un desarrollador React un poco mejor.
Todos somos Hemingway
Video Summary and Transcription
Esta charla cubre consejos importantes para el desarrollo de software, enfocándose en React. Se enfatiza comenzar con lo que sabes y construir sobre ello. Hacer las preguntas correctas y simplificar los componentes demuestra experiencia. Leer código y hacer preguntas son cruciales para encontrar mejores soluciones. Se destacan la función connect en la biblioteca React Red Hook y el patrón de componente función-como-hijo. Se enfatiza escribir código que sea fácil de entender y mantener para otros. Se menciona la importancia de reintentar en el servidor y refactorizar para el ecosistema.
1. Introducción
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. Hoy he decidido compartir con ustedes los consejos más importantes que he encontrado. Y espero que también les resulten útiles.
♪ 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.
2. Starting with What You Know
Lo primero en escribir, al igual que en programación, es comenzar con lo que sabes. Por ejemplo, en React, si no estás familiarizado con la escritura de aplicaciones, puedes comenzar renderizando un componente de respaldo. Luego, a medida que aprendes más, puedes construir sobre lo que ya sabes. La complejidad surge a medida que adquieres conocimiento, tanto en la escritura como en el desarrollo de software.
3. Writing Components and Asking Questions
Cuando escribes software, es importante centrarse en la historia. Pregúntate si cada componente o función es realmente parte de la historia. Por ejemplo, al manejar errores en un componente fetch, renderizar mensajes de error puede que no sea parte de la historia del componente. En su lugar, considera pasar el error como argumento a los hijos del componente. Al hacer las preguntas correctas y simplificar los componentes, puedes demostrar tu experiencia.
4. Importancia de Hacer Preguntas y Leer Código
Hacer preguntas es crucial para encontrar mejores soluciones. Sin embargo, la falta de experiencia puede dificultar saber qué preguntas hacer. Para adquirir más experiencia, se recomienda leer código escrito por otros desarrolladores.
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
5. Explorando la Función Connect y Leyendo Código
Me fascinó cómo funciona la función connect en la biblioteca React Red Hook. Esto me llevó a escribir un artículo y lanzar una biblioteca basada en este patrón. Sin embargo, más tarde descubrí que este patrón no era nuevo y se había utilizado durante años. Leer código, especialmente en bases de código grandes como React, puede enseñarte mucho.
6. El Patrón de Componente Función como Hijo
El patrón de componente función como hijo, ejemplificado por Formic, es uno de mis favoritos. Permite que componentes como Formic tengan responsabilidad mientras brindan valor al consumidor. Leer código de bibliotecas populares, que a menudo implican colaboración entre desarrolladores, puede ofrecer ideas valiosas y decisiones inteligentes.
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.
7. Escribiendo Código para Otros
El código que escribimos no es solo para nosotros, sino para que otros lo lean, mantengan y amplíen. Stephen King dijo: 'escribe con la puerta cerrada, reescribe con la puerta abierta'. Al escribir código, es importante hacerlo simple para que otros lo entiendan y revisen. Debemos renombrar componentes y props para reflejar su propósito y eliminar los innecesarios. Siguiendo este enfoque, podemos ayudar a otros a comprender mejor nuestro código, incluso sin entrar en los detalles de implementación.
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
8. Reflexiones Finales y Recomendaciones
Si se trata de algo en el servidor, lo intentamos de nuevo. La historia aquí trata de hacer una solicitud y manejar el error. La refactorización se trata de probar el código para otros compañeros de equipo y personas en el ecosistema. Gracias por ver y escuchar.
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.