Un codificador hablando de código
Tom aquí escribiendo, desarrollador apasionado de todo lo relacionado con la web y lo nativo. Han pasado muchas lunas desde que empecé a escribir unas pocas líneas de código. Fue un glorioso momento de “Hola mundo”, y desde entonces he escrito muchas más líneas de mucho más código, que abarcan desde sistemas de alerta en tiempo real, aplicaciones médicas que apoyan a los médicos en sus tareas diarias hasta reuniones multiplataforma. software de gestión de programación. También he aprendido algunas cosas a lo largo del camino, y hoy quiero compartir un aspecto de la codificación que puede que no siempre obtenga tanta atención, especialmente durante los momentos pesados de la mitad del proyecto. Hablemos de la responsabilidad de un codificador o, para ser precisos, del legado del código de un codificador.
Las pirámides de Javascript
El trabajo de un arquitecto no es solo definir el diseño fundamental de un nuevo edificio, las formas de las paredes, ventanas y puertas o la alineación de la casa proporcional al sol al mediodía. Entre todas esas cosas, el arquitecto sabe que el edificio tiene que aguantar durante años, que tiene que soportar una naturaleza brutal de fuertes vientos, lluvias torrenciales, inviernos fríos y veranos calurosos. El objetivo final del trabajo del arquitecto es asegurarse de que las personas que viven en el edificio tengan un hogar seguro. Se trata de la longevidad de su trabajo. Se trata de su legado.
En el desarrollo de software, las cosas tienden a moverse a un ritmo muy rápido, especialmente cuando se trabaja en empresas emergentes. Es importante enviar rápidamente nuevas funciones, ganar tracción en el mercado y mantener el interés de los usuarios. El enfoque durante el desarrollo tiende a limitarse al sprint actual o implementar esa característica de alta prioridad lo antes posible.
Sin embargo, cuando estoy codificando, no debería limitarse a que las pruebas se iluminen en verde o solo a la fecha límite que debe cumplirse. Una vez en la naturaleza, las aplicaciones son utilizadas por humanos que pueden depender de ellas para su rutina diaria de trabajo. El programa que estoy construyendo hoy es el legado que dejaré mañana.
Tomemos la Web como ejemplo: nunca ha sido más fácil encontrar componentes que brinden la funcionalidad que estoy buscando en este momento a través de NPM. Se instalan y conectan rápidamente al resto del código base. Pero cuando se trata de la longevidad de mi aplicación, las dependencias de terceros pueden detener todo el proceso de actualización, b / c actualizar que una dependencia impide que otra funcione. Es un acto de equilibrio decidir entre qué implementar por mi cuenta, bifurcar o instalar directamente desde un administrador de paquetes.
Sin embargo, el código de proveedores externos puede estar bien. Es importante verificar algunos factores antes de usar la biblioteca o el marco: qué tan bueno fue el mantenimiento en el pasado, cuántas contribuciones activas hay ahora, hay una hoja de ruta disponible que describe los cambios o mejoras futuros, si el paquete está completamente administrado por la comunidad o respaldado por patrocinadores para ayudar con su desarrollo?
Pasando del código externo a mi propio código base, una cosa que tengo que recordarme constantemente es no tomar atajos durante el desarrollo para alcanzar un objetivo más rápido. Por muy tentador que sea a corto plazo, el código mal planificado se vengará y morderá. Pensar en el código más que escribirlo ayuda a mitigar muchos problemas. Sin duda, un factor clave aquí es la experiencia, sin embargo, los desarrolladores junior también deben comprender la importancia del código mantenible desde el principio. Lo que conduce a errores ahora puede que nunca se solucione debido a los plazos del proyecto y solo se resuelva a través de soluciones alternativas, lo que lleva a un código desordenado, una mala experiencia del usuario o ambos.
Mentalidad del maquinista
Otro aspecto de la codificación reflexiva sobre el que quiero escribir es el público objetivo de una aplicación, el usuario. Mientras estoy sentado de 9 a 5 frente a la pantalla de mis reglas deslizantes eléctricas, revisando líneas de código y concentrándome en el problema que me asignaron, es difícil recordar que todo mi trabajo, eventualmente, ha terminado. para ser utilizado por alguien que lo use parcial o completamente durante el trabajo diario. Y realmente no importa si estoy creando una aplicación para personas sin conocimientos técnicos o API para otros desarrolladores; las cosas que creo deben ser ergonómicas en su uso.
Sé por experiencia de primera mano que los usuarios pueden interactuar con su aplicación de formas extrañas y en su mayoría inexplicables. Yo, como creador, tiendo a rechazar el comportamiento "no intencionado" de mi servicio, más aún si ya he invertido mucho tiempo y energía en él. Sin embargo, mantener la mente tranquila al recibir comentarios y, si es necesario, obligarme a escucharlos, juega un papel clave en la comprensión del comportamiento de uso real de la audiencia.
Nosotros, como desarrolladores, vivimos en un mundo de orden y uniformidad a la hora de codificar, donde se aplica un tipo especial de física y gravitación y donde conocemos todas las reglas. Es un mundo para abrazar y sumergirnos por completo en él, ya que somos sus creadores y habitantes. Pero enfrentar comentarios, es decir, críticas de fuera de este mundo, generalmente conduce a su rechazo por parte de los desarrolladores. El manejo de los informes y las opciones de los usuarios debe aprenderse y valorarse como una entrada relevante para el desarrollo. Es una lección que aprendí y es de gran ayuda en cada etapa del proyecto estar abierto a cambios y comentarios.
process.exit ();
Para resumir, piense no solo en el código que está escribiendo hoy, sino también en el que la gente usará en los años venideros. Tome decisiones meditadas con respecto al uso de paquetes de códigos externos, así como la estructura y las implementaciones del proyecto, de modo que el producto final se pueda utilizar de manera ergonómica y eficiente, reflejando la demanda real de la audiencia objetivo. Comprender la retroalimentación es clave y ayuda enormemente a entregar un producto de calidad del que uno puede estar orgulloso.
- Tom
