Dedicar tiempo a uno mismo, en clave de código

En marzo de 2020, hablé hablé de revisar nuestras Especificaciones de Servidory que uno de mis principales objetivos era asegurarme de que proporcionamos la mejor experiencia posible a los desarrolladores que utilizan nuestros SDK. La actualización de las especificaciones del servidor permitió a nuestro equipo abrirse un poco y desarrollar los SDK de forma que tuvieran sentido para el lenguaje y ofrecieran a cada desarrollador la experiencia que esperaba.

Nos propusimos objetivos para la primera mitad del año en torno a la idea de limpiar la experiencia del usuario. Esto dio lugar a que nuestros defensores del desarrollo del lenguaje revisaran cada uno de los SDK, tanto en el espacio de nombres de Nexmo como en el de OpenTok, y encontraran dónde podíamos alinearnos mejor con la nueva especificación. Empezamos a hacer una lista de los puntos en los que no cumplíamos la especificación. Suena muy formal, pero lo que queremos decir es: ¿se alineaban los SDK con nuestros nuevos objetivos? ¿En qué aspectos los SDK no parecían o no parecían una biblioteca para el lenguaje X?

Una oportunidad para causar una primera impresión

Para muchos desarrolladores, su primera experiencia con una API de Vonage es a través de nuestros SDK de servidor o cliente. Una de las primeras tareas de su proyecto será instalar nuestro software SDK y arrancarlo por primera vez. A partir de ese momento, nuestro trabajo es facilitar la escritura de software para nuestra plataforma.

Cada lenguaje es diferente, y lo entendemos. Un desarrollador Java tiene un conjunto diferente de expectativas para escribir una aplicación en comparación con un desarrollador Ruby. Nuestros SDKs deberían exponer nuestras APIs de una forma que tenga sentido para los lenguajes que soportamos. Deberíamos ser tan pitónicos o idiomáticos o limpios como un desarrollador espera que sea una biblioteca adecuada.

Los lenguajes también evolucionan. Soy desarrollador de PHP, y gran parte del odio que recibe nuestro lenguaje se basa en código con expectativas y restricciones de años pasados y versiones que ya no reciben soporte. Nuestros SDKs deberían evolucionar con los lenguajes, y de hecho lo hacen. Los desarrolladores tienen expectativas sobre cómo es el código "moderno" y nosotros deberíamos esforzarnos por cumplirlas.

Uno de los principales objetivos de nuestro equipo del SDK de servidor es ofrecer bibliotecas que estén al día no sólo con nuestros productos, sino también con las expectativas de los desarrolladores. Siempre hemos defendido varias ideas, como el desarrollo basado en pruebas, la documentación de alta calidad y la atención al detalle. Tenemos previsto seguir tomando el pulso a las comunidades de desarrolladores y de lenguajes para ofrecer la mejor experiencia posible a los desarrolladores.

¿Qué buscábamos?

La mayor parte de las auditorías giraron en torno al uso de nuestros productos y a si los SDK exponían o no ese uso de forma clara y evidente. La claridad del código era uno de los puntos principales de la nueva especificación del SDK y se convirtió en un aspecto importante de las auditorías.

La Audit dio a cada uno de nuestros defensores lingüísticos el tiempo y el poder para marcar dónde podíamos mejorar. Ninguno de nuestros SDK se quedaba atrás en cuanto al soporte que esperábamos ofrecer, pero cada uno de los SDK tenía retoques y cambios de nombre en las interfaces públicas que harían más claras las intenciones.

Como adelanto de algunos de los próximos cambios en el SDK de PHP, gran parte de la capa Voice API ha sido reescrita. Si desea realizar una llamada saliente, debe crear un objeto OutboundCall objeto. Si quieres generar una NCCO, puedes crear un objeto NCCO y añadir acciones a la OCNC. Tomando una página de la "auto-documentación de código" libro de jugadas, un desarrollador debe ser capaz de leer este código y entender lo que está pasando, incluso si no están familiarizados con PHP en sí.

