シェア:
){kind=small}
クリスはデベロッパー・リレーションズ・ツーリング・マネージャーで、お気に入りのツールを開発するチームを率いています。彼は15年以上、クライアントワークからビッグデータ、大規模システムに至るまで、様々な言語と種類のプロジェクトでプログラミングをしてきました。オハイオ州に住み、家族と過ごしたり、ビデオゲームやTTRPGゲームをしたりしている。
私たちを定義する仕様
所要時間：1 分
開発者として、私は怠け者だ。もし誰かが私の抱えている問題を解決するソフトウェアを作ったなら、私はそれを使いたい。新しいライブラリは、あまり干渉されることなく、すぐに使い始めることができるはずだ。
NexmoのサーバーSDKチームのイニシアチブ・リーダーとして、私の目標のひとつは、SDKを使用する開発者に最高のエクスペリエンスを提供することです。SDKを使うことが、ドキュメントを調べたり、生のHTTPリクエストをしたりするのと同じくらい苦痛であるなら、SDKに何の意味があるのでしょうか？私たちのチームは、あなたがソフトウェアを作る仕事をより早くできるようにしたいと考えています。
最近、チームが集まり、既存のServer SDK Specs（以前はClient SDK Specsと呼ばれていました）がどのように維持されているかを確認するために、Server SDK Specs（以前はClient SDK Specsと呼ばれていました）を見直すことにしました。この仕様書は、Nexmoがソフトウェアの書き方についてより批判的に考え始めた2016年に書かれたものです。2020年現在、私たちは6つの異なる言語のSDKを管理しており、それぞれの言語には独自の癖があります。数年前と今とでは、何が違うのでしょうか？
最初の仕事は、RFCにインスパイアされた言語の多くを廃棄することだった。理由はいたって簡単で、RFCは既知の構造と、合意された文言を提供するものだからだ。おかげで RFC 2119のおかげで MUST, MUST NOT, SHOULD, SHOULD NOTなどの単語はすべて、それぞれ固有の定義を持っており、RFCがどのように書かれるかについての期待値を設定している。もし誰かが新しい仕様書を作成するのであれば、これらの単語はまったく意味をなさない。
それから4年、さらに5つのSDKが登場し、この文書は機能だけでなく直接的な実装に関してもかなり厳しくなっていた。動作だけでなく、APIクライアントがどのような構造であるべきかについても詳述されていた。このため、あるSDKの設計方法は自然に分裂し、他のSDKはあまり言語として自然でないやり方を余儀なくされました。RubyのSDKはNodeJSのライブラリのように見えるべきでしょうか？
おそらく無理だろう。
そのため、我々は特定の言語構成要素にまつわる言葉の多くを削除したが、さまざまなアイデアに関する包括的な目標や目的は残した。 しかし、SDKを使いやすくする様々なアイデアSDKを使いやすくするための様々な考え方の包括的な目標や目的は維持しています。エラーと例外は、ライブラリが明示的にサーバー例外やレスポンス例外を投げるべきだという考え方に従ったまま、命名に関する指示は、「使用すべき動詞のリストはこちらです」というものに減らしました。
この仕様は、SDKを均質な体験にすることにあまり興味がなく、現在では、言語の期待とベストプラクティスを一致させるという指示を後押ししています。これは、私たちのパブリックSDK APIが変化していくことを意味しますが、言語Xの開発者として期待されるものに変化していくことを意味します。私たちは、SDKが、あなたの言語のよく構築されたライブラリで得られるようなエクスペリエンスを提供することを望んでいます。
Nexmoの素晴らしいところは、ウェブアドレスを入力するだけで、誰でもすぐにAPIを使い始めることができることです。インターネットのおかげで、HTTPという標準的なプロトコルと、JSONやXMLを使ったシンプルなテキストインターフェイスを使って、世界中のマシンと素早くやりとりできるようになりました。私たちは、かつてないほどさまざまなサービスを結びつけることができる。
しかし、通話中に音声合成を再生する必要があるのに、なぜ「？ $talk->put()?意味的には意味がない。
たしかにNexmoは素晴らしいAPIを提供しているが、ソフトウェアを作るときには、私たちが何であるかは気にすべきではない。通話中に音声合成をしたいのであれば、 $call->playTextToSpeech("Hello World")の方が意図がはっきりしている。これは、HTTP PUTリクエストを作るかもしれないが、HTTPメソッドにちなんだメソッド名をつける必要はない。
私たちは 動詞と命名規則を、HTTPクライアントを書くためではなく、仕事を終わらせるために行うアクションのリストに整理した。開発者はSDKを使ってサードパーティーのサービスを抽象化している。結局のところ、私たちが PUTを使おうが POSTを使ったかどうかなんて誰も気にしない。
私たちのSDKが、私たちのプラットフォームと対話できるさまざまな方法を提供するだけでなく、インターフェイスが理解しやすく、使いやすいものであることを確認したいのです。私たちのSDKは、作業を行う際に起こりうる定型文を処理する手助けをしながら、行われている作業について明示することで、問題を解決する手助けをするものでなければなりません。
既存の通話に音声合成を入れるという例に戻ると、現在の方法は、わかりやすさとセマンティクスの観点から、少しわかりにくい。私たちのSDKで何かを行う方法を見つけることは、明示的であるべきであり、また素早く実行できるものであるべきです。開発者が6ヶ月後に自分のコードに戻って来て、なぜアクションを実行する代わりに talk()がアクションを実行する代わりにオブジェクトを返す理由を理解しようとするようなことは避けたい。私は、開発者が自分のコードを簡単に読むことができ、常に何が起こっているかを正確に知ることができるようにしたいのです。
// Current, pull a Talk object out of a specific call
$talk = $client->calls['abcd-123']->talk();
// Set the text
$talk->setText(TEXT);
// PUT the text back to the API
$talk->put();
// In the future, we will just find a specific call
$call = $client->calls()->find('abcd-123');
// And play Text to Speech into it
$call->playTextToSpeech("All your base are belong to us");
サーバーSDKチームは現在、すべてのメインラインSDK(NodeJS, Java, Python, .NET, ルビーおよび PHPなどのSDKを開発し、新しい仕様と照らし合わせています。私たちは、SDKの開発者エクスペリエンスに焦点を当て、よりモダンでクリーンな方法で、SDKに期待されている使いやすさをすべてのお客様に提供したいと考えています。
いつものように、私たちはお客様からのフィードバックを聞くのが大好きです。私たちは、お客様の生活をより快適にするためにこのソフトウェアを開発しています。カンファレンスやミートアップで私たちを見かけたら、私たちがどのようなことをしているか教えてください！私たちのSDKに欲しいものはありますか？私たちに連絡してください Githubで私たちと連絡を取り、不足している機能があれば教えてください。