Prendre du temps pour soi, en toute connaissance de cause

En mars 2020, j'ai j'ai parlé de la révision de nos spécifications pour les serveurset que l'un de mes principaux objectifs était de m'assurer que nous fournissions la meilleure expérience possible aux développeurs qui utilisent nos SDK. La mise à jour des spécifications du serveur a permis à notre équipe de s'ouvrir un peu et de développer les SDK d'une manière qui soit logique pour le langage et qui donne à chaque développeur l'expérience qu'il attend.

Nous avons fixé des objectifs pour le premier semestre de l'année autour de l'idée d'améliorer l'expérience de l'utilisateur. Nos développeurs linguistiques ont donc passé en revue chacun des SDK, à la fois dans les espaces de noms Nexmo et OpenTok, et ont cherché à savoir où nous pouvions mieux nous aligner sur la nouvelle spécification. Nous avons commencé à dresser une liste des points non conformes à la spécification. Cela semble très formel, mais ce que nous voulons dire, c'est que les SDK ont-ils été alignés sur nos nouveaux objectifs ? Où les SDK ne ressemblent-ils pas à une bibliothèque pour le langage X ?

Une chance de faire une première impression

Pour de nombreux développeurs, leur première expérience avec l'API de Vonage se fait par le biais de nos SDK serveur ou client. L'une des premières tâches de leur projet consistera à installer notre logiciel SDK et à l'amorcer pour la première fois. À partir de ce moment, notre travail consiste à faire en sorte qu'il soit facile d'écrire des logiciels pour notre plateforme.

Chaque langage est différent, et nous le comprenons. Un développeur Java a des attentes différentes de celles d'un développeur Ruby en ce qui concerne l'écriture d'une application. Nos SDK devraient exposer nos API d'une manière qui soit logique pour les langages que nous prenons en charge. Nous devrions être aussi pythoniques, idiomatiques ou propres que ce qu'un développeur attend d'une bibliothèque appropriée.

Les langages évoluent également. Je suis un développeur PHP, et une grande partie de la haine que reçoit notre langage est basée sur un code avec des attentes et des restrictions datant d'années révolues et de versions qui ne sont plus prises en charge. Nos SDK devraient évoluer avec les langages, et c'est ce qu'ils font. Les développeurs ont des attentes sur ce à quoi ressemble un code "moderne" et nous devrions nous efforcer de les satisfaire.

L'un des principaux objectifs de notre équipe SDK Serveur est de fournir des bibliothèques qui sont à jour non seulement par rapport à nos produits mais aussi par rapport aux attentes des développeurs. Nous avons toujours défendu diverses idées telles que le développement piloté par les tests, la documentation de haute qualité et l'attention portée aux détails. Nous avons l'intention de continuer à suivre de près les communautés de développeurs et de linguistes afin d'offrir aux développeurs la meilleure expérience possible.

Que recherchions-nous ?

La majeure partie des audits a porté sur l'utilisation de nos produits et sur la question de savoir si les kits de développement logiciel exposaient cette utilisation de manière claire et évidente. La clarté du code était un point essentiel de la nouvelle spécification du SDK et est devenue un point important des audits.

L'Audit a donné à chacun de nos défenseurs des langues le temps et le pouvoir d'indiquer où nous pouvions faire mieux. Aucun de nos SDK n'était en retard par rapport à l'assistance que nous nous attendions à fournir, mais chacun d'entre eux comportait des ajustements et des changements de nom pour les interfaces publiques qui rendraient les intentions plus claires.

En avant-première de certains changements à venir dans le SDK PHP, une grande partie de la couche Voice API a été réécrite. Si vous souhaitez passer un appel sortant, vous créez un objet OutboundCall objet. Si vous voulez générer un NCCO, vous pouvez créer un objet NCCO et ajouter des actions au NCCO. En s'inspirant de la méthode du "code auto-documenté", un développeur devrait pouvoir lire ce code et comprendre ce qui se passe, même s'il n'est pas familier avec le langage PHP.

$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);

L'idée n'est pas que l'ancienne méthode était difficile, mais que ce qui se passait n'était pas aussi clair. Renommer les méthodes et les classes peut être un véritable défi, mais nous espérons que nombre de ces changements faciliteront non seulement la compréhension de ce que font nos produits, mais aussi la meilleure façon de les utiliser.

Cet Audit nous a également permis de trouver des endroits où un ou deux SDK faisaient quelque chose qui devrait être généralisé à l'ensemble des SDK. L'une de ces options consistait à permettre aux utilisateurs de spécifier des URL de base pour les API. Bien qu'il s'agisse d'une demande des clients, il s'est avéré que certains SDK l'avaient déjà mise en œuvre. L'Audit nous a donné l'occasion de rassembler ces idées et de veiller à ce qu'elles soient ajoutées dans tous nos SDK.

Améliorer les produits

Un grand nombre de nos développeurs linguistiques qui assurent la maintenance de nos SDK sont également ce que nous appelons des spécialistes produits. Ces spécialistes collaborent avec les chefs de produit et les différentes équipes d'ingénieurs dans le cadre de la conception de nos produits API. Comme les spécialistes produit contribuent à la conception du produit lui-même, la façon dont les développeurs interagissent avec les API par le biais des SDK est examinée en amont.

Si nous constatons que quelque chose est difficile à utiliser pour un développeur, nous pouvons prendre de meilleures décisions au niveau de l'API ou du SDK pour lui faciliter la vie. Notre travail ne consiste pas seulement à nous rendre à des événements et à distribuer des t-shirts : nous prenons en compte tous les commentaires des développeurs et nous indiquons aux chefs de produit et aux ingénieurs les domaines dans lesquels nous pouvons améliorer l'expérience, et nous les aidons à trouver des solutions.

La récente version de .NET v5.0.0 a apporté de nombreuses améliorations au SDK. Il y a eu quelques ajouts de code utiles comme une meilleure gestion des erreurs et un système de journalisation plus flexible, mais les tests unitaires et les extraits de code ont fait l'objet d'une refonte. Ces changements ont non seulement amélioré notre confiance, et par extension la vôtre, dans le code et les changements, mais les exemples sont devenus beaucoup plus clairs et concis sur la façon de mettre en œuvre nos SDK.

Nous sommes là pour vous servir

En fin de compte, notre travail consiste à défendre les intérêts des développeurs qui utilisent notre logiciel. Nous ne plaidons pas nécessairement pour que vous utilisiez notre produit, mais pour que vous, le développeur, puissiez vous exprimer au sein de Voice. Une partie de notre travail consiste à prendre en compte les commentaires des développeurs que nous rencontrons et à améliorer nos produits, mais nous devons également nous assurer que votre expérience est aussi bonne et productive qu'elle peut l'être. Nous pourrions générer automatiquement nos SDK et nous arrêter là, mais cela ne vous aiderait pas, vous qui essayez de résoudre un problème.

D'ici à la fin de l'année 2020, nous disposerons d'un grand nombre de mises à jour passionnantes des kits de développement logiciel (SDK) visant spécifiquement à rendre le développement plus clair. .NET, Python et PHP ont de merveilleuses réécritures à venir qui aideront à nettoyer diverses expériences. Ruby poursuit la vérification statique des types introduite dans la version 6.3.0 ainsi que diverses améliorations générales (v7.0.0 a introduit une meilleure gestion des erreurs et des noms de classes plus clairs, alors consultez cette version).

N'hésitez pas à nous faire part de vos commentaires sur nos produits ou sur les logiciels, démonstrations ou outils que nous créons. Nous avons un canal Slack de la communauté qui permet à nos linguistes et à nos spécialistes des produits de répondre aux questions au jour le jour. Nous surveillons Stack Overflow et nous aidons à fournir des réponses et des conseils aux différents problèmes auxquels les développeurs sont confrontés. Nous répondons aux courriels qui nous parviennent à l'adresse community@vonage.com sur de nombreux sujets différents concernant nos SDK et API.

Nous voulons vous fournir les outils et le soutien nécessaires pour résoudre votre problème, aussi rapidement et efficacement que possible.