$outboundCall = new OutboundCall(new Phone(TO_NUMBER), new Phone(NEXMO_NUMBER));
$ncco = new NCCO();
$ncco->addAction(new Talk('This is a text to speech call from Vonage'));
$outboundCall->setNCCO($ncco);

$response = $client->voice()->createOutboundCall($outboundCall);

La idea no es que la forma antigua fuera difícil, sino que no estaba tan claro lo que ocurría. Renombrar métodos y clases puede ser todo un reto, pero esperamos que muchos de estos cambios no solo faciliten la comprensión de lo que hacen nuestros productos, sino también la mejor forma de utilizarlos.

Esta Audit también nos permitió encontrar lugares en los que uno o dos SDK estaban haciendo algo que debería hacerse global en todos los SDK. Una de estas opciones era permitir a los usuarios especificar las URL de base para las API. Aunque esto era una petición de los clientes, resulta que algunos SDK ya lo habían implementado. La Audit nos dio la oportunidad de recopilar estas ideas y asegurarnos de que se añadían en todos nuestros SDK.

Mejorar los productos

Muchos de nuestros defensores de los desarrolladores lingüísticos que mantienen nuestros SDK son también lo que llamamos Especialistas en productos. Nuestros especialistas de producto colaboran con los jefes de producto y los distintos equipos de ingeniería en la creación de nuestros productos de API. A medida que los especialistas de producto ayudan a diseñar el producto en sí, los desarrolladores ven cómo interactúan con las API a través de los SDK.

Si descubrimos que algo puede resultar difícil para un desarrollador, podemos tomar mejores decisiones a nivel de API o de SDK para facilitarle la vida. Nuestro trabajo no consiste solo en viajar a los eventos y repartir camisetas: recogemos todas las opiniones de los desarrolladores y hacemos saber a los jefes de producto y a los ingenieros dónde podemos ofrecer una experiencia mejor, y les ayudamos a encontrar soluciones.

La reciente versión de .NET v5.0.0 se han introducido muchas mejoras en el SDK. Hubo algunas adiciones de código útiles como la mejora de la gestión de errores y un sistema de registro más flexible, pero las pruebas unitarias y fragmentos de código vio un refactor. Estos cambios no sólo mejoran nuestra confianza, y por extensión la suya, en el código y los cambios, sino que los ejemplos son mucho más claros y concisos sobre cómo implementar nuestros SDK.

Estamos a su servicio

Al fin y al cabo, nuestro trabajo consiste en defender a los desarrolladores que utilizan nuestro software. No necesariamente abogamos para que uses nuestro producto, sino que abogamos por ti, el desarrollador, como una voz dentro de Vonage. Parte de lo que hacemos es tomar los comentarios que recibimos de los desarrolladores con los que nos reunimos y mejorar nuestros productos, pero también nos aseguramos de que tu experiencia sea tan buena y productiva como sea posible. Podríamos autogenerar nuestros SDK y darlo por terminado, pero eso no te ayuda a ti, la persona que intenta resolver un problema.

A finales de 2020, tendremos un montón de interesantes actualizaciones de los SDK orientadas específicamente a hacer más claro el desarrollo. .NET, Python y PHP tienen algunas maravillosas reescrituras en camino que ayudan a limpiar varias experiencias. Ruby continúa con la comprobación estática de tipos introducida en v6.3.0 junto con varias mejoras generales (v7.0.0 introdujo un mejor manejo de errores y nombres de clase más claros, así que echa un vistazo a esa versión).

No dude en ponerse en contacto con nosotros para hacernos llegar sus comentarios sobre nuestros productos o sobre el software, las demos o las herramientas que creamos. Tenemos un canal canal Slack de la comunidad en el que nuestros defensores del idioma y del producto ayudan a responder preguntas en el día a día. Supervisamos Stack Overflow y ayudamos a dar respuestas y orientación a los distintos problemas a los que se enfrentan los desarrolladores. Respondemos a los correos electrónicos que llegan a community@vonage.com sobre muchos temas diferentes acerca de nuestros SDK y API.

Queremos darle las herramientas y el apoyo que resuelvan su problema, con la mayor rapidez y eficacia posibles